MQTT Protocol Guide for IoT

MQTT (Message Queuing Telemetry Transport) is the dominant messaging protocol for IoT (Internet of Things). It connects billions of devices — from industrial sensors and smart home devices to fleet tracking systems and medical monitors. If you are building anything that involves devices communicating over a network, you need to understand MQTT.

This guide covers the protocol fundamentals, quality of service levels, and practical patterns.

Why MQTT?

MQTT was designed in 1999 for oil pipeline telemetry over satellite links — a scenario with low bandwidth, unreliable connections, and constrained devices. These design constraints produced a protocol that is:

• Lightweight — minimal packet overhead (as little as 2 bytes for a header)
• Publish/subscribe — decouples senders and receivers
• Reliable — three QoS levels for different reliability needs
• Bidirectional — both devices and servers can publish and subscribe
• Battery-friendly — supports long idle periods with keepalive pings

Publish/Subscribe Model

Unlike HTTP (request/response), MQTT uses a publish/subscribe model with a central broker:

1. Publishers send messages to topics (e.g., sensors/temperature/room1)
2. The broker receives messages and routes them to subscribers
3. Subscribers register interest in topics (with optional wildcards)

Publishers and subscribers never communicate directly. The broker handles all routing, which means:

• Publishers do not need to know who is listening
• Subscribers do not need to know who is sending
• Devices can go offline and reconnect without breaking the system

Topics

MQTT topics are hierarchical strings separated by /:

home/livingroom/temperature
home/livingroom/humidity
home/bedroom/temperature
factory/line1/machine3/status

Wildcards (for subscribers only)

• + matches exactly one level: home/+/temperature matches home/livingroom/temperature and home/bedroom/temperature
• # matches any number of levels: home/# matches everything under home/
• You cannot publish to a wildcard topic — only subscribe

Quality of Service (QoS)

MQTT defines three QoS levels:

QoS 0: At Most Once

Fire and forget. The message is delivered once with no confirmation. It may be lost if the connection drops.

Use for: High-frequency sensor data where individual lost readings are acceptable (temperature every second).

QoS 1: At Least Once

The broker acknowledges receipt. If no acknowledgment arrives, the publisher resends. This may cause duplicates.

Use for: Important events that must be delivered, where duplicates can be handled idempotently (door opened, alarm triggered).

QoS 2: Exactly Once

A four-step handshake ensures the message is delivered exactly once. Highest overhead but no duplicates and no loss.

Use for: Critical commands where duplicates would cause problems (billing events, actuator commands).

The effective QoS is the minimum of the publisher's QoS and the subscriber's QoS. If you publish at QoS 2 but the subscriber subscribed at QoS 0, the delivery is QoS 0.

Retained Messages

A retained message is stored by the broker and sent immediately to any new subscriber on that topic. This is useful for "last known value" patterns:

Topic: sensors/battery/level
Payload: "87"
Retained: true

When a new subscriber connects, it immediately receives the last battery level without waiting for the next publish. Only one retained message is stored per topic — a new retained message replaces the old one.

Last Will and Testament (LWT)

When a client connects, it can register a "last will" message — a message the broker publishes if the client disconnects unexpectedly (without a proper DISCONNECT packet):

Will Topic: devices/sensor42/status
Will Payload: "offline"
Will QoS: 1
Will Retain: true

Combined with a regular retained message on connect ("online"), this creates a reliable online/offline status indicator.

Clean Session vs Persistent Session

• Clean session (true): The broker discards any previous session state. Subscriptions must be re-established on each connect. Default for most clients.
• Persistent session (false): The broker stores subscriptions and queued messages (QoS 1+) while the client is offline, delivering them on reconnect.

MQTT 5.0 Features

MQTT 5.0 (released 2019) adds:

• Reason codes on every acknowledgment
• Message expiry — messages can have a TTL
• Topic aliases — reduce per-message overhead for repeated topics
• Request/response pattern with response topics
• User properties — custom key-value metadata on messages
• Shared subscriptions — load balance messages across multiple subscribers

Common Brokers

Try It

Connect to any MQTT broker over secure WebSockets with StackCache MQTT Client. Subscribe to topics, publish messages, and inspect payloads in real time — directly from your browser with no install.