MQTT protocol

MQTT is a lightweight messaging protocol designed for constrained devices and low-bandwidth, high-latency, or unreliable networks. It follows the publish/subscribe model, enabling efficient communication in IoT systems, mobile applications, and embedded systems with minimal overhead.

Each MQTT message consists of three parts:

1. Fixed header — present in every MQTT message. Contains a control byte with the packet type (CONNECT, PUBLISH, SUBSCRIBE, etc.) and associated flags.
2. Variable header — optional, depends on the message type. Contains additional information such as packet identifiers or topic names.
3. Payload — carries the application data. For PUBLISH messages, this is the transmitted data; for SUBSCRIBE messages, it contains topic filters.

This compact format keeps message sizes small and optimizes network use.

	MQTT	HTTP	CoAP	AMQP
Model	Publish/subscribe	Request/response	Request/response	Message queue
Transport	TCP	TCP	UDP	TCP
Overhead	Very low	High	Low	High
Connection	Persistent	Stateless	Stateless	Persistent
Best for	IoT, constrained devices	Web applications	Constrained IoT	Enterprise messaging

Key differences worth understanding:

• MQTT vs. HTTP — HTTP is stateless: every request must carry all necessary context, increasing data load. MQTT maintains a persistent, stateful session between client and broker, enabling continuous data exchange with minimal overhead.
• MQTT vs. CoAP — CoAP uses UDP and follows a request/response model. MQTT uses TCP for reliable delivery and the publish/subscribe model, which is better suited for scenarios where devices send or receive messages without direct communication between sender and receiver.
• MQTT vs. AMQP — AMQP offers more control over messaging guarantees (message queues, routing) at the cost of increased complexity and resource requirements. MQTT focuses on minimizing overhead.

MQTT excels where low overhead, limited bandwidth, and power efficiency are critical. HTTP and AMQP are better suited for richer feature sets or complex communication patterns.

MQTT is designed for environments with:

• Low bandwidth constraints
• Minimal power consumption requirements
• Inconsistent network reliability

Common use cases include:

• Smart home automation (lighting, HVAC, security systems)
• Wearable devices (fitness trackers, health monitors)
• Connected vehicles (vehicle telemetry, fleet management)
• Industrial monitoring and control (factory equipment sensors)

• Publishers send messages to specific topics without knowing who the receivers are.
• Subscribers express interest in topics and receive only matching messages.

This decoupling makes MQTT highly scalable — producers and consumers operate independently.

The MQTT broker acts as a central intermediary:

• Manages client connections
• Routes messages between publishers and subscribers
• Ensures reliable delivery based on the requested QoS level

Multiple clients can publish and subscribe to the same topic, with the broker ensuring that messages are delivered to all interested subscribers.

MQTT architecture is built on three key components:

Clients — any device or system that connects to the broker. Can publish, subscribe, or both. Clients range from small IoT sensors to complex enterprise applications.

Broker — the central server responsible for routing messages, managing connections, handling QoS, and persisting messages for offline clients.

Topics — hierarchical channels through which data flows. Publishers send to topics; subscribers register interest in topics. Wildcards (+, #) allow matching multiple topics. See Topics and wildcards.

MQTT defines 14 packet types that govern all communication between clients and the broker:

Packet	Direction	Purpose
CONNECT	Client → Broker	Establishes connection; includes clientId, protocol version, credentials, session flags, and optional Last Will
CONNACK	Broker → Client	Acknowledges connection; indicates success or rejection reason

Packet	Direction	Purpose
PUBLISH	Both	Carries the message payload, topic name, QoS level, and optional retain flag
PUBACK	Receiver → Sender	QoS 1 acknowledgment
PUBREC	Receiver → Sender	QoS 2 — step 1 of four-way handshake
PUBREL	Sender → Receiver	QoS 2 — step 2 of four-way handshake
PUBCOMP	Receiver → Sender	QoS 2 — step 3, completes delivery
SUBSCRIBE	Client → Broker	Registers interest in one or more topic filters with desired QoS
SUBACK	Broker → Client	Confirms subscriptions and granted QoS levels
UNSUBSCRIBE	Client → Broker	Removes subscriptions from specified topics
UNSUBACK	Broker → Client	Confirms unsubscription

Packet	Direction	Purpose
PINGREQ	Client → Broker	Checks broker availability; keeps connection alive during inactivity
PINGRESP	Broker → Client	Confirms broker is still reachable
DISCONNECT	Client → Broker	Initiates clean disconnection; in MQTT 5.0 includes optional reason code
AUTH	Both	MQTT 5.0 only — supports multi-step enhanced authentication (e.g., SASL, OAuth)

MQTT defines three delivery guarantee levels:

• QoS 0 (At most once) — fire-and-forget; no guarantee of delivery.
• QoS 1 (At least once) — guaranteed delivery but possible duplicates.
• QoS 2 (Exactly once) — guaranteed exactly-once delivery via four-step handshake.

See Quality of Service (QoS) for a detailed guide.

• Persistent session (clean session = false) — the broker stores subscriptions and queued QoS 1/2 messages. Upon reconnection, the client receives missed messages.
• Clean session (clean session = true) — all session state is cleared on disconnect. The client starts fresh on each connection.

When a client reconnects after a disconnect, the broker redelivers any missed messages if a persistent session was used. With QoS 1 or QoS 2, the broker continues redelivery until the client acknowledges each message. This session flexibility allows clients to maintain continuous operation even with intermittent connectivity.

MQTT 3.1.1 is the widely adopted baseline version. It provides the core publish/subscribe model, three QoS levels, and basic session management, and is known for its lightweight nature across a wide range of devices.

MQTT 5.0 builds on MQTT 3.1.1 with the following additions:

Feature	Description
Reason codes	Detailed success and error feedback for all operations
User properties	Custom key-value pairs attachable to any MQTT packet
Session expiry	Client-controlled duration for session state retention after disconnect
Message expiry interval	Per-message TTL; the broker discards undelivered messages past the deadline
Shared subscriptions	Multiple clients share messages from the same topic for load balancing
Topic alias	Short numeric aliases replace frequently used topic names to reduce bandwidth
Enhanced authentication (AUTH packet)	Multi-step authentication flows for protocols like OAuth or SCRAM
Flow control	Client-controlled receive maximum to prevent message flooding
Request-response pattern	Asynchronous request/response via response topic and correlation data
Payload format indicator & content type	Signal payload format (e.g., JSON, binary) and MIME content type
Subscription options	Per-subscription controls: Retain As Published, No Local, Retain Handling, Maximum QoS
Subscription identifier	Unique identifier assigned to each subscription, included in PUBLISH for client-side routing

• Keep messages small and choose the appropriate QoS level for each use case.
• Reserve QoS 2 for critical data only — its four-way handshake carries the highest overhead.
• Avoid excessive use of retained messages and manage topic hierarchies carefully to prevent message flooding.

• Always use TLS/SSL to encrypt communication between clients and the broker.
• Implement strong authentication: username/password, client certificates, or SCRAM (MQTT 5.0).
• Enforce topic-level access control at the broker to restrict publish and subscribe permissions.

• Scale brokers horizontally using clustering and load balancers.
• Use shared subscriptions to distribute message processing across subscriber groups.
• Monitor broker metrics — connection counts, throughput, and resource usage — to identify bottlenecks early.