Let’s dive into MQTT, how to ensure its security, and examples of the protocol to see how it has rapidly gained popularity in the IoT field.
In today’s world, there are billions of smart devices. Imagine if these devices were all interconnected and could communicate with each other like their users, forming a global network. This is what is commonly referred to as the Internet of Things, or IoT. The IoT has fundamentally changed the IT world and our way of innovating. When exploring the IoT, it is essential to consider its performance and security issues.
The Message Queue Telemetry Transport Protocol (MQTT)
MQTT is a lightweight messaging protocol based on a publish/subscribe model for machine-to-machine (M2M) communication over TCP/IP. The protocol provides telemetry technology, and MQTT developers are working hard to connect the ever-growing internet world, which is expected to generate a more diverse array of smart devices. The first version of the MQTT protocol was written by IBM’s Stanford-Clark and Arlen Nipper.
Why MQTT?
MQTT has been used in Facebook’s messaging application, allowing it to maintain a long connection with the server without consuming too much power; it only requires very low network bandwidth, and the code footprint is also minimal; it transmits data over widely distributed and intermittently available networks. These characteristics give MQTT a significant advantage in applications on remote devices with limited memory and processing power.
Additionally, MQTT has some very notable features:
-
Open source, free, and easy to use
-
Follows one-to-many, publish/subscribe model
-
Streamlined message headers
-
Provides multiple quality of service levels
-
Simple message commands
-
Does not impose restrictions on data types and formats, maintaining flexibility
-
Messages can be retained
-
Clean sessions and persistent connections
-
Last Will and Testament flag
Comparison of MQTT and HTTP:
|
MQTT |
HTTP |
|
|
Design |
Data-centric |
File-centric |
|
Model |
Publish/Subscribe |
Request/Response |
|
Complexity |
Simple commands |
Complex |
|
Message Size |
Small, compressed binary size is 2 bytes |
Larger, as headers are in text format |
|
Service Level |
3 QoS levels |
Same service level for all messages |
|
Distribution |
One-to-many |
One-to-one |
An example of the MQTT topology:
Quality of Service Levels
The QoS value determines how each message will be delivered, and each sent message requires a mandatory QoS setting.
Level 0 (At most one message delivery)
When the QoS value of a message is set to 0, no acknowledgment is required, and no retransmission mechanism is defined. The message either successfully reaches the broker (MQTT broker) once or it does not reach at all. If the client disconnects or the server fails, QoS 0 messages will be lost, and the MQTT layer will not attempt to retransmit the message. From a performance perspective, this is the fastest way to send messages using MQTT. Only the MQTT command PUBLISH is used in level 0; other commands are not utilized.
QoS 1 (At least one message delivery)
The MQTT client or server will attempt to deliver the message at least once, but duplicates may occur. When the broker receives the message, it will send an acknowledgment command PUBACK. If PUBACK is not received, the sender will resend the message using the DUP (duplicate) flag. When a message with the DUP bit is received, the broker will republish the message to all subscribers and send the PUBACK acknowledgment back to the sender. The communication mechanism of level 1 is achieved through MQTT message persistence. When PUBLISH occurs, the message will be stored in the persistent layer (such as a disk) and deleted upon receiving PUBACK. QoS 1 messages have a message ID in the message header.
QoS 2 (Exactly one message delivery)
On the basis of QoS 1, an additional control flow ensures that messages are delivered exactly once, without duplication. Messages are sent in the PUBLISH flow and stored by the client in the persistent layer. A PUBREC message is sent in response to PUBLISH. At the same time, the message is locked on the server. Upon receiving PUBREC, PUBREL is sent back to the server. When PUBREL is received, the broker sends the message, returns PUBCOMP, and discards the stored state. QoS 2 messages have a message ID in the message header.
The purpose of MQTT is to provide lightweight communication for IoT, but security comes at the cost of increased processor usage and communication overhead. This is why there are only a few security mechanisms in the protocol. However, many implementations of MQTT utilize security standards such as SSL/TLS.
Security in MQTT is divided into multiple layers:
Network Layer: Provides secure connections for communication using physically secure networks or VPNs.
Transport Layer: Uses TLS/SSL for transport encryption, ensuring communication is encrypted and authenticated.
Application Layer: The protocol has a client ID, and username/password credentials provide device authentication. Another way is to encrypt the payload without extensive transport encryption.
MQTT Practice – Home Monitoring
A home monitoring system is a typical example of an application based on MQTT. For instance, the current temperature of an indoor heater can be sent to the device upon request.
Like any other application, when it comes to communication between two applications or devices, there is a possibility of communication failure, making it crucial to monitor the application to ensure effective operation and a good user experience.
Catchpoint currently can monitor the performance and availability of IoT devices using the MQTT protocol. MQTT testing can be done by publishing and subscribing to messages on specified topics, and communication time can be measured.
In today’s world, there are billions of smart devices. Imagine if these devices were all interconnected and could communicate with each other like their users, forming a global network.
Long press the QR code ▲
Subscribe to the “Architect’s Little Secret Circle” public account
If inspired, please give me a thumbs up, thank you ↓