Understanding MQTT
The Lightweight Messaging Backbone of IoT
The Internet of Things (IoT) connects billions of physical devices — from tiny environmental sensors to smart industrial machines. Because these devices often run on battery power and operate over unstable networks with limited bandwidth, traditional web protocols like HTTP are not always the best fit.
That is where MQTT (Message Queuing Telemetry Transport) comes in.
1. How MQTT Works: Pub-Sub vs. Request-Response
Both HTTP and MQTT run on top of a reliable TCP connection, but their communication models serve different needs:
- HTTP (Client-Server): Follows a unidirectional request-response pattern. A server cannot initiate contact; it only responds when a client asks.
- WebSocket: Provides a full-duplex, bidirectional raw communication channel over a single connection.
- MQTT (Publish-Subscribe): Decouples the sender and receiver through a central coordinator called a Broker. Devices publish messages to specific topics, and other devices subscribe to those topics.
Tip: MQTT can also run on top of WebSockets, making it easy to bypass restrictive firewalls and enable native browser dashboards to receive real-time IoT feeds.
[Publisher (Sensor)] ---> (Topic: /factory/temp) ---> [MQTT Broker] ---> [Subscribers (Apps / Cloud)]2. Low Overhead and Reliable Quality of Service (QoS)
MQTT’s binary header is extremely lightweight (as small as 2 bytes) compared to HTTP’s verbose text-based headers. This drastically cuts down bandwidth usage and power consumption.
Get Aravind sathyajith’s stories in your inbox
Join Medium for free to get updates from this writer.
To ensure messages reach their destination reliably across unstable networks, MQTT defines three Quality of Service (QoS) levels:
- QoS 0 (At most once / “Fire and Forget”): The message is sent with no confirmation step. Best suited for high-frequency telemetry data where occasional packet loss is acceptable.
- QoS 1 (At least once): The message is guaranteed to arrive, but duplicates may occur if acknowledgments are delayed.
- QoS 2 (Exactly once): Uses a four-step handshake to guarantee the message is delivered once and only once. Ideal for mission-critical commands or billing workflows.
3. Security and Broker Ecosystem
Because MQTT handles sensitive device data, securing the transport layer is critical:
- TLS/SSL Encryption: Data in transit is secured using SSL/TLS (versions 1.2 and 1.3) with certificate-based configurations (
certfile,keyfile), preventing eavesdropping and tampering. - Authentication: Brokers support client IDs, username/password credentials, token authentication, and X.509 client certificates.
Common MQTT Brokers
- Open Source / Self-Hosted: Eclipse Mosquitto, EMQX
- Enterprise Grade: HiveMQ
- Managed Cloud Platforms: AWS IoT Core, Azure IoT Hub
4. The Evolution: Why MQTT 5.0 Outperforms MQTT 3.1.1
Standardized by organizations like OASIS and IBM, MQTT 3.1.1 has been the industry standard for years. However, MQTT 5.0 was introduced to meet modern, cloud-native requirements.
Key MQTT 5.0 Enhancements
- Negative Acknowledgments (NACKs) & Reason Codes: Instead of silently dropping failed messages, MQTT 5 provides detailed error codes for faster troubleshooting.
- Topic Aliases: Replaces long topic strings with short two-byte integers to conserve network bandwidth on repeated transmissions.
- User Properties: Adds custom key-value metadata to packet headers without modifying the message payload (similar to HTTP headers).
- Payload Format Indicators: Allows the sender to declare whether the payload is raw binary or formatted UTF-8 data (e.g., JSON).
- Shared Subscriptions & Scalability: Distributes message loads across multiple client instances, making backend scaling seamless.
