Publish/subscribe vs HTTP request/response
HTTP is a pull model: a client asks a server for a resource and waits for a response. MQTT is a push model: a publisher sends a message to a topic on the broker, and the broker immediately delivers it to every current subscriber. There is no polling, no persistent connection from each device to every other device, and no need for clients to know each other's addresses. This decoupling is critical at IoT scale — a temperature sensor publishing every 30 seconds does not care whether zero or a thousand subscribers are listening at that moment.
How MQTT Works
| Part | Role | Example |
|---|---|---|
| Broker | Central message server | Mosquitto, EMQX, HiveMQ |
| Publisher | Sends messages to topics | Temperature sensor |
| Subscriber | Receives matching topics | Automation controller |
| Topic | Hierarchical message path | home/living-room/temp |
Topics and wildcards
MQTT topics are hierarchical strings separated by slashes, like home/kitchen/humidity. Subscribers can use two wildcards: + matches a single level (e.g., home/+/humidity matches home/kitchen/humidity and home/bedroom/humidity), and # matches all remaining levels (e.g., home/# matches every topic under home/). The # wildcard must appear at the end of a subscription string. Wildcard subscriptions are powerful but must be used carefully — a # subscription on a busy broker can flood a client with unwanted messages.
QoS levels explained
- QoS 0 — At most once: the message is sent once with no acknowledgement. If the broker or subscriber is offline, the message is lost. Best for frequent sensor readings where a missed value does not matter.
- QoS 1 — At least once: the sender retransmits until it receives a PUBACK. The subscriber may receive duplicates; the application must handle them. Used for most home automation events.
- QoS 2 — Exactly once: a four-step handshake (PUBLISH → PUBREC → PUBREL → PUBCOMP) guarantees the message is delivered exactly once. Used for billing events or commands where duplicates cause real problems. The overhead is significant — avoid for high-frequency telemetry.
Retained messages and last-will messages
A retained message is stored by the broker against a topic. When a new subscriber connects, the broker immediately sends the most recent retained message for that topic — so a dashboard displays the current sensor value instantly rather than waiting for the next publish. Only one retained message is stored per topic; publishing a new one replaces the old.
A last-will message (Last Will and Testament, LWT) is registered by a client when it connects. If the client disconnects ungracefully — power loss, network failure — the broker publishes the will message on a specified topic. This is the standard mechanism for marking devices as offline in home automation systems like Home Assistant.
MQTT over WebSockets
Browsers cannot open raw TCP sockets, so MQTT in browser-based dashboards runs over WebSockets. The broker listens on a WebSocket port (commonly 8083 for plain or 8084 for TLS) and wraps MQTT framing inside WebSocket frames. Libraries like MQTT.js handle this transparently. This allows fully interactive browser dashboards that receive live sensor data without polling.
MQTT vs HTTP vs CoAP
| Protocol | Model | Transport | Overhead | Best for |
|---|---|---|---|---|
| MQTT | Pub/sub | TCP | Very low (2-byte min header) | IoT, smart home, telemetry |
| HTTP/REST | Request/response | TCP | High (headers ~200–800 bytes) | APIs, web services |
| CoAP | Request/response | UDP | Low (4-byte header) | Constrained devices, lossy networks |
Security
MQTT is not secure by default. A production deployment should use: TLS on port 8883 to encrypt the transport; username/password authentication at the MQTT level; and client certificates for mutual TLS where the broker cryptographically verifies each device's identity. Topic ACLs should restrict each client to only the topics it legitimately needs — a temperature sensor should not be able to publish to device/firmware/update. Publicly accessible unauthenticated brokers are a persistent IoT security problem.
Common platforms using MQTT
- Home Assistant: uses MQTT as its primary integration protocol for sensors, switches, and custom devices
- AWS IoT Core: fully managed MQTT broker scaling to billions of messages with IAM-based topic policies
- Azure IoT Hub: supports MQTT for device-to-cloud telemetry and cloud-to-device commands
- Mosquitto: the most widely deployed open-source MQTT broker, suitable from Raspberry Pi to production servers
Frequently Asked Questions
What does MQTT stand for?
It originally stood for Message Queuing Telemetry Transport, though today MQTT is commonly used as the protocol name by itself.
What is MQTT used for?
It is used for IoT telemetry, smart home events, device state updates, sensors, and lightweight machine-to-machine messages.
What port does MQTT use?
Plain MQTT commonly uses TCP port 1883. MQTT over TLS commonly uses TCP port 8883. MQTT over WebSockets typically uses port 8083 (plain) or 8084 (TLS).