You might have heard a lot about the MQTT protocol. The technology is over twenty years, and it is commonly used in communication networks of different types. The Internet of Things is one of the most popular application fields for this protocol. Here, we will provide insight into MQTT and its use in IoT applications. We will talk about the strong and weak points of this messaging standard and compare it with other competing technologies.
MQTT is a high-usage technology that was initially used to build connections within a satellite-based network. The lightweight protocol allowed for low bandwidth and power consumption.
The resource efficiency of MQTT played a major role in the system, working via the costly satellite link. Later on, MQTT has come into use with more accessible and low-cost communication channels and in various application areas, including the Internet of Things (IoT).
So what is the MQTT protocol? Are there advantages of using it for your IoT device instead of other protocols? What are these advantages? We will figure all this out in the article.
In 1999, IBM and Eurotech developers established the first version of Message Queuing Telemetry Transport, or MQTT. It is an open TCP/IP-based protocol that provides data exchange within a network of devices.
How does MQTT work? The protocol uses a publish-subscribe pattern and includes the following components:
A server, or broker, communicates with the clients (publishers and subscribers) via an internet connection or a local network. A publisher creates messages and publishes them on a certain topic. A subscriber receives the messages relevant to the topic to which it is subscribed.
Publishers and subscribers may switch roles, and sometimes MQTT clients take on the role of both. The number of publishers and subscribers can be unlimited. This will only depend on your server’s capacity. The clients have IDs by which the server identifies them.
Each topic comprises different subtopics, or levels, that form a hierarchy. By publishing messages to the exact subtopics, the publisher will be able to reach the intended recipient that has a subscription for the same topic levels.
Like any other binary protocol, MQTT has an edge over text protocols in machine-to-machine communication. Devices can send and receive the binary data without extra processing, which speeds up the messaging within the network.
MQTT transmits messages in packets. A packet consists of a:
Fixed header — This is a mandatory part of the message comprising a control header and a packet size. The minimum size is 2 bytes, and the maximum size is 5 bytes.
Variable header — This is an optional part of the message that provides additional information. Its size may vary, depending on the message type.
Payload — This is an optional part of the message with a maximum size of 256 MB. It may include different commands, like switching on/off, data exchange, and reading sensor data.
MQTT message structure
Depending on the CPU capabilities, MQTT can connect many thousands or even millions of devices. Besides the scalability, it is simple to use. It has low system requirements and high compatibility with Internet-connected applications.
That is why this network technology is so popular in the IoT. It also finds wide use in consumer electronics, automotive, and industrial applications.
To keep it simple, an IoT system is a network of connected devices communicating with each other. MQTT fits well into this concept. It is a light protocol with a fast response time. It makes the interaction between devices efficient, whatever the number of devices there is.
An attractive feature native to the MQTT protocol architecture is the minimum overhead. It ensures smooth data transfer with low bandwidth and reduces the load on the CPU and RAM.
We used MQTT as a light and energy-efficient communication protocol in our customizable GPS tracking solution. In this IoT project, a GPS tracker collects beacon data and sends it to the cloud with real-time display on the front end. MQTT was a good choice for a small-sized device with low power consumption.
The MQTT IoT protocol can transfer data even with unstable connections. It provides three options for Quality of Service (QoS), which is responsible for the message delivery. The choice of the option depends on data criticality and connection stability.
QoS 0 (set as default): A publisher sends a message without requesting guaranteed delivery. You can use it when the information transmitted is not critical and the connection is stable.
QoS 1: A publisher sends a message until it gets a delivery confirmation. You can use it when the information transmitted is critical and the connection is not stable. QoS 1 makes sure the subscriber receives the message.
QoS 2: A publisher sends a message only once with guaranteed delivery. You can use it when the information transmitted is critical, and the connection is not stable. QoS 2 makes sure the subscriber receives the message only once without its duplicates and overhead.
The open-source MQTT libraries and public brokers minimize the development costs and speed up the development process.
Freely available documentation and a large developer community make the implementation of MQTT protocol easy and possible in any environment, with either pre-made or custom libraries.
To deploy the MQTT protocol for IoT devices, you need a library and a broker that can be your local server, or a cloud-based one. The cost of deployment will depend on the choice of development tools and environment.
If you’re planning to use MQTT in your IoT application, you need to make sure the transmitted data is confidential and secure.
MQTT protocol security relies on the TLS/SSL cryptographic protocols and rather weak authentication. So MQTT is not among the top protocols in terms of security. You can introduce additional features to make MQTT well-secured and protect your IoT system against vulnerabilities.
You can add security mechanisms on different levels. For example, you can use a firewall for the broker security on the network level. Or you can use encryption algorithms to make MQTT secure on the application level. Implementation of end-to-end encryption enables confidential messaging between clients.
You can also use an access token to identify clients and prevent your system from unwanted access.
To improve authentication, you need to modify the protocol, and therefore the broker. Since an off-the-shelf broker does not allow for such modifications, you will have to deploy your own broker and customize it.
MQTT is a flexible and easy-to-use technology that provides effective communication within an IoT system. So, no wonder there are many popular IoT applications that use the MQTT protocol.
For example, the IBM Watson IoT Platform uses MQTT as the main communication protocol.
Amazon Web Services used MQTT as a basis for AWS IoT services. AWS IoT Core has an MQTT-based message broker, and it supports two levels of MQTT QoS.
In one of our IoT projects, we developed an AWS cloud solution for a solar monitoring system. We used MQTT to send solar battery data to the cloud dashboard.
Microsoft Azure offers the Azure IoT Hub service to build IoT applications using the MQTT protocol.
McAfee, Red Hat, Cisco, and IECC are also among the companies that have chosen MQTT for various tasks.
But is MQTT the best IoT protocol? Other communication protocols, such as HTTP, CoAP, AMQP have similar functionality. You can also use them in IoT applications.
To get a true picture of the performance and relevance of the MQTT protocol for Internet of Things, let’s put things into perspective.
Seamless communication is one of the key points of a well-functioning IoT system. You can achieve this by choosing a suitable communication protocol. MQTT can become a good option for your IoT product, but there are alternatives too.
HTTP vs. MQTT
The history of the Hypertext Transfer Protocol (HTTP) dates back to 1989. As an open standard, it was established by IETF and W3C in 1997. It uses TCP/IP as transport protocols, but the upcoming HTTP/3 will be UDP-based.
HTTP is a web protocol, and it is often used together with HTML to communicate with web browsers.
HTTP is a text protocol that works on a request/response model and uses URI or URL as message topics. A client sends a request to a server, and the server sends back a response. There are no specific limits to the message size; it is the server that places the limitations.
Unlike MQTT, HTTP is heavyweight because it is a text protocol. This implies the transmission of large-size messages and high overhead.
HTTP is heavy. It needs more power and memory resources than MQTT and any other lightweight protocol.
HTTP is an open standard
HTTP can be used with multiple devices. However, the more devices you add, the more load you put on the server. This negatively affects overall performance.
HTTP has no Quality of Service or other services, so it relies on TCP only as a guarantee of message delivery.
Originally, HTTP was designed with no security mechanisms. HTTPS is the encrypted HTTP that has the same level of security as MQTT. It uses TLS/SSL to authenticate clients and encrypt the transferred data.
CoAP vs. MQTT
Constrained Application Protocol (CoAP), developed by IETF, is a UDP-based protocol. It has much in common with HTTP, and these two protocols reliably work with each other.
CoAP is a binary protocol that supports two modes of communication: publish/subscribe and request/response. Like HTTP, it publishes messages to URI. The maximum message size is determined by the server capacity.
As intended for constrained devices, CoAP has a small message size and minimum overhead. Besides, CoAP uses UDP, which is a simple transport protocol that has no handshakes and guaranteed delivery. This also minimizes overhead and message size. In this case, CoAP has the upper hand over MQTT. Despite the lightweight architecture and low message size, MQTT runs on TCP that contains connection requests, handshakes, and a delivery guarantee.
CoAP is designed for resource-limited devices. So its major advantages are power efficiency and low memory consumption. Sometimes, CoAP can be more resource-efficient than MQTT.
CoAP is an open standard
Extremely low overhead makes CoAP a scalable protocol that can be used with a large number of connected devices.
It is not a strong point of this protocol. Unlike MQTT, CoAP has no Quality of Service, and it runs on UDP, which has no guaranteed delivery. To ensure delivery, it uses confirmable and non-confirmable messages.
AMQP vs. MQTT
Advanced Message Queuing Protocol (AMQP) was developed at JPMorgan Chase & Co. in 2003 as an open messaging protocol for banking systems.
AMQP is a binary TCP-based protocol that can use either a publish/subscribe model or a request/response pattern.
The exchange component of the protocol gets a message from the publisher and routes it to a queue. The queue stores the message until the client can process it.
AMQP is light, and it doesn’t have much overhead. But it puts a strong emphasis on message delivery that adds overhead and makes it high compared to MQTT.
AMQP doesn’t take too much RAM and CPU resources. However, it consumes them more than MQTT due to a more complex messaging system.
AMQP is an open standard
AMQP is scalable, and it allows for using multiple connections.
Both protocols, AMQP and MQTT, have features and opportunities to provide reliable messaging. They run on TCP and apply QoS to provide stable and ensured data transfer. AMQP provides two levels of QoS, while MQTT has three of them. Besides, MQTT has the so-called “last will and testament” option. It guarantees the delivery of a message to the client in case of disconnection.
Throughput and Latency Benchmarking
To provide a clearer picture of MQTT performance in comparison with its alternatives, we carried out our own benchmark analysis. We created a testing environment to measure latency and throughput. These are the measurable parameters that highlight a protocol’s performance.
We defined throughput as the maximum number of messages per second sent from the publisher to the broker or server. Measuring the latency, we took the minimum server’s response time. We used Apache JMeter and its plugins as a load testing tool.
The publisher's hardware ran on a single-core processor with an operating frequency of 700 MHz and 512 MB of RAM. The server hardware used a single-core processor with 2GB RAM. The payload size of each message that we sent using the protocols was 64 KB.
In our benchmarking, we considered MQTT with different levels of QoS.
Throughput and latency comparison chart
According to our benchmarking results, CoAP showed outstanding performance in throughput. It managed to send twice as many messages as MQTT with QoS 0. HTTP and MQTT with QoS 1 and QoS 2 were on much the same level with the lowest throughput.
The same protocols (HTTP; MQTT with QoS 1 and 2) had delays in the server’s response time. MQTT with QoS 0, CoAP, and AMQP showed zero latency.
There are dozens of communication protocols designed for various needs and purposes. Many of them can be used for IoT projects. Among the worth-mentioning protocols are the following:
STOMP (Simple (or Streaming) Text Oriented Message Protocol), a TCP-based text protocol that is very similar to HTTP. STOMP uses a broker that sends messages to clients. STOMP supports a wide range of languages and platforms. It is simple and easy to implement.
DDS (Data Distribution Service), a publish/subscribe protocol that can be used in large-scale, high-performance, and real-time systems. DDS controls message delivery with the help of Quality of Service. The protocol has libraries for the most popular programming languages. It is available in both open-source and commercial versions.
XMPP (Extensible Messaging and Presence Protocol), an open client-server standard based on XML. XMPP uses a publish/subscribe mechanism, and it runs over TCP and HTTP. It has a rich selection of free and open-source libraries and servers.
SSE (Server-Sent Events), a part of HTML5. SSE uses HTTP as a transport protocol and provides one-way communication from server to client. A client sends a request, and the server pushes data once the connection is open.
LwM2M, or Lightweight M2M, is an open protocol for IoT device management. LwM2M interoperates with CoAP as it is light and energy-efficient and is often used for constrained devices. There are many available LwM2M specifications, SDKs, and implementations.
According to Google Trends, the level of interest in MQTT has quadrupled worldwide in the past 5 years. This trend is supported by the high-speed expansion of the IoT market and a persistent tendency towards simplicity and resource efficiency.
MQTT and IoT popularity dynamics
Simple architecture, easy implementation, reliable message delivery, and high scalability are the strong benefits that will maintain an interest in the MQTT protocol for IoT.
OASIS released the latest version of the protocol, which is MQTT 5.0, in March 2019. The new features added to v5.0 are message expiry, shared subscription, and topic alias. They optimized MQTT performance and made it more attractive for IoT developers.
MQTT is a strong competitor in the field of data transfer and network communication, although it is not number one at every point. For example, CoAP outperforms MQTT in throughput and overhead. And AMQP takes the lead in security.
However, there are several key benefits that MQTT provides to its users:
All this makes MQTT a well-suited option for your IoT device. In our IoT solution development, we use MQTT as part of the protocol stack. This is one of the favorite choices for low-power wireless devices with unstable connections.
Also Published At: https://www.integrasources.com/blog/mqtt-protocol-iot-devices/