What Is MQTT? A Beginner's Guide to the Protocol

How MQTT works

MQTT follows a publish/subscribe model instead of the request/response model of HTTP. Clients never talk to each other directly. Instead, a publisher sends a message to a topic on a central broker, and the broker forwards that message to every client that has subscribed to the topic. Publishers and subscribers are fully decoupled — they don't need to know about each other, run at the same time, or even know how many receivers exist.

A typical setup has three roles: publishers (for example, sensors sending readings), subscribers (for example, a dashboard or backend service), and the broker that connects them. A single client can both publish and subscribe.

For the protocol-level details — the MQTT control packet types, their structure, and how messages flow through the broker — see the MQTT protocol reference in the TBMQ docs.

Why MQTT is used for IoT

MQTT was designed for constrained devices and unreliable networks, which is exactly the environment most IoT fleets live in. Its advantages:

MQTT vs HTTP

HTTP is request/response: a client asks, the server answers, and the connection is typically short-lived. That's a poor fit for pushing frequent, small updates to many devices. MQTT keeps a long-lived connection open and pushes messages the instant they're published, with far less per-message overhead. See MQTT vs HTTP for a fuller comparison. For moving that device data into backend analytics pipelines, MQTT is often paired with a streaming platform — see MQTT vs Kafka.

Core MQTT concepts

Once the pub/sub basics click, these are the concepts worth knowing next: