MQTT vs AMQP for IoT
Understanding the Differences Between MQTT and AMQP
MQTT was designed for the Internet of Things (although it wasn’t called that at the time). Both MQTT and AMQP run over TCP connections, both are client-server in architecture and bi-directional.
AMQP was designed to provide general purpose high performance enterprise messaging, whereas MQTT was created as an IoT protocol. AMQP has many features to cater for a range of messaging scenarios and is more complex than MQTT. The core AMQP destinations for messages are queues, but there are several different methods of routing messages. MQTT has just one routing mechanism - topic subscriptions.
What is MQTT?
MQTT is a communication protocol with features specifically targeted at IoT solutions:
Uses TCP connections, for reliability (assured delivery and packet error checking), fragmentation and ordering.
Aims to minimize data overhead of each MQTT packet.
The last known good data value for a device can be stored (retained messages).
Notifications when client unexpectedly disconnects (will message) to allow client state to be monitored.
Bi-directional message flow - data from and commands to devices can use the same TCP connection.
Publish subscribe routing, which allows the easy addition of more consumers and producers of data.
MQTT Publish / Subscribe Architecture
The MQTT commands are CONNECT, SUBSCRIBE, PUBLISH, UNSUBSCRIBE and DISCONNECT. MQTT Topics are the unit of distribution, 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 predefined: applications can create them simply by using them.
What is AMQP?
AMQP is a messaging protocol which was created to be a non-proprietary method of connecting applications. AMQP 0.9.1 is a product of the AMQP working group, whereas AMQP 1.0 is an OASIS standard, as are MQTT 3.1.1 and 5.0. AMQP 1.0 is quite a different protocol from 0.9.1, which complicates AMQP support. AMQP supports multiple routing topologies, which are mainly application-defined. This gives flexibility at some cost of application setup. Here is an example routing showing the fundamental components:
AMQP fundamental components
An application has to create a queue if it doesn’t already exist, and then bind that queue to an exchange. The exchange is the target of the message publish operation, which then routes messages to queues. There are four predefined exchange types:
Direct - routing key matches queue name
Fanout - every queue bound to it receives every message
Topic - messages are routed to queues based on the pattern used when binding the queue to the exchange
Headers - similar to the topic exchange but uses message headers in the matching algorithm
This is an AMQP topology which could approximate an MQTT broker configuration:
AMQP Topology
AMQP has features which do not exist in MQTT or only in MQTT 5.0 such as:
Message headers (in MQTT 5.0)
Multiple lightweight connections over one TCP connection (channels)
Virtual hosts (isolated server environments)
Comparing MQTT and AMQP
| MQTT | AMQP | |
|---|---|---|
| Full name | MQTT (the OASIS standardization group decided it would not stand for anything) | Advanced Message Queuing Protocol |
| Architecture | Publish subscribe (MQTT does have a request/reply mode as well) | Queues, multicast (fanout), publish subscribe, request reply |
| Command targets | Topics | Exchanges, Queues |
| Underlying Protocol | TCP/IP | TCP/IP |
| Secure connections | TLS + username/password (SASL support possible) | TLS + username/password (SASL support possible) |
| Client observability | Known connection status (will messages) | Unknown connection status |
| Messaging Mode | Asynchronous, event-based | Synchronous and asynchronous |
| Message queuing | The broker can queue messages for disconnected subscribers | Core capability, flexible configuration |
| Message overhead | 2 bytes minimum | 8 bytes (general frame format) |
| Message Size | 256MB maximum | 2GB theoretical, 128MB max recommended |
| Content type | Any (binary) | Any (binary) |
| Topic matching | Level separator: / Wildcards: + # | Level separator: / Wildcards: + # |
| Reliability | Three qualities of service: 0 - fire and forget 1 - at least once 2 - once and only once | Two qualities of service: -without acks (=0) - with acks (=1) |
| Connection “multiplexing” | No | Yes - channels |
| Message attributes | MQTT 5.0 only | Yes |
| Object persistence | Yes | Yes |
The Advantages and Disadvantages of MQTT
There are two features of MQTT which don’t have a direct counterpart in AMQP: will and retained messages. These are especially useful in IoT applications for which they were designed. MQTT is lighter in bytes consumed on the wire than AMQP as it is more focussed on IoT solutions. This can be especially useful for very low powered devices and unreliable networks.
MQTT is easier to configure and get started. One of the greatest attributes of MQTT is the simplicity and flexibility with which solutions can be created. The publish-subscribe paradigm allows many clients to produce and share information with each other as well as back end systems.
The Advantages and Disadvantages of AMQP
AMQP provides more capability than MQTT for general purpose message queuing, at the expense of some efficiency and complexity. AMQP was not targeted at IoT solutions, lacking will and retained messages. The configuration of routing topologies is open to error which can’t happen in the simpler MQTT world.
The fact that AMQP 0.9.1 and 1.0 are so completely different does lead to some complexity in this solution space - version 1.0 is the only one standardized at OASIS.
Conclusion: MQTT or AMQP - Which is Better for IoT?
AMQP 0.9.1 was not created for IoT use cases. It is a general purpose message queuing protocol that is more complex than MQTT, and a greater overhead on the wire for IoT. MQTT was designed for IoT - especially connecting devices to a central IT infrastructure, so it really does shine at that. Its simplicity but effectiveness in building IoT solutions makes it the best choice.
There are many IoT protocols out there and understanding what suits best for your IoT project is essential.
Additional Reading
Read the blog MQTT Vs. HTTP for IoT to learn the differences between MQTT and HTTP protocol or if you are contemplating using MQTT or HTTP for your use case.
Read the blog MQTT Vs. ZeroMQ for IoT to learn the differences between MQTT and ZeroMQ protocol.
Read the blog MQTT Vs. CoAP for IoT to learn the differences between MQTT and CoAP protocol.
Read the blog Transferring Data from Modbus to MQTT Broker for Advanced IIoT Data Use Cases to learn the differences between MQTT and Modbus TCP.
Watch the Video
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.
