What is MQTT?
A standards-based messaging protocol that governs how Internet of Things devices exchange data, MQTT addresses the unique challenges posed by IoT deployments. Smart sensors, wearables, and connected devices typically operate under significant constraints—limited bandwidth and resource availability—making traditional communication protocols impractical. MQTT solves this by providing an efficient, lightweight framework for bidirectional data flow between devices and cloud systems. Its design enables seamless transmission and reception of information across networks where conventional approaches would struggle.
Why the MQTT protocol matters
Lightweight and efficient
Deploying MQTT on IoT hardware demands minimal computational resources, making it suitable even for small microcontrollers. A basic MQTT control message can occupy as few as two data bytes. The protocol's compact message headers further reduce network overhead, allowing organizations to maximize available bandwidth.
Scalable
The protocol requires minimal code footprint while consuming negligible power during operation. Built-in mechanisms support communication with vast numbers of connected devices, enabling deployments spanning millions of endpoints. MQTT 5.0 introduced shared subscriptions, permitting multiple subscribers to connect to a broker while designating only one to process each message. This capability facilitates cloud-based load-balancing implementations.
Reliable
IoT devices frequently operate over unreliable cellular connections characterized by low bandwidth and high latency. MQTT incorporates built-in mechanisms that minimize reconnection time when connectivity is lost. The protocol defines three quality-of-service (QOS) levels to guarantee appropriate message delivery:
- QOS 0 delivers messages once using a fire-and-forget approach, suitable for non-critical applications like telemetry
- QOS 1 transmits messages multiple times to ensure the recipient obtains at least one copy
- QOS 2 guarantees the recipient receives exactly one copy, typically employed for mission-critical operations such as alarm notifications
Secure
MQTT streamlines message encryption and device authentication through contemporary security standards including OAuth, TLS 1.3, and customer-managed certificates.
Well-supported
Extensive MQTT implementation support exists across multiple programming languages such as Python, JavaScript, and C++. This broad ecosystem enables developers to integrate MQTT functionality quickly with minimal additional code across diverse applications.
Historical development of MQTT
The protocol originated in 1999 within the oil and gas sector, where engineers required a compact messaging solution capable of operating under severe bandwidth and power constraints to supervise oil pipelines through satellite connections. The name Message Queuing Telemetry Transport reflected its initial association with IBM's MQ Series product. IBM released MQTT 3.1 in 2010 as an open, freely available protocol for universal implementation. The protocol subsequently underwent standardization when submitted to the Organization for the Advancement of Structured Information Standards (OASIS) in 2013. OASIS released MQTT version 5 in 2019, representing a significant upgrade. Today, MQTT functions as the protocol's official designation rather than remaining an acronym.
The publish-subscribe architecture
MQTT operates through a publish-subscribe model that fundamentally differs from traditional client-server communication. Rather than direct point-to-point exchanges, a message broker acts as an intermediary, receiving messages from publishers and distributing them to interested subscribers. This architecture decouples communicating parties across three dimensions:
Space decoupling
Publishers and subscribers remain unaware of each other's network positions and do not share identifying information such as IP addresses or port numbers.
Time decoupling
Publishers and subscribers function independently, with no requirement for simultaneous network presence.
Synchronization decoupling
Message transmission and reception occur asynchronously, eliminating the need for either party to pause operations while awaiting the other.
Core MQTT components
MQTT client
Any networked device running MQTT library software qualifies as an MQTT client, ranging from full servers to embedded microcontrollers. Clients functioning as message originators serve as publishers, while those receiving messages act as subscribers. A single device may perform both roles simultaneously.
MQTT broker
The broker, alternatively termed the MQTT server, constitutes the backend infrastructure orchestrating message flow between clients. Its responsibilities encompass receiving and filtering messages, identifying relevant subscribers, and forwarding appropriate content. Additional broker functions include:
- Verifying client credentials and permissions
- Optionally routing messages to external systems for processing
- Managing undelivered messages and client session states
- Rejecting messages that violate protocol specifications
MQTT connection
Communication between clients and brokers initiates when a client transmits a CONNECT message to the broker. The broker responds with a CONNACK message confirming successful connection establishment. Both participants require TCP/IP stack support, though WebSockets compatibility is available. Client-to-client connections never occur; all communication routes through the broker.
How MQTT operates
- An MQTT client initiates connection with the MQTT broker
- Upon successful connection, the client may publish messages, subscribe to specific topics, or perform both actions
- When the broker receives a message, it forwards it to all subscribed clients with matching interests
MQTT topic
Topics function as keywords enabling the broker to categorize and route messages to appropriate clients. Organized hierarchically like file system directories, topics allow sophisticated message filtering. In a smart home deployment across multiple floors, the broker might structure topics as separate branches for each level, with subdivisions for individual device types.
MQTT publish
Publishing clients transmit messages containing topic identifiers and data encoded in byte format. The originating client determines the data representation—whether text, binary, XML, or JSON. For instance, a smart home lighting fixture might publish a status message to the topic livingroom/light.
MQTT subscribe
Clients seeking to receive messages on particular topics send a SUBSCRIBE message to the broker, including a unique packet identifier and a subscription list. A smart home mobile application, for example, might subscribe to +/light to monitor all lighting status updates throughout the residence and maintain an accurate count of active lights.
MQTT over WebSockets
MQTT over WebSockets (WSS) enables direct data reception within web browsers, allowing JavaScript-based applications to establish connections with MQTT brokers. The protocol functions identically to standard MQTT but incorporates additional headers supporting WSS requirements. Conceptually, the MQTT message payload becomes encapsulated within a WSS wrapper.
Security considerations
MQTT communication can leverage the TLS protocol to safeguard sensitive information transmitted by IoT devices. The protocol supports identity verification, authentication, and authorization mechanisms between clients and brokers through TLS certificates and password credentials. Brokers typically authenticate clients using assigned unique identifiers combined with password verification. Most deployments employ certificate-based or DNS-based server authentication from the client perspective. MQTT incorporates encryption capabilities addressing various data protection requirements.
MQTT and REST architecture
MQTT does not follow REST principles. Representational State Transfer employs a request-response communication model between endpoints. Conversely, MQTT utilizes the publish-subscribe paradigm at the application layer and maintains persistent TCP connections for push-based message delivery. However, MQTT version 5 introduces a request-response capability allowing publishers to specify a response topic, enabling the receiver to process the request and generate an appropriate reply, thereby approximating REST-like behavior.
AWS support for MQTT implementations
AWS IoT Core provides a fully managed platform enabling connection of billions of IoT devices and routing of trillions of messages to AWS services. The service offers:
- Straightforward device fleet connectivity, management, and scaling without server provisioning or administration
- Flexible protocol selection including MQTT, HTTPS, MQTT over WSS, and LoRaWAN
- Mutual authentication and end-to-end encryption protecting device connections and transmitted data
- Real-time message filtering, transformation, and action execution based on defined business logic
Source: AWS News Blog