What MQTT Is and Why It Was Created
MQTT — Message Queuing Telemetry Transport — is a publish-subscribe messaging protocol designed for constrained devices and low-bandwidth, high-latency, or unreliable networks. It was created in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Cirrus Link) to monitor oil pipelines via satellite. Today it is the dominant protocol for Internet of Things (IoT) device communication, supported natively in cloud platforms from AWS, Azure, Google Cloud, and hundreds of embedded device SDKs.
The protocol's design philosophy is minimum bandwidth, minimum battery drain. An MQTT control packet can be as small as 2 bytes. Compare that to an HTTP request, which adds at minimum several hundred bytes of headers even for a simple GET. For a temperature sensor that wakes up every 30 seconds to transmit a 10-byte reading, this difference matters enormously for battery life and network capacity when multiplied across thousands of devices.
The Publish-Subscribe Model and IP Addresses
MQTT does not use direct device-to-device communication. Every message passes through a central server called a broker. The broker has a fixed IP address (or a DNS hostname that resolves to one) because all devices in the network need to find and maintain connections to it.
The architecture works like this:
- Publishers are devices that send data. A temperature sensor publishes a reading to the broker on a specific topic, such as
home/livingroom/temperature. - Subscribers are devices or applications that receive data. Your smartphone app subscribes to
home/livingroom/temperatureand receives each new reading the sensor publishes. - The broker sits in the middle at a known IP address, routing messages from publishers to all matching subscribers. It maintains the list of subscriptions and queues messages when subscribers are temporarily offline.
A device only needs to know one IP address: the broker's. It never needs to know the IP addresses of other devices. This decoupling is one of MQTT's key architectural advantages — devices can be added, removed, or replaced without reconfiguring other devices in the network.
MQTT at the Network Layer
MQTT runs over TCP/IP. The default port is 1883 for unencrypted connections. For TLS-encrypted connections, the standard port is 8883. MQTT over WebSockets (for browser-based clients) uses port 80 or 443 depending on TLS.
The TCP connection is persistent. Unlike HTTP where each request creates a new connection, MQTT clients establish a single TCP connection to the broker and maintain it for the duration of their session. This persistent connection eliminates the latency and overhead of repeated TCP handshakes and TLS negotiations, which is critical for time-sensitive sensor data and command-and-control traffic.
When a device cannot maintain a persistent connection (due to cellular network constraints or power management), MQTT's clean session and persistent session features allow the broker to queue messages for the device until it reconnects.
MQTT Topic Structure
Topics are hierarchical UTF-8 strings that define where messages are published and subscribed. They use forward slashes as separators:
factory/line1/machine3/temperaturehome/kitchen/humiditybuilding/floor3/hvac/status
Subscribers can use wildcards to subscribe to multiple topics at once:
+(single level wildcard):home/+/temperaturematcheshome/kitchen/temperature,home/bedroom/temperature, etc.#(multi-level wildcard):home/#matches everything underhome/including all nested levels.
Good topic design is critical for both performance and security. Overly broad subscriptions (like subscribing to #) generate unnecessary traffic and can expose data to unintended subscribers.
Quality of Service Levels
MQTT defines three QoS levels that trade message delivery guarantee against overhead:
| QoS Level | Guarantee | Overhead | Best For |
|---|---|---|---|
| QoS 0 (At most once) | Message sent once, no acknowledgment | Lowest | Sensor readings where occasional loss is acceptable |
| QoS 1 (At least once) | Message delivered at least once, may duplicate | Moderate (acknowledgment packet) | Commands, alerts where delivery is required |
| QoS 2 (Exactly once) | Message delivered exactly once, no duplicates | Highest (4-packet handshake) | Billing events, financial transactions |
For most sensor telemetry, QoS 0 or QoS 1 is appropriate. QoS 2 is used sparingly because the 4-packet exchange significantly increases latency and broker load.
MQTT vs. HTTP vs. CoAP for IoT
| Protocol | Model | Min Packet Size | Connection | Best For |
|---|---|---|---|---|
| MQTT | Publish-subscribe | 2 bytes | Persistent TCP | Many devices, low power, real-time telemetry |
| HTTP/REST | Request-response | ~200 bytes | New per request (HTTP/1.1) | Cloud API calls, web dashboards |
| CoAP | Request-response | 4 bytes | UDP, connectionless | Constrained devices on lossy networks |
| AMQP | Message queue | ~8 bytes | Persistent TCP | Enterprise message routing, complex routing rules |
| WebSocket | Bidirectional stream | ~6 bytes | Persistent | Browser-based real-time applications |
Popular MQTT Brokers
Mosquitto is the most widely used open-source MQTT broker, maintained by the Eclipse Foundation. It is lightweight, runs on hardware as small as a Raspberry Pi, and supports MQTT 3.1.1 and 5.0. Mosquitto is suitable for development and small to medium IoT deployments.
EMQX is a high-performance open-source broker designed for large-scale deployments, supporting millions of concurrent connections with clustering and horizontal scaling. It includes a web-based management console and REST API for monitoring.
HiveMQ is a commercial broker optimized for enterprise deployments with advanced security features, Kubernetes support, and compliance certifications.
Cloud-managed MQTT services include AWS IoT Core, Azure IoT Hub, and Google Cloud IoT Core, which handle broker infrastructure, scaling, and integration with cloud processing services without requiring self-hosted broker management.
Securing MQTT: Critical Considerations
Default MQTT configurations are often completely open — no authentication, no encryption, port 1883 accessible to anyone with network access. This was acceptable on isolated industrial networks but is dangerous on any internet-connected deployment. Securing an MQTT deployment requires:
- TLS encryption: Use port 8883 with valid certificates. Without TLS, all MQTT traffic including credentials is transmitted in plaintext. Any network observer can capture and inject messages.
- Authentication: Configure username and password authentication at minimum. For production, use client certificate authentication (mutual TLS) so each device has a cryptographically verified identity.
- Authorization: Restrict which topics each client can publish to and subscribe from. A temperature sensor should not be able to subscribe to command topics. Brokers support ACL (Access Control List) configuration to enforce per-client topic permissions.
- Firewall rules: If the broker is on the public internet, restrict port 8883 access to known client IP ranges where possible. Monitoring for unauthorized connection attempts is also important.
MQTT 5.0 vs. 3.1.1
MQTT 5.0 (released 2019) added significant features over the widely deployed 3.1.1:
- Reason codes: All responses include a reason code explaining success or failure, replacing the ambiguous success/failure of 3.1.1.
- User properties: Key-value metadata can be attached to any MQTT message, enabling use cases like message tracing and custom routing.
- Shared subscriptions: Multiple subscribers can share a subscription group, with the broker distributing messages across them — enabling load-balanced processing without requiring a separate message queue.
- Message expiry: Messages can be given an expiry time, after which the broker discards them if undelivered. Prevents stale commands from executing after reconnect.
- Flow control: Clients can specify the maximum number of unacknowledged QoS 1 and 2 messages, preventing broker overload on slow connections.
Common Misconceptions
MQTT and HTTP are interchangeable for IoT
They are not. HTTP follows a request-response model — a client asks for data and a server responds. MQTT uses publish-subscribe — publishers send data when it changes and subscribers receive it immediately without polling. For IoT devices that generate continuous telemetry, HTTP polling generates enormous overhead (repeated connections, headers, repeated authentication). MQTT's persistent connection and minimal overhead make it the right choice for high-frequency sensor data.
The broker is a single point of failure
In a poorly designed deployment, yes. But enterprise MQTT brokers like EMQX and HiveMQ support clustered deployments with redundant nodes and automatic failover. Cloud-managed services like AWS IoT Core are inherently highly available. The broker is architecturally central but does not have to be a reliability bottleneck if designed correctly.
MQTT is only for small devices
MQTT is optimized for constrained devices, but it is equally appropriate for server-to-server messaging, microservice event streaming, and real-time dashboard data delivery. Any scenario where you want one-to-many message distribution with persistent connections and low overhead is a valid MQTT use case regardless of device type.
QoS 2 is always the safest choice
QoS 2 guarantees exactly-once delivery, which sounds ideal, but the 4-packet handshake multiplies broker and network load. For sensor telemetry where occasional duplicate readings are harmless, QoS 2 wastes resources. For commands or financial events, QoS 2 is justified. Choose QoS based on your specific message semantics, not a blanket assumption that higher is better.
Pro Tips
- Always give your broker a stable hostname, not just an IP address. Device firmware is hard to update. If your broker's IP changes, every device needs a firmware update. A DNS hostname provides flexibility to change the underlying IP without touching device configuration.
- Design topic hierarchies before deployment, not after. Retrofitting topic structure after hundreds of devices are deployed requires firmware updates across your entire fleet. Plan the hierarchy, document it, and treat it as a formal schema that requires change control.
- Enable retained messages for device state topics. A retained message means the broker stores the last published value for a topic and immediately delivers it to any new subscriber. New subscribers and reconnecting clients immediately know the current device state without waiting for the next publish.
- Use Last Will and Testament (LWT) for device health monitoring. LWT allows a device to register a message with the broker that will be published automatically if the device disconnects unexpectedly. Subscribe to LWT topics to detect ungraceful disconnects that indicate power loss, network failure, or device crash.
- Monitor broker connection counts and message rates continuously. An unexpected spike in new connections may indicate a firmware bug causing devices to repeatedly reconnect. A drop in expected message rates may indicate silent device failure. These metrics are the primary operational signals for IoT fleet health.
- Separate test and production broker infrastructure completely. Test devices publishing to a production broker — or production devices accidentally pointed at a test broker after a configuration mistake — cause subtle data corruption that is difficult to trace. Separate broker instances, separate network segments, separate credentials.
Explore your current network connection and device IP details here.