Skip to content

MQTT Vs CoAP for IoT

by Ian Craggs
13 min read

Understanding the Differences Between MQTT and CoAP

MQTT is a client-server protocol designed for the Internet of Things (although it wasn’t called that at the time), with publish-subscribe messaging as its core. The MQTT server, also known as the broker, allows you to inspect and manage connected IoT devices and messages. The Broker can also provide shared services, such as retained messages. There are many client libraries and brokers available: free, open source and commercially supported.

CoAP (The Constrained Application Protocol) is also a client-server protocol designed for the Internet of Things. It too targets constrained devices, but is modeled on the World Wide Web of resources (URIs) and HTTP. It uses GET, POST, PUT and DELETE verbs like HTTP, which it can interoperate with through proxies. URIs represent device state, but devices can be a CoAP client or server. For example, a client posts updates to a server or a server responds to GET requests from clients. MQTT is a layer over TCP, whereas CoAP works over UDP. Some features of TCP that are not in UDP, such as fragmentation, have to be re-implemented in CoAP. On the other hand, CoAP is able to use the multicast feature of UDP, which does not exist in TCP. Like MQTT, CoAP has implementations of clients and servers in multiple languages.

What is MQTT?

MQTT is a communication protocol with features specifically targeted at IoT solutions. MQTT:

  • Uses TCP connections for reliability (assured delivery and packet error checking), fragmentation, and ordering.

  • Aims to minimize the data overhead of each MQTT packet.

  • Can store the last known good data value for a device (retained messages).

  • Can send Notifications when clients unexpectedly disconnect to allow client state to be monitored (will messages).

  • Uses bi-directional message flow - data from and commands to devices can use the same TCP connection.

  • Employs publish-subscribe routing, which makes it easy to add more consumers and producers of data.

HiveMQ Broker and Publish - Subscribe StructureThe MQTT commands are CONNECT, SUBSCRIBE, PUBLISH, UNSUBSCRIBE, and DISCONNECT. Topics are the distribution units, to which clients can PUBLISH and SUBSCRIBE. All authorized subscribers to a topic will receive all messages published to it. MQTT topics do not have to be pre-defined: applications can create them simply by using them.

What is CoAP?

RFC 7252 defines the core of the CoAP protocol. It was designed for machine-to-machine (M2M) applications such as smart energy and building automation, supporting constrained devices and networks while cooperating with HTTP through simple proxies. CoAP reuses the web concepts of URIs and Internet media types to enable the building of IoT solutions.

The core interaction between clients and servers is request-response:

The core interaction between clients and servers is request-responseServer resources are discovered by sending a GET request to the /.well-known/core path. Using UDP multicast you can discover servers in a group, or to send requests to multiple endpoints at the same time – to turn a set of lights on or off for instance.

The observe extension allows clients to “subscribe” to a server URI, so that notifications are sent whenever the state represented by that URI changes:

The observe extension allows clients to “subscribe” to a server URINon-confirmable messages have no acknowledgement, similar to QoS 0 in MQTT. Message retries implement reliability. If no acknowledgment is received after sending a confirmable message, that message is retried at increasing intervals until it is received or reaches a timeout. Non-confirmable messages use a client-generated token of up to 8 bytes in length to match responses to requests. To de-duplicate confirmable messages, the receiver uses a combination of message ID and the source endpoint (IP address in UDP). It is possible to use transports other than UDP for CoAP, although that is far less common than UDP. TCP and SMS are possible.

MQTT and CoAP Comparison Summary

Full name MQTT (the OASIS standardization group decided it would not stand for anything)The Constrained Application Protocol
Architecture Client/ServerClient/Server
Command targets TopicsURIs
Underlying transport TCPUDP
Default insecure TCP port 18835684
Default secure UDP port 88835684
Secure connections TLS + username/password (SASL support possible)DTLS (TLS for UDP)
Client observability Known connection status (will messages)None
Retained messages YesNo
Messaging Mode Asynchronous, event-basedSynchronous (or asynchronous with observe extension)
Message queuing The broker can queue messages for disconnected subscribersNone
Message overhead 2 bytes minimum4 bytes minimum
Message Size 256MB maximumLimit of underlying transport - RFC 7252 suggests 1152 bytes for UDP if nothing is known about the target.
Message fragmentation Reliant on TCPNo (RFC 7959 proposes an extension for this)
Content type Any (binary)Any
Pub/sub topic matching Level separator: /Wildcards: + #No pub/sub (but extensions have been proposed)
Message distribution One to many, one to oneOne to many, one to one
Reliability Three qualities of service: 0 - fire and forget 1 - at least once 2 - once and only onceConfirmable or not (roughly equivalent to QoS 1 and 0)

MQTT Performance Vs. CoAP Performance

These are the approximate packet sizes measured with Wireshark for MQTT and CoAP including TCP and UDP overheads for a payload of 256 bytes. The CoAP scenario is a synchronous GET plus the response with the data - there is no connection to establish or subscription to be sent. The MQTT messages are sent at QoS 0 and the CoAP messages without confirmation.

MQTT (TCP) Bytes CoAP (UDP) Bytes
Establish connection 166None
Subscribe 159None
For each message published 388312+75 (request + response)
Sum for 1 message 1101387
Sum for 10 messages 80853870
Sum for 100 messages 7792538700

As you would expect, the overheads for UDP are less than TCP in this simple scenario. However, to reach a similar level of capability as the MQTT TCP connection (larger packets, reliable transmission), more complex CoAP behavior is needed.

The following are figures for an MQTT application using a local HiveMQ broker. The application sends and receives a message before the next round trip starts. A similar approach is taken with CoAP using the Eclipse Californium Java implementation of client and server – it issues a GET to receive the data from the server before the subsequent GET. In each case, the messages are 256 bytes.

No. messages Protocol Msgs per second Avg round trip time (ms)
10000 MQTT - QoS 11,2340.81
10000 MQTT - QoS 018,4160.054
10000 CoAP8,7290.1145

These are simple scenarios. In both cases, one can expand throughput by tailoring the applications and servers to the solution needed. These figures are just for illustration.

The Advantages and Disadvantages of MQTT

Having a centralized MQTT broker means that IoT services are available in a ready-made and portable form, so:

  • Applications can track messages and communicate the availability of services

  • Retained messages provide the last known good value for data streams

One of the greatest attributes of MQTT is the flexibility with which you can create solutions. The publish-subscribe paradigm allows many clients to produce and share information with each other as well as back end systems. Brokers can be chained together, and MQTT gateways connected to cloud services just by mapping the flow of messages through topics. Over-the-air updates of firmware and configurations can be broadcast to devices.

The inbuilt queueing of MQTT brokers can deal with connection interruptions and provide buffering for constrained devices that don’t have the capacity to do it themselves.

The Advantages and Disadvantages of CoAP

CoAP behaves similarly to HTTP, which is familiar to many developers and users. Whether that suits more or less than MQTT’s publish/subscribe can be a matter of taste.

With CoAP using UDP it has smaller overheads than TCP, but a smaller maximum payload and less reliability. It can use the multicast ability of UDP for certain efficient functions. CoAP was designed for IoT, so it does a good job of supporting low-powered devices.

Some downsides of CoAP using UDP are:

  • It can be more difficult to traverse firewalls, unlike MQTT that uses WebSockets.

  • It can be used in DDoS attacks if internet-facing.

CoAP solutions are very flexible since the definition of client and server are dynamic. In MQTT, these elements are fixed. That also means no CoAP standard broker exists with general services that can be relied on.

Conclusion: MQTT Vs. CoAP – Which is Better for IoT?

The out-of-the-box features MQTT brokers provide must be implemented by CoAP applications. Since some MQTT brokers have standard behavior and cloud services available, IoT solutions can be built rapidly.

CoAP could be well-suited to an edge, on-premises, or mesh network that connects to a gateway, which then uses MQTT to the cloud for IoT services. You can also use MQTT for this purpose. There is also an MQTT-like competitor for CoAP, MQTT-SN, which is in the process of being standardized.

If you want to learn more about how MQTT can increase your efficiency and bottom line, check out these resources:

Watch the Video

  • 00:18 - What is MQTT?
  • 01:18 - What is CoAP?
  • 02:15 - The CoAP observe extension
  • 02:27 - MQTT vs. CoAP Comparison Summary
  • 05:08 - MQTT vs. CoAP. Which protocol is better for IoT?

Ian Craggs

Ian Craggs works for IBM, and has been involved with MQTT for more than 10 years. He wrote the IBM MQTT server Really Small Message Broker which became the inspiration for the Eclipse Mosquitto project. He contributed C client libraries to the Eclipse Paho project at its onset and is now the project leader.

Related content:

HiveMQ logo
Review HiveMQ on G2