Generated by GPT-5-mini| MQTT | |
|---|---|
| Name | MQTT |
| Caption | Message Queuing Telemetry Transport stack overview |
| Developer | Andy Stanford-Clark; Arlen Nipper |
| Introduced | 1999 |
| Latest release | 5.0 (ISO/IEC 20922:2016 aligned update) |
| License | OASIS standard |
MQTT
MQTT is a lightweight publish–subscribe network protocol designed for constrained devices and low-bandwidth, high-latency or unreliable networks. It was created to enable efficient telemetry and messaging between embedded systems, sensors, and servers while minimizing overhead and conserving resources. The protocol has been standardized and widely implemented across industry, academia, and open-source communities, influencing IoT deployments, industrial automation, and cloud messaging services.
MQTT originated from work by Andy Stanford-Clark and Arlen Nipper to connect sensor networks to telemetry backends and has since been standardized by OASIS and recognized in international standards bodies. The protocol favors a simple client–server (broker) topology and a topic-based publish–subscribe paradigm that decouples producers and consumers; this paradigm is comparable to architectures used in enterprise message buses and event-driven systems. MQTT’s minimalist framing and small control packet set make it suitable for battery-powered devices, embedded microcontrollers, satellite links, and mobile applications. It has been referenced alongside other messaging technologies and transport frameworks in standards discussions and industrial consortia.
The protocol operates typically over TCP/IP and optionally over WebSocket transports; it defines a binary control packet format with fixed and variable headers to minimize parsing complexity. MQTT specifies control packet types for CONNECT, CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRESP, and DISCONNECT, enabling session establishment, message exchange, subscription management, and keepalive mechanisms. The standard defines session state, clean session flags, will messages, retained messages, and topic filters with wildcard semantics that allow hierarchical routing similar to other messaging systems. Version 5.0 introduced enhanced features such as reason codes, user properties, request/response correlation, and improved error reporting to support richer interoperability and diagnostic tooling.
At the center of an MQTT deployment is the broker, which mediates client connections, manages topic subscriptions, enforces access control, and persists retained messages or session state when requested. Clients (publishers and subscribers) are typically constrained devices, gateways, mobile apps, or cloud services that open long-lived connections to brokers. Gateways and protocol translators often bridge between field protocols, industrial buses, and MQTT brokers, enabling integration with SCADA deployments, building management systems, and cloud platforms. Management components include monitoring systems, provisioning servers, and certificate authorities used in PKI-based deployments; orchestration tools and container platforms are commonly used to scale broker clusters in cloud-native environments.
MQTT defines three Quality of Service (QoS) levels to balance delivery assurance with resource use: at most once (QoS 0), at least once (QoS 1), and exactly once (QoS 2). QoS 0 provides best-effort delivery without acknowledgements; QoS 1 uses PUBACK and retransmission for acknowledgment; QoS 2 uses a two-phase handshake (PUBREC, PUBREL, PUBCOMP) to ensure exactly-once delivery semantics. Session persistence, message queues, and retained messages interact with QoS to provide durable delivery across client reconnects; broker implementations may offer persistent storage, in-memory queues, or integration with databases and message stores for high-availability patterns. For large-scale deployments, clustering, shared subscriptions, and load balancing are applied to meet throughput and latency requirements, often in conjunction with network-level techniques and transport optimizations.
Security for MQTT is typically layered atop transport protocols and broker features. Transport Layer Security (TLS) is commonly used to provide confidentiality, integrity, and server authentication; mutual TLS can provide strong client authentication using X.509 certificates issued by certificate authorities. Brokers often implement username/password authentication, token-based schemes, OAuth 2.0 integration, and access-control lists to restrict topic operations per client identity. Additional protections include payload encryption at the application layer, client authorization hooks, logging and auditing integrations, and intrusion detection systems. Secure gateway designs emphasize key management, hardware security modules, and compliance with regulatory frameworks for critical infrastructure and industrial systems.
A wide range of broker and client implementations exist across programming languages and platforms, from embedded C libraries for microcontrollers to enterprise-grade brokers and cloud-managed services. Notable brokers and implementations span open-source projects, commercial products, and cloud vendor offerings; similarly, SDKs provide client libraries in languages such as C, C++, Java, Python, JavaScript, Go, Rust, and .NET. Gateways and protocol adapters often accompany SDKs to integrate with fieldbus technologies and industrial protocols. Ecosystem tooling includes testing frameworks, protocol analyzers, management consoles, and certification programs supported by standards organizations and industry consortia.
MQTT is widely used in Internet of Things scenarios including smart home systems, industrial IoT, vehicle telematics, asset tracking, and remote monitoring where constrained bandwidth and intermittent connectivity are common. It has been adopted in energy management, healthcare telemetry, agriculture sensing, and building automation, and is integrated into cloud platforms, edge computing frameworks, and message-driven microservices architectures. The protocol’s lightweight nature and publish–subscribe model make it attractive for mobile messaging, real-time dashboards, and event distribution across distributed systems, with extensive deployments in consumer, enterprise, and industrial sectors.
Andy Stanford-Clark Arlen Nipper OASIS ISO/IEC TLS X.509 OAuth 2.0 SCADA container cloud computing Java Python C++ Rust (programming language) Go (programming language) JavaScript .NET Framework embedded system microcontroller edge computing industrial control system telemetry vehicle telematics asset tracking building automation energy management healthcare agriculture smart home Internet of Things publish–subscribe pattern message bus event-driven architecture certificate authority hardware security module intrusion detection system access control list keepalive long polling WebSocket TCP/IP broker (message broker) cluster (computing) load balancing data persistence message queue retained message session (computer science) protocol analyzer software development kit open-source software commercial software cloud platform gateway (networking) protocol translator fieldbus industrial protocol monitoring system provisioning orchestration (computing) security token authentication authorization logging auditing diagnostics two-phase commit handshake (computing) quality of service exactly-once delivery at-least-once delivery best-effort delivery retransmission acknowledgement (data networks) reason code (protocol) user property message framing binary protocol control packet publish (message) subscribe (computing) unsubscribe (computing) ping (networking) disconnect (computing) service-level agreement high availability fault tolerance scalability performance engineering diagnostic tool software development kit (SDK) open standard standards organization industrial consortia