MQTT

MQTT

Company type	Protocol
Industry	Computer networking, Internet of Things
Founded	1999
Founder	Andy Stanford-Clark, Arlen Nipper
Products	Publish–subscribe messaging protocol

MQTT is a streamlined, publish–subscribe protocol designed for machine-to-machine communication and message queuing. It caters to remote devices with limited resources or constrained network bandwidth, commonly found in the Internet of things (IoT) ecosystem. Operating over transport protocols that ensure ordered, reliable, and bidirectional connections—most often TCP/IP—MQTT is standardized by OASIS and recognized as an ISO recommendation under ISO/IEC 20922.

History

The original MQTT protocol was developed in 1999 by Andy Stanford-Clark from IBM and Arlen Nipper, who was then affiliated with Eurotech, Inc.. Its initial application focused on monitoring oil pipelines within the SCADA industrial control framework. The protocol was engineered to be efficient in terms of bandwidth usage and power consumption, making it suitable for devices connected via expensive satellite communications.

The acronym "MQ" in MQTT derives from IBM's IBM MQ product line, standing for "Message Queue," although MQTT itself uses a publish-and-subscribe messaging model rather than traditional queuing. IBM referred to version 3.1 as "MQ Telemetry Transport". Subsequent OASIS releases use the abbreviation "MQTT" without any expanded form, with the technical committee named accordingly. Since 2013, the term "MQTT" has ceased to be an acronym.

In 2013, IBM submitted MQTT version 3.1 to OASIS under a charter limiting major modifications. OASIS assumed responsibility for the protocol’s upkeep and published version 3.1.1 on October 29, 2014. A substantial revision, MQTT version 5, introducing new features, was released on March 7, 2019.

MQTT-SN (MQTT for Sensor Networks) is a variant designed for battery-powered embedded devices operating on non-TCP/IP networks, such as those utilizing Zigbee.

Overview

The MQTT architecture consists of two key components: a message broker and multiple clients. The broker acts as a server that receives messages from clients and routes them to the appropriate recipients. Clients encompass any device—from microcontrollers to full-scale servers—that implement an MQTT library and connect to the broker via a network.

Data is structured within a hierarchical topic system. When a publisher has new information, it transmits a message to the broker, which then forwards it to all clients subscribed to that particular topic. Publishers remain unaware of subscriber details, and subscribers do not need knowledge of publishers.

If no subscribers exist for a given topic, the broker discards incoming messages unless they are marked as retained. Retained messages preserve the latest message and its associated quality of service (QoS) level for each topic. This mechanism ensures that new subscribers receive the most recent data immediately upon subscribing without delay.

Publishing clients can specify a default message that will be sent automatically if they unexpectedly disconnect. Systems may deploy multiple brokers that share data according to subscriber interests.

MQTT control packets vary in size from as small as two bytes up to nearly 256 megabytes. Fourteen distinct message types handle client connection management, data publishing, acknowledgments, and connection monitoring.

While MQTT transmits data over TCP, its MQTT-SN variant supports communication over UDP or Bluetooth.

Security features such as authentication and encryption are not inherently provided by MQTT; these are generally implemented using TLS to secure data transmissions against interception or tampering.

The standard unencrypted port assigned to MQTT is 1883, whereas port 8883 is reserved for encrypted connections.

MQTT broker

An MQTT broker is a software component that operates either on local infrastructure or in cloud environments, offered as both open source and commercial options. It acts similarly to a postal system: publishers send messages to a designated "Topic," while subscribers receive all messages associated with that topic. One topic can have numerous subscribers (one-to-many), and a single client may subscribe to multiple topics across different brokers (many-to-one).

Clients engage in both publishing and subscribing activities, facilitating two-way communication—devices can transmit sensor data and receive control instructions. However, clients must send distinct messages for each topic individually, as simultaneously broadcasting a message to multiple topics is not supported.

This design separates client devices from server-side applications, ensuring clients do not access each other's transmitted data. MQTT incorporates TLS encryption with options for certificates, usernames, and passwords; some connections may also require client certificates that correspond with those on the server.

To enhance reliability, brokers and clients can automatically switch over to backup brokers if failures occur. Additionally, load balancing among several servers—whether on-premises or cloud-based—is feasible.

Brokers can handle both the standard MQTT protocol and compatible specifications like Sparkplug concurrently while maintaining uniform security standards.

Persistent sessions enable brokers to retain connection details, client subscriptions, and queued messages with QoS levels 1 or 2 during device offline periods.

Notable benefits of MQTT brokers include:

1. Securely managed client connections when appropriately configured
2. Scalability from individual devices up to thousands of endpoints
3. Monitoring of client status and authentication credentials
4. Minimization of network load without compromising security

Connect

Initiates a connection with the server, establishing communication between nodes.

Disconnect

Allows the MQTT client to finalize necessary operations before the TCP/IP session terminates.

Publish

Immediately returns control to the application thread after sending the request to the MQTT client.

Version 5.0

Introduced by OASIS in 2019, MQTT 5.0 brought significant improvements:

• Reason codes: Acknowledgments now provide specific return codes detailing reasons for failures.
• Shared subscriptions: Facilitate load distribution across clients to mitigate overload.
• Message expiry: Messages can be assigned expiration times and are removed if undelivered within that timeframe.
• Topic alias: Enables substitution of topic names with numeric aliases for enhanced efficiency.

Quality of service

MQTT connections define a Quality of Service (QoS) level that balances delivery guarantees against communication overhead:

• At most once – message sent once without confirmation (fire-and-forget).
• At least once – message retransmitted until acknowledgment is received (guaranteed delivery).
• Exactly once – employs a two-step handshake to ensure single delivery (assured delivery).

These QoS levels apply solely between MQTT clients and brokers and do not influence the underlying TCP transmission reliability.

Security

In 2020, security researchers uncovered vulnerabilities in MQTT that could be exploited to perform slow denial-of-service (DoS) attacks, underscoring potential risks in certain deployments.

Clustering

By connecting multiple broker nodes into robust networks, MQTT clustering improves fault tolerance, scalability, and high availability, guaranteeing uninterrupted message transmission even in the event of hardware or network disruptions.

See also

• Comparison of MQTT implementations
• Advanced Message Queuing Protocol (AMQP)
• Streaming Text Oriented Messaging Protocol (STOMP)
• Constrained Application Protocol (CoAP)
• Apache ActiveMQ
• Solace PubSub+
• RabbitMQ