With the rapid growth of the Internet of Things, massive numbers of devices require an efficient, reliable, and low-overhead communication method. The MQTT protocol has emerged as the de facto standard data exchange protocol in the IoT field. This article systematically explains the principles, framework, application scenarios, and configuration advantages of MQTT across four dimensions.
MQTT stands for Message Queuing Telemetry Transport. Invented by IBM in 1999 for remote oil pipeline monitoring — a scenario with severe constraints on network bandwidth and device power consumption — MQTT has since evolved over more than two decades to become an ISO standard (ISO/IEC 20922), widely used in IoT, mobile internet, connected vehicles, and other fields.
MQTT's core characteristics can be summarized in three points:
Lightweight: Minimal protocol header overhead (fixed header is only 2 bytes), suitable for low-bandwidth, high-latency networks
Publish/Subscribe model: Completely decouples data producers from consumers, breaking the rigid structure of traditional point-to-point communication
Based on TCP/IP: Inherits TCP's reliable transmission characteristics while providing configurable delivery guarantees through Quality of Service (QoS) levels
Understanding MQTT hinges on mastering three basic concepts: topics, publishers, and subscribers. Together, they form the protocol's fundamental operating framework.
Topics — Data Exchange "Channels"
In MQTT, data is not sent directly to a specific device's IP address. Instead, it is published to "topics." A topic is a UTF-8 string using a slash-delimited hierarchical structure, for example factory/workshop_A/temperature_sensor. This design enables clear, scalable data organization and supports wildcards (+ for single-level, # for multi-level) for batch subscriptions.
Publishers — Data Producers
Any device capable of connecting to an MQTT broker can act as a publisher. A publisher needs to do only one thing: send a message to a specified topic. It does not need to know who will receive the message, how many devices will receive it, or where those devices are — the publisher's responsibility ends there.
Subscribers — Data Consumers
A subscriber tells the broker: "I am interested in certain topics; please push new messages to my device." A device can subscribe to multiple topics, and multiple devices can subscribe to the same topic. Subscribers likewise do not need to know which specific publisher the data came from.
Broker — The Central Hub
The broker is the core server of the MQTT protocol, responsible for receiving all published messages, maintaining subscription relationships, and distributing messages to all matching subscribers. The broker completely decouples publishers and subscribers in time, space, and data format.
An analogy: Traditional TCP point-to-point communication is like a phone call — both parties must be online simultaneously, know each other's numbers, and communicate one-to-one. MQTT's publish/subscribe model is more like a social media feed — the author (publisher) simply posts content to their account (topic), and followers (subscribers) receive the post. The author does not know who is reading, readers do not need to know the author, and the platform (broker) handles all distribution logic.
A typical MQTT communication flow includes the following steps:
Establish Connection: A client (which can be either a publisher or subscriber) initiates a TCP connection to the broker, then sends a CONNECT packet for protocol handshake. The connection may carry parameters such as username, password, will message (published on abnormal disconnect), and keep-alive interval.
Subscribe to Topics: A subscriber sends a SUBSCRIBE packet to the broker, with a list of topics and the desired Quality of Service (QoS) level for each. Once the broker acknowledges, the subscription relationship is established.
Publish Messages: A publisher sends a PUBLISH packet to the broker, specifying a topic and message payload. The broker forwards the message to all matching subscribers based on subscription relationships.
Keep-Alive Heartbeat: Clients periodically send PINGREQ packets; the broker replies with PINGRESP to maintain connection liveness and detect abnormal disconnections.
Disconnect: The client sends a DISCONNECT packet to gracefully close the connection.
MQTT provides three levels of Quality of Service, allowing users to choose between transmission reliability and overhead based on the scenario:
| QoS Level | Name | Mechanism | Suitable Scenarios |
|---|---|---|---|
| 0 | At most once | Fire-and-forget, no acknowledgment, no retransmission | Environmental sensor data (loss of a single reading is acceptable) |
| 1 | At least once | Acknowledgment after sending, possible duplicate reception | Control commands requiring delivery confirmation where duplicates are tolerable |
| 2 | Exactly once | Four-way handshake ensures unique delivery | Payment instructions, critical alerts (neither loss nor duplication allowed) |
Note that QoS is negotiated separately between publisher and broker, and between broker and subscriber. The actual guarantee for a message traveling from publisher to subscriber is the minimum of the QoS levels on the two segments.
MQTT's original design closely matches IoT requirements. Its suitable scenarios have distinctive characteristics:
1. Low-Bandwidth, High-Latency Networks
In 2G/3G/4G/5G, satellite, NB-IoT, and similar environments, bandwidth may be as low as tens of kbps, and latency as high as several seconds. MQTT's small header (2 bytes) and streamlined retransmission mechanism make it far superior to text-based protocols like HTTP in such environments.
2. Resource-Constrained Devices
Embedded devices often have only tens of KB of RAM and limited flash memory. MQTT client implementations are extremely lightweight and can run on microcontroller-level hardware (e.g., ARM Cortex-M, ESP8266).
3. Bursty, Non-Continuous Data Transmission
Sensors do not need to report data every millisecond; they send only when a state changes or on a periodic timer. MQTT's keep-alive mechanism allows devices to remain in low-power sleep most of the time, waking only when data is ready.
4. One-to-Many Communication Needs
A single command needs to be sent to hundreds or thousands of devices (e.g., remote updates, batch control), or data from many sensors needs to be aggregated to a single monitoring center. MQTT's publish/subscribe model naturally supports this fan-out and fan-in.
5. Dynamic, Unpredictable Topologies
Devices frequently join, leave, or move (e.g., connected vehicles, wearables). MQTT uses a central broker for management; new devices simply subscribe to topics to join the system without modifying existing device configurations.
No protocol is universal, and MQTT has its limitations. Understanding these boundaries helps avoid architectural misuse:
Large-volume, long-duration transfers: MQTT lacks flow control and chunked transfer mechanisms. For large files (e.g., firmware packages, video clips), use HTTP/FTP, or use MQTT to transmit a download link rather than the binary data itself.
Extremely real-time closed-loop control: While MQTT latency is typically low, TCP backpressure and potential QoS retransmissions can lead to uncontrolled tail latency. For jitter-sensitive applications (e.g., industrial real-time Ethernet), more specialized protocols should be considered.
Request-response interactions: MQTT is a one-way messaging model. For remote procedure calls, response topics can be layered on top (e.g., request_topic/req, response_topic/res), but this is less straightforward than HTTP/REST.
Point-to-point direct connections without a broker: MQTT's design relies on a central broker. If the scenario requires direct device-to-device communication without an intermediate server, MQTT is not suitable.
From an engineering perspective, MQTT offers significant convenience for system integration and expansion:
1. Unified Interface, Simple Configuration
Regardless of device type, all clients communicate with the broker using the same protocol. Developers only need to focus on "which topic to publish, which topics to subscribe to," without configuring connection details for each device individually.
2. Plug-and-Play for New Devices
Need to add a new sensor type? Simply have the new device connect to the broker and publish to a new topic; monitoring applications subscribe to that topic. No changes to the existing system are required. This loose coupling makes system expansion almost unlimited.
3. Centralized Broker Management
Security policies (TLS encryption, username/password, client certificates), flow control, message persistence, offline message queues, and other features are configured uniformly on the broker side, keeping client implementations lean.
4. Mature Ecosystem, Rich Tooling
From open-source options like Eclipse Mosquitto and EMQX to cloud services such as AWS IoT Core, Azure IoT Hub, and Alibaba Cloud IoT, all natively support MQTT. Cross-platform client libraries cover major languages including C, C++, Python, Java, and Go.
The fundamental reason MQTT has become one of the most widely used protocols in IoT is that it accurately answers three basic questions of IoT communication:
How to transmit efficiently? Through lightweight headers and binary message formats, reducing network and computational overhead.
How to organize data flows flexibly? Through topics and the publish/subscribe model, achieving complete decoupling of producers and consumers.
How to adapt to complex environments? Through configurable Quality of Service, will messages, reconnect mechanisms, and other features that accommodate unstable networks.
Just as a common language allows people to communicate across regional dialects, MQTT provides a standard, low-barrier "communication language" for massive numbers of heterogeneous IoT devices. It is not the optimal solution for every scenario, but in its sweet spot — low power, low bandwidth, high latency, massive device counts, dynamic topology — MQTT has become the de facto standard.
Understanding MQTT's principles and boundaries is the first step in building reliable, scalable IoT systems. When developers stop treating it as a black-box tool and instead understand its underlying design philosophy of "decoupling and distribution," they can more confidently address the various communication challenges that arise in IoT applications.