MQTT concretely allows devices to send information on a given subject to a server that functions as a message broker. The broker pushes this information to customers who have previously subscribed. For the user, a subject looks like a hierarchical path. Customers can subscribe to a specific level in a subject’s hierarchy or at multiple levels if they use a wildcard.
How MQTT works
An MQTT session is divided into four steps: login, authentication, communication, and termination.
A client begins by creating a TCP / IP connection to the broker using either a standard port or a custom port defined by the broker’s operators. When connecting, the server may continue an old session if it recognizes a previously used client identity.
The standard ports are 1883 for unencrypted communication and 8883 for encrypted communication using SSL / TLS. During initial SSL / TLS handshake, the client validates the server certificate to authenticate the server. During this exchange, the customer can also provide the broker with a client certificate that the broker can then use to authenticate the client. Although not specified in the MQTT standard, brokers usually support client authentication with their SSL / TLS certificates.
The MQTT protocol is primarily intended for devices with limited resources, SSL / TLS is not always available and in some cases it is not desired. The client then authenticates by sending a username and password in plain text to the server during the CONNECT / CONNACK packet sequence.
Some brokers, especially open brokers published on the Internet, accept anonymous customers. In this case, the username and password are simply left blank.
MQTT is considered a lightweight protocol because the messages all have a small software footprint. Each message consists of a fixed header (2 bytes), an optional variable header, a message payload limited to 256 MB, and a quality of service level. The three quality of service levels determine how the MQTT protocol handles content. Although higher levels are more reliable, they are also more greedy in terms of latency and bandwidth. Subscribed customers can specify the maximum QoS level they wish to receive.
The simplest level of quality of service is unconfirmed service (Unacknowledged Service). This level uses a sequence of PUBLISH packets: the publisher sends a message to the broker only once and the broker transmits this message only once to the subscribers. No mechanism guarantees the reception of the message and the broker does not record it either. This level of quality of service is also called “QoS Level 0” or QoS0, or “At most once”.
The second level of service is the Acknowledged Service. This level uses a sequence of PUBLISH / PUBACK (Publish Acknowledge) packets between the publisher and its broker, as well as between the broker and subscribers.
A confirmation packet verifies that the content has been received and a mechanism for returning the original content is triggered if the acknowledgment is not received in a timely manner. This means that the subscriber can receive multiple copies of the same message. This level of quality of service is also called “QoS Level 1” or QoS1, or “At least once” (at least once).
The third level of QoS is the Assured Service. This level delivers the message with two pairs of packets. The first is called PUBLISH / PUBREC and the second is PUBREL / PUBCOMP. Both pairs ensure that regardless of the number of attempts, the message will only be issued once. This level of quality of service is also called “QoS level 2” or QoS2, or “Exactly once” (exactly one time).
During the communication phase, a client can do the following: publish, subscribe, unsubscribe, or ping.
The publish operation sends a binary block of data (the content) to a topic defined by the publisher. MQTT supports BLOB messages up to 256 MB in size. The content format depends on the application. Subscriptions to topics are done using a pair of SUBSCRIBE / SUBACK packets. The unsubscription is done in a similar way using a pair of UNSUBSCRIBE / UNSUBACK packets.
Strings describing a subject form a tree by using the slash (/) as the separator character. A customer can subscribe to entire branches of a subject’s tree (or unsubscribe) using the following two wildcard characters: the plus sign (+), which corresponds to a single level, and the pound sign (#) for several levels. A special character, the dollar ($), allows you to exclude a topic from any subscription using a wildcard at the root. Typically, the dollar is used to carry specific system or server messages.
A client can perform a fourth operation during the communication phase: he can ping the broker’s server using a sequence of PINGREQ / PINGRESP packets. Roughly translated, it means “ES-TU LIVING / YES I AM LIVING”. This operation has no other function than to maintain an active connection and to make sure that the TCP connection has not been cut by a gateway or a router.
When an editor or subscriber wishes to terminate an MQTT session, he sends a DISCONNECT message to the broker and then terminates the connection. This is called a graceful shutdown because it allows the client to easily reconnect by providing their client identity and resume the session where they left off.
In case of sudden disconnection not leaving time for the publisher to send a DISCONNECT message, the broker can send subscribers a message from the publisher that the broker had previously cached. The message, called last will and testament , indicates to subscribers the measures to be taken in case of unexpected termination of the publisher.
Challenges in using MQTT for the Internet of Things
Because MQTT does not include security mechanisms, this protocol is traditionally used in secure networks for specific application purposes. The structure of MQTT subjects can easily become a huge tree. However, there is no simple way to divide it into smaller logical domains that could be federated. This makes it difficult to create a scalable, scalable MQTT network because as the subject tree grows, complexity increases.
MQTT has another drawback: its lack of interoperability. Since the payload of the messages is binary, with no information about their coding, problems can arise, especially in open architectures where applications from different manufacturers are supposed to work seamlessly with each other.
As discussed above, the MQTT protocol includes minimal authentication features. Username and password are sent in clear and any secure use of MQTT requires to implement SSL / TLS, which unfortunately is not a lightweight protocol.
Authenticating clients with client certificates is not an easy process and MQTT does not allow, except through out-of-band proprietary means, to determine who owns a subject and who can publish information to it. It is therefore very easy to inject malicious messages, voluntarily or otherwise, into the network. In addition, there is no way for the receiver to know who sent the original message unless this information is contained in the message.
The proprietary security layer that needs to be added to MQTT therefore increases the software footprint and complicates the implementation of the protocol.
Despite these considerations, many experts believe that MQTT will play an important role in the Internet of Things , facilitating operations such as inventory tracking, automotive telematics, resource monitoring and medical networks.
The protocol is constantly improving and now supports WebSockets, another protocol that enables two-way real-time communication between clients and brokers.
Other transfer protocols for devices with limited resources are under study. Like the Constrained Application Protocol (CoAP), which uses a request / response type of communication model. Or the Advanced Message Queuing Protocol (AMQP), which, like MQTT, relies on a publication / subscription model.