When developing an IoT product, choosing the right protocol for your project can be difficult. There’s a lot of choices out there, which can make selecting the most appropriate protocol for your project that much harder.  

That’s why we’ve put together a comparison of IoT protocols. In this guide, we’ll go over the pros and cons of the different IoT protocols you may wish to use and include an IoT protocol comparison table that’ll help identify the right solution for you. Let’s get into it.

Learn more by reading our complete guide to IoT Protocols and Standards for 2021.

MQTT (Message Queuing Telemetry Transport)

MQTT (message queuing telemetry transport) features a publisher-subscriber messaging model. This model enables simple data flows between different devices.

The Pros of MQTT

Here are some of the pros of MQTT as an IoT protocol:

  • Very lightweight – MQTT’s generic design is both basic and lightweight. As a result, it’s able to provide low power consumption for devices. This is ideal for the number of smaller, lower-powered devices that have appeared on the market over the past five years or so.
  • Ensures message delivery – MQTT is designed to ensure 100% message reliability under the worst network conditions. What’s more, you can add further message delivery reliability through its three different flags (from highest to lowest) – otherwise known as QOS (quality of service).
  • Battery friendly – MQTT consumes 170 times less energy on 3G networks and 47 times less energy on Wi-Fi networks. As a result, MQTT is considered a suitable IoT protocol if you’re looking to build devices that can stay connected to a battery for years and years.

The Cons of MQTT

Despite some undeniable positives of using an MQTT, there are also some clear disadvantages:

  • Doesn’t support streaming – MQTT doesn’t support streaming of any kind, either audio or video. Therefore, if you’re looking to stream anything on your IoT stack, you need to look elsewhere.
  • Not ‘developer friendly’ – This is the biggest red flag when considering what IoT protocol you want to use. If you’re using an MQTT as a remote control, it’s not developer friendly at all. Asynchronous publish-subscribe mechanisms in conjunction with user interface programming can be very cumbersome, i.e., when you send a command to your IoT device that potentially can take a long time to get a response to, what do you tell the user? Do you make them wait? And if not, how do you inform the user of actions that didn’t go as expected?. You can read more about this here.
  • Latency issues – While reliability is one of the MQTT’s main strengths, speed and latency are not. If these aren’t massive concerns for you, it shouldn’t present a problem. However, if poor latency could have a detrimental effect on your IoT device, it’s best to avoid MQTT for your IoT stack. The most obvious examples are remote control of a drone. Even a millisecond delay in action and video feed makes this use-case impossible. Another more widespread use case is interaction with a video-based doorbell with audio. A delay of seconds will be a great annoyance.

For more information, read our blog on the pros and cons of using MQTT in IoT.

AMQP (Advanced Message Queuing Protocol)

An AMQP (Advanced Message Queuing Protocol) is an open standard application layer IoT protocol.

Developers primarily use it for transactional messages between servers. Therefore, as you can imagine, it’s primarily used in the banking industry. 

The Pros of AMQP

Here are some of the pros of the AMQP as an IoT protocol.

  • It uses QoS to ensure message delivery – Much like MQTT, AMQP is extremely secure and reliable due to the use of quality of service (QoS) to ensure message delivery. 
  • Adaptable to other IoT standards – AMQP has the capability of being adapted to multiple IoT standards. That being said, it’s not very easy to do so.

The Cons of AMQP

Despite its high level of security and its adaptability to other standards, there are some drawbacks of the AMQP.

  • Heaviness – The AMQP suffers from being extremely heavyweight. As a result, it can’t be used in smaller or lower-powered IoT devices. This is why its use within IoT remains limited and primarily within the banking industry.
  • Not user friendly – Unlike HTTP – more on that later – AMQP is not user friendly. This, along with its heavy weight, puts most developers off using it as an IoT protocol.

HTTP (Hypertext Transfer Protocol)

HTTP gets a lot of criticism within the IoT world – with some seeing it as outdated when compared to the other IoT protocols and standards available.

However, it still has its merits for the right IoT device and industry application.

The Pros of HTTP

  • Addressing – HTTP uses an advanced scheme of addressing that’s extremely user friendly. It assigns IP addresses with recognizable names. This enables them to be easily identified on the world wide web. This is wildly different from the standard IP address, which is just a series of numbers.
  • The capability of processing large amounts of data – HTTP can process extremely large quantities of data. This makes it an invaluable IoT protocol within the world of manufacturing and 3D printing.
  • Flexibility – HTTP has the capability to download extensions or plugins when required, such as Flash players.

The Cons of HTTP

As mentioned, some IoT developers believe that HTTP is not suitable for use as an IoT protocol. Here’s why.

  • Data integrity Issues – There aren’t any encryption methods used in HTTP. This makes HTTP insecure and prone to data integrity issues. 
  • Data Privacy Concerns – If a hacker manages to intercept a request, they can view all the content present on the web page. On top of that, they can also gather confidential information present on the HTTP.
  • Heavy power consumption – HTTP uses more system resources, which leads to more power consumption. This is the main reason why developers often recommend going with a different protocol.


As you can see, as a standalone IoT protocol, HTTP has significant drawbacks (heavy on resources, unencrypted), which can make it inappropiate for many projects. However, when paired with Nabto Edge, these issues can be circumvented. 

For example, Nabto Edge allows secure remote access to your existing HTTP service. In turn, the built-in security provided by Nabto Edge protects your data integrity, resolving any data privacy concerns that come with using HTTP alone. 

Furthermore, Nabto Edge only requires minimal code changes. The existing TCP client only needs to connect to the local Nabto proxy TCP server started in the client application instead of the actual TCP server.

CoAP (Constrained Application Protocol)

CoAP (Constrained Application Protocol) is an application layer protocol. This was designed to address the needs of HTTP-based IoT systems.

As mentioned before, HTTP is often considered too heavy and power hungry for most IoT applications. CoAP has addressed this by moving the HTTP model into usage in restrictive devices and network environments – this gives it lower overheads while still enjoying the easy implementation that HTTP has.

The Pros of CoAP

We’ve already mentioned some of the pros of choosing CoA. The good news is that there are a couple more to note. 

  • Low overheads – as mentioned before, a significant advantage of using a CoAP as an IoT protocol is its low overheads. This means it uses very little power and enables long battery life.
  • Encryption – CoAP uses a better data encryption model than HTTP and MQTT. It can be combined with the DTLS (data transport layer security) encryption layer rather than SSL. As a result, it can provide greater data privacy and protection compared to other IoT protocols.

The Cons of CoAP

However, despite the above advantages, CoAP still has some weaknesses.

  • Message unreliability – CoAP adds a method to confirm messages are received. However, this does still not verify that it was received in its entirety and decoded properly.
  • Issues with NAT and firewalls – CoAP can have issues communicating with Network Address Translation (NAT) devices because the IP can become dynamic over time. For this reason, CoAP is only really suited to devices with resource limitations, such as IoT microcontrollers.


If you’re looking to improve your experience using CoAP, Nabto Edge supports CoAP using the Nabto Edge Direct protocol. 

What’s the benefit of this? Nabto Edge makes it possible to develop request/response clients via CoAP. However, it also cuts through firewall configurations set up by either peer. This greatly increases message reliability. Also, Nabto Edge packages CoAP with DTLS (authentication and encryption, etc.), so privacy is ensured out of the box. 

Here’s more information on the benefits of a CoAP and Nabto integration and how it works

IoT protocols Comparison Table

While we’ve made a comparison of IoT protocols, we’re well aware that it can be difficult to decipher which one is better when they’re not stacked up alongside each other.

So, as a TL;DR – take a look at this IoT protocols comparison table, which compares each protocol’s strengths, weaknesses, and specifications.














Low Latency

Messaging Type








Build-in Security

Easy to Build on


Bottom Line

Choosing the right IoT protocol for your next IoT application is crucial. That’s why this IoT protocols comparison article provides you with a simple rundown of the pros and cons of each major protocol.

While each protocol has specific limitations, Nabto can help overcome some specific barriers to implementation. 

Therefore, when choosing an IoT protocol – such as HTTP or CoAP – using Nabto Edge on top of these can help you achieve more. 

If you want to learn more about Nabto Edge – or any of our other IoT solutions – get in touch with us today.

Read Our Other Resources

We’ve published a range of IoT resources for our community, including:

Leave a Reply

Your email address will not be published. Required fields are marked *