Network Development: MQTT vs TCP/IP Model Explained
It compares MQTT protocol with TCP/IP reference model and analyzes their relationship and differences.
MQTT Protocol
- MQTT Protocol Introduction
MQTT (Message Queuing Telemetry Transport) is a lightweight publish‑subscribe messaging protocol. It is designed for low‑bandwidth, high‑latency or unstable network environments. The abbreviation MQ originates from Message Queue, derived from IBM’s MQSeries product line. Even though the name contains "MQ", MQTT itself does not require queue functionality. Different from the traditional client‑server architecture used by TCP and UDP, MQTT follows the publish‑subscribe model. A publisher sends messages to a broker middleware. According to subscriber subscription information, the broker forwards messages to corresponding subscribers. This protocol fits IoT applications well because it effectively reduces network traffic and communication overhead.
MQTT is used for data transmission between different devices or between devices and the cloud. It adopts the publish‑subscribe messaging pattern. Clients receive desired messages by subscribing to specific topics and can also publish messages to given topics. The MQTT broker is the core of the whole system. It receives messages from clients and routes messages to matching subscribers based on topics, implementing one‑to‑many or many‑to‑many communication.
In 1999, Andy Stanford‑Clark and Arlen Nipper faced a challenge: they needed to design an efficient communication protocol for a satellite‑connected oil‑pipeline monitoring system. The system had to operate under extreme conditions:
Bandwidth‑limited Satellite communication normally has very limited and costly bandwidth.
Battery consumption Devices are often battery‑powered, so lowering power consumption is critical.
Unreliable network Satellite links may suffer high latency and instability.
Photo of Andy Stanford‑Clark
To address these challenges, MQTT was designed with the following goals:
Easy to implement Build a simple protocol that can run on resource‑constrained devices and reduce development and deployment complexity.
Lower data‑transmission cost Minimize message header overhead and simplify communication flows to cut bandwidth usage and transmission costs.
Quality‑of‑service management Offer multiple message QoS levels to satisfy reliability and efficiency requirements for different applications, keeping message delivery reliable under varying network conditions.
Continuous session control Allow clients to maintain persistent sessions so they can receive missed messages even after connection drops.
Flexible data format No rigid requirements for data types or formats; users can transmit all kinds of payloads as needed.
MQTT successfully solved these challenges and became an important protocol for IoT and remote‑monitoring applications. It transfers data efficiently over low‑bandwidth and unstable networks and is especially suitable for embedded devices and remote sensors. In 2013, IBM submitted the MQTT 3.1 specification to OASIS to promote it as an open standard. Afterwards, MQTT gradually became one of the standard protocols in the IoT field. Core principles of MQTT: lean design, publish‑subscribe pattern, focus on transmission efficiency and reliability for low‑bandwidth high‑latency networks, support flexible topic creation and QoS management, suitable for compute‑limited devices.
Main features of MQTT:
Publish‑subscribe pattern MQTT uses publish‑subscribe communication. Publishers publish messages to topics; subscribers subscribe to topics of interest to receive relevant messages. An MQTT broker middleware manages publish‑subscribe workflows and reliably distributes messages to subscribers.
This pattern decouples senders and receivers and improves system flexibility and scalability.
Spatial decoupling between sender and receiver
Publishers do not need to know who the subscribers are. Similarly, subscribers know nothing about publishers and only subscribe to target topics.
Temporal decoupling between sender and receiver
Publishers and subscribers do not need to be online simultaneously. A publisher may send messages while subscribers are offline; the broker caches messages and pushes them once subscribers come online. Subscribers can also subscribe while publishers are offline and receive messages immediately after publishers connect.
Meanwhile publishers and subscribers send and receive messages asynchronously without waiting for peer responses, achieving asynchronous communication.
Three‑level Quality of Service (QoS) MQTT provides three message‑delivery QoS levels.
Comparison of message delivery mechanisms for QoS 0, QoS 1 and QoS 2
QoS 0 (At most once) Messages may be lost with minimal transmission overhead. Suitable for scenarios insensitive to data loss, e.g. environmental sensor data collection where one missing sample does not affect overall results, or ordinary app push notifications. Smart devices will not receive pushes if offline.
QoS 1 (At least once) Messages are delivered at least once but duplicates may occur. Suitable for use‑cases where message arrival must be guaranteed and duplicates cause no severe consequences.
QoS 2 (Exactly once) Messages are delivered precisely one time. Applied to highly demanding scenarios with zero loss or duplication, such as billing systems and instant‑messaging push notifications requiring accurate delivery.
By selecting QoS levels, MQTT controls message transmission priority and redundancy to conserve bandwidth.
Lightweight and efficient MQTT has small protocol headers carrying only essential information to cut communication overhead. Binary encoding further improves transmission efficiency, making it ideal for constrained devices and low‑bandwidth networks.
Keep‑alive and Last‑Will message MQTT clients configure keep‑alive time and periodically send keep‑alive packets to the server to maintain connections. Clients may also set a Last‑Will message. When a client disconnects unexpectedly, the broker publishes this predefined message to notify other subscribers.
Topic‑based addressing MQTT uses hierarchical topics to identify messages. Subscribers may subscribe to wildcard topics to receive multiple related messages. Topic‑based subscription delivers flexible message routing and filtering.
Security mechanism MQTT supports SSL/TLS encryption to secure message transmission and authentication methods such as username‑password or OAuth.
Built on TCP/IP MQTT runs over TCP/IP for reliable data delivery. There also exists MQTT‑SN built on UDP.
- MQTT Packet Structure
The basic MQTT data unit is a packet. Each packet consists of Fixed Header, Variable Header and Payload:
+----------+-------------------+-------------------+
| Fixed | Variable Header | Payload |
| Header | | |
+----------+-------------------+-------------------+
MQTT packet format details:
Fixed Header
Packet Type Identifies MQTT message type: CONNECT, PUBLISH, SUBSCRIBE and others.
Reserved Bit Reserved for future extension.
QoS Level Sets message delivery quality: 0, 1 or 2.
Duplication Flag Indicates whether this is a re‑transmitted duplicate packet.
Keep Alive Defines interval for client keep‑alive packets to maintain connection.
Variable Header
Protocol Name Always "MQTT".
Protocol Level Represents MQTT version supported by client and server.
Connection ID Unique ID identifying the client connection.
Username Optional field for authentication.
Password Optional field for authentication.
Heartbeat Optional field for connection‑liveness detection.
Payload Payload carries actual transmitted data. Its length depends on packet type and QoS level.
For PUBLISH packets: payload contains topic and message content. For SUBSCRIBE packets: payload holds list of subscribed topics.
MQTT packet design pursues compactness and minimal transmission overhead, which is critical for resource‑limited devices.
Common MQTT packet types:
CONNECT packet Used when a client requests connection to server.
CONNACK packet Acknowledges connection requests.
PUBLISH packet Used for publishing messages.
PUBACK packet Acknowledges received PUBLISH packets.
SUBSCRIBE packet Used for topic subscription.
SUBACK packet Acknowledges SUBSCRIBE packets.