MQTT: Message Queuing Telemetry Transport

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol designed for constrained devices and unreliable networks. It was created in 1999 by Andy Stanford-Clark of IBM and Arlen Nipper, originally to monitor oil pipelines via satellite links where bandwidth was expensive and connections were fragile. The protocol needed to be efficient, reliable, and capable of operating on devices with minimal processing power and memory.

Since its creation, MQTT has become the dominant messaging protocol for the Internet of Things (IoT). It is now an OASIS open standard, with the latest version being MQTT 5.0, published in 2019. The protocol runs over TCP on port 1883 for unencrypted connections and port 8883 when secured with TLS. Its minimal packet overhead (as small as 2 bytes for a header) makes it ideal for battery-powered sensors, embedded systems, and mobile devices that need to conserve bandwidth and power.

MQTT is used across a wide range of industries. Smart home platforms like Home Assistant rely on it for device communication. Automotive companies use it for connected vehicle telemetry. Industrial operations use it for monitoring factory equipment. Social platforms like Facebook Messenger adopted MQTT for its efficient push notification delivery. Wherever devices need to send small messages reliably over potentially unstable connections, MQTT is a natural fit.

How MQTT Works: The Publish-Subscribe Model

MQTT uses a publish-subscribe (pub/sub) messaging pattern, which is fundamentally different from the request-response model used by HTTP. In HTTP, a client sends a request to a specific server and waits for a response. In MQTT, message senders (publishers) and message receivers (subscribers) never communicate directly. Instead, a central component called the broker handles all message routing.

The system involves three roles. Publishers are clients that send messages to a named topic. They do not know or care who will receive those messages. Subscribers are clients that register interest in one or more topics. The broker delivers any message published to those topics. The broker sits in the middle, accepting all published messages and forwarding them to every client that has subscribed to the matching topic.

This decoupling is one of MQTT's greatest strengths. Publishers and subscribers do not need to know about each other, run at the same time, or even be on the same network segment. A temperature sensor can publish readings to home/livingroom/temperature without any knowledge of whether a dashboard, a logging service, or an automation system is listening. New subscribers can be added at any time without modifying the publisher. This loose coupling makes MQTT systems highly flexible and easy to scale.

MQTT Topics and Wildcards

Topics are the addressing mechanism in MQTT. A topic is a UTF-8 string that the broker uses to filter and route messages to the appropriate subscribers. Topics are hierarchical, using the forward slash / as a level separator. For example, home/livingroom/temperature has three levels: home, livingroom, and temperature. Topics are case-sensitive, so Home/LivingRoom and home/livingroom are two different topics. Topics do not need to be pre-created; they come into existence the moment a client publishes or subscribes to them.

MQTT supports two wildcard characters for subscribing to multiple topics at once. The single-level wildcard + matches exactly one level in the topic hierarchy. Subscribing to home/+/temperature would match home/livingroom/temperature and home/bedroom/temperature, but not home/floor1/bedroom/temperature. The multi-level wildcard # matches any number of levels and must appear as the last character in the subscription. Subscribing to home/# would match every topic that begins with home/, regardless of depth.

Best practices for topic naming include using lowercase letters, keeping topic structures consistent, avoiding leading slashes (which create an empty first level), and designing the hierarchy to reflect your data model logically. A well-structured topic tree makes wildcard subscriptions more useful and keeps your system organized.

MQTT Quality of Service (QoS) Levels

MQTT provides three Quality of Service levels that control the delivery guarantee for each message. Each level represents a different trade-off between reliability and network overhead. The QoS level is set per message by the publisher, and the broker honors it when delivering to subscribers (subject to the maximum QoS granted during subscription).

QoS 0: At most once.This is the fastest and simplest level, often called "fire and forget." The publisher sends the message once with no acknowledgment from the broker. The message may arrive once, or it may be lost entirely if the network drops the packet. QoS 0 is suitable for non-critical data like frequent sensor readings where an occasional lost value is acceptable.

QoS 1: At least once. The publisher sends the message and waits for a PUBACK (publish acknowledgment) from the broker. If no PUBACK is received within a timeout period, the publisher resends the message. This guarantees delivery but may result in duplicate messages if the acknowledgment is lost. QoS 1 is the most commonly used level, providing a good balance of reliability and performance. Subscribers should be prepared to handle duplicates.

QoS 2: Exactly once. This is the most reliable level, guaranteeing that each message is delivered exactly one time with no duplicates. It uses a four-step handshake: PUBLISH, PUBREC (publish received), PUBREL (publish release), and PUBCOMP (publish complete). This eliminates both message loss and duplication, but it requires twice the number of network round trips compared to QoS 1. QoS 2 is reserved for scenarios where duplicates are unacceptable, such as billing events or critical command messages.

Retained Messages and Last Will

Retained messagessolve a common problem in pub/sub systems: when a new subscriber connects, it normally has no way of knowing the current state of a topic. With retained messages, the broker stores the last message published to a topic with the "retain" flag set. When a new client subscribes to that topic, the broker immediately delivers the retained message so the subscriber has the most recent value right away, without waiting for the next publish. This is especially useful for status topics like device online/offline state or the latest sensor reading.

Last Will and Testament (LWT)is a feature that lets clients prepare for unexpected disconnections. When a client connects to the broker, it can register a "will" message: a topic, payload, QoS level, and retain flag. If the client disconnects ungracefully (network failure, crash, or keep-alive timeout), the broker automatically publishes the will message on the client's behalf. This is commonly used to update a status topic, for example publishing "offline" to devices/sensor42/status so other clients know the device is no longer available.

MQTT also distinguishes between clean sessions and persistent sessions. With a clean session, the broker discards any previous session state when the client connects. With a persistent session, the broker stores subscriptions and any QoS 1/2 messages that arrive while the client is offline, delivering them when the client reconnects. MQTT 5.0 introduced session expiry intervals, giving clients fine-grained control over how long the broker should maintain session state after disconnection.

MQTT Packet Types

The MQTT protocol defines 15 packet types that handle every aspect of communication between clients and the broker. Each packet has a compact fixed header (as small as 2 bytes) followed by a variable header and optional payload. The most important packet types are listed below.

MQTT vs HTTP for IoT

MQTT and HTTP are both application-layer protocols that run over TCP, but they are designed for very different use cases. HTTP follows a request-response model where the client initiates every exchange. MQTT uses a persistent connection with publish-subscribe messaging, which makes it far more efficient for IoT scenarios involving frequent, small messages and server-initiated push delivery.

For IoT deployments with thousands of devices sending small payloads every few seconds, MQTT can reduce bandwidth usage by up to 90% compared to HTTP. The persistent connection eliminates the overhead of repeated TCP handshakes and large HTTP headers. However, HTTP remains the better choice for traditional web APIs, browser-based applications, and scenarios where request-response semantics are needed.

Popular MQTT Brokers

The broker is the central component of any MQTT deployment. It handles authentication, authorization, message routing, session management, and QoS enforcement. Several brokers are available, ranging from lightweight open-source options to fully managed cloud services.

• Eclipse Mosquitto: a lightweight, open-source broker written in C. Mosquitto is widely used for development, testing, and edge deployments. It has a small memory footprint and runs on everything from Raspberry Pi devices to full servers. It supports MQTT 3.1, 3.1.1, and 5.0.
• HiveMQ: an enterprise-grade broker designed for large-scale production deployments. HiveMQ supports clustering for horizontal scalability, full MQTT 5.0 compliance, and an extension framework for custom integrations. It is commonly used in automotive, logistics, and industrial IoT.
• EMQX: a high-performance broker built with Erlang, known for handling millions of concurrent connections. EMQX offers built-in rule engines, data integration with databases and message queues, and both open-source and enterprise editions.
• AWS IoT Core: a managed MQTT service from Amazon Web Services. It handles broker infrastructure, scaling, and security automatically. AWS IoT Core integrates natively with other AWS services like Lambda, DynamoDB, and S3 for processing and storing IoT data.
• Azure IoT Hub:Microsoft's managed IoT platform, which supports MQTT along with AMQP and HTTPS. It provides device provisioning, identity management, and integration with Azure services like Stream Analytics and Azure Functions.

Choosing between self-hosted and cloud-managed brokers depends on your requirements. Self-hosted brokers like Mosquitto and EMQX offer full control, lower latency for local networks, and no per-message costs. Cloud services like AWS IoT Core and Azure IoT Hub eliminate operational overhead, provide built-in scaling, and simplify integration with cloud analytics and storage, but they introduce per-message pricing and dependency on the cloud provider.

Common Use Cases

• IoT sensor networks: MQTT is the standard protocol for collecting data from distributed sensors. Temperature, humidity, pressure, and motion sensors publish readings to the broker, where multiple consumers can subscribe for logging, alerting, and analytics.
• Smart home automation: platforms like Home Assistant use MQTT as a central communication bus. Smart lights, thermostats, locks, and sensors all publish state and subscribe to commands through the broker.
• Industrial telemetry: factories and plants use MQTT to monitor equipment health, track production metrics, and trigger maintenance alerts. Its lightweight nature makes it suitable for PLCs and embedded controllers on the factory floor.
• Fleet and vehicle tracking: connected vehicles publish GPS coordinates, fuel levels, and diagnostic data over MQTT. Fleet management systems subscribe to these topics for real-time tracking and route optimization.
• Chat and messaging:MQTT's low-latency push delivery makes it suitable for chat applications. Facebook Messenger famously used MQTT to deliver messages to mobile devices efficiently, reducing battery drain compared to polling-based approaches.
• Real-time dashboards: monitoring dashboards subscribe to relevant topics and update visualizations as new data arrives. This provides live views of system health, business metrics, or environmental conditions without manual refreshing.
• Energy monitoring: smart meters and energy management systems use MQTT to report consumption data. Utilities and building managers subscribe to track usage patterns and optimize energy distribution.
• Agriculture monitoring: soil moisture sensors, weather stations, and irrigation controllers communicate over MQTT in precision farming setups, enabling automated watering schedules and crop health monitoring across large areas.

Frequently Asked Questions About MQTT

What does MQTT stand for?

MQTT originally stood for Message Queuing Telemetry Transport. However, the OASIS standard committee now treats MQTT simply as the protocol name rather than an acronym, since the protocol does not actually implement message queuing in the traditional sense. It uses a publish-subscribe model rather than a point-to-point message queue.

Is MQTT secure?

MQTT itself does not define encryption, but it is commonly secured using TLS/SSL on port 8883. This encrypts all communication between clients and the broker. Additionally, MQTT supports username/password authentication in the CONNECT packet, and most brokers support client certificate authentication for stronger identity verification. MQTT 5.0 added enhanced authentication mechanisms that support challenge-response flows and integration with external auth systems.

What is the difference between MQTT and HTTP?

HTTP uses a request-response model where the client initiates every interaction. MQTT uses a publish-subscribe model with a persistent connection, allowing the broker to push messages to clients at any time. MQTT has much lower overhead (2-byte minimum header versus hundreds of bytes for HTTP headers), making it far more efficient for IoT devices that send frequent, small messages. HTTP is better suited for web applications and RESTful APIs.

What is an MQTT broker?

The broker is the central server in an MQTT system. It receives all messages from publishers, filters them by topic, and delivers them to the appropriate subscribers. The broker also manages client sessions, enforces QoS levels, stores retained messages, and publishes Last Will messages when clients disconnect unexpectedly. Popular brokers include Eclipse Mosquitto, HiveMQ, and EMQX.

Can MQTT handle millions of devices?

Yes. Enterprise brokers like HiveMQ and EMQX are designed to handle millions of concurrent connections. EMQX has demonstrated support for over 100 million connections in testing. Cloud services like AWS IoT Core and Azure IoT Hub also scale to millions of devices with managed infrastructure. The key to scaling MQTT is choosing a broker that supports clustering and horizontal scaling, combined with efficient topic design and appropriate QoS levels.

What is new in MQTT 5.0?

MQTT 5.0, released in 2019, introduced several significant features. These include user properties (custom key-value metadata on packets), shared subscriptions (load balancing messages across multiple subscribers), session expiry intervals, message expiry intervals, topic aliases (reducing bandwidth for frequently used topics), flow control, enhanced error reporting with reason codes on all acknowledgments, and the request-response pattern for RPC-style interactions. These additions make MQTT 5.0 better suited for enterprise and cloud-scale deployments.

Related Protocols

• TCP: the transport protocol that MQTT runs on, providing reliable, ordered byte-stream delivery
• HTTP: the request-response web protocol often compared with MQTT for IoT use cases
• HTTPS: the encrypted version of HTTP, similar in concept to MQTT over TLS on port 8883
• UDP: the connectionless transport protocol used by MQTT-SN, a variant of MQTT designed for sensor networks