|
| 1 | +--- |
| 2 | +layout: docwithnav-mqtt-broker |
| 3 | +title: MQTT broker |
| 4 | +description: What is MQTT broker? Learn how the MQTT protocol works, what MQTT server does, and how clients use topics, and connections for reliable IoT communication |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +* TOC |
| 9 | +{:toc} |
| 10 | + |
| 11 | + |
| 12 | +[MQTT](/docs/mqtt-broker/user-guide/mqtt-protocol/) is a lightweight, publish/subscribe messaging protocol widely used in the Internet of Things (IoT) and other distributed systems. |
| 13 | +It is specifically designed to work efficiently in environments with limited resources, low bandwidth, high latency, or unreliable network connections. |
| 14 | + |
| 15 | +At the heart of every MQTT architecture lies the <a href="/products/mqtt-broker/" target="_blank" style="color: inherit; text-decoration: none;">MQTT broker</a> — |
| 16 | +the central server that manages all communication between clients. |
| 17 | +The broker is responsible for receiving messages from publishers, determining which subscribers are interested in those messages, and reliably delivering them according to the protocol’s rules. |
| 18 | +In this way, the broker acts as the backbone of the MQTT system, ensuring seamless, secure, and efficient message exchange. |
| 19 | + |
| 20 | + |
| 21 | + |
| 22 | +### MQTT Clients |
| 23 | + |
| 24 | +An <a href="/products/mqtt-broker/" target="_blank" style="color: inherit; text-decoration: none;">MQTT client</a> is any device, application, or service that connects to the broker to send or receive messages. |
| 25 | +Clients can range from small, resource-constrained IoT sensors to complex enterprise applications. |
| 26 | +Common examples include: |
| 27 | + |
| 28 | +* **IoT devices** that publish sensor data, such as temperature, humidity, or GPS location. |
| 29 | +* **Mobile or web applications** that subscribe to updates from connected devices. |
| 30 | +* **Back-end services** that collect, process, or visualize incoming data streams. |
| 31 | + |
| 32 | +Each client can take on one or more roles: |
| 33 | + |
| 34 | +* **Publisher**: Sends (publishes) messages to a defined topic. |
| 35 | +* **Subscriber**: Receives (subscribes to) messages from one or more topics. |
| 36 | +* **Hybrid**: Acts as both a publisher and a subscriber, depending on the use case. |
| 37 | + |
| 38 | +By separating publishers and subscribers through the broker, MQTT clients remain loosely coupled, making systems more flexible, scalable, and easier to maintain. |
| 39 | + |
| 40 | +### MQTT Topics |
| 41 | + |
| 42 | +An <a href="/products/mqtt-broker/" target="_blank" style="color: inherit; text-decoration: none;">MQTT topic</a> is a structured string used by the broker to **route messages** between publishers and subscribers. |
| 43 | +Topics define the subject or channel of communication and are the backbone of the publish/subscribe model. |
| 44 | + |
| 45 | +Key characteristics: |
| 46 | + |
| 47 | +* **Hierarchical structure**: Topics are organized in levels separated by slashes (`/`). |
| 48 | + Example: `home/livingroom/temperature` |
| 49 | +* **Message flow**: |
| 50 | + |
| 51 | + * **Publishers** send messages to a specific topic. |
| 52 | + * **Subscribers** register their interest in one or more topics and receive all messages published to them. |
| 53 | + |
| 54 | +#### Wildcards in Topics |
| 55 | + |
| 56 | +MQTT supports special characters called <a href="/products/mqtt-broker/" target="_blank" style="color: inherit; text-decoration: none;">MQTT wildcards</a> to simplify subscription patterns: |
| 57 | + |
| 58 | +* `+` (single-level wildcard) — matches exactly one level in the topic hierarchy. |
| 59 | + Example: `home/+/temperature` → matches `home/livingroom/temperature` and `home/kitchen/temperature`. |
| 60 | +* `#` (multi-level wildcard) — matches all remaining levels in the topic hierarchy. |
| 61 | + Example: `home/#` → matches `home/livingroom/temperature`, `home/kitchen/humidity`, and anything else under `home/`. |
| 62 | + |
| 63 | +This flexible topic system allows clients to filter messages with precision, making MQTT highly efficient for large-scale, event-driven communication. |
| 64 | + |
| 65 | +### Role of the MQTT Broker |
| 66 | + |
| 67 | +The **MQTT broker** is the central component that enables communication in an MQTT system. |
| 68 | +Clients never communicate directly with each other — all messages flow through the broker. |
| 69 | +By acting as the trusted intermediary, the broker guarantees that messages are delivered securely, reliably, and according to the rules of the protocol. |
| 70 | + |
| 71 | +Key responsibilities of the broker include: |
| 72 | + |
| 73 | +* **Managing client connections**: Establishing, monitoring, and maintaining sessions with MQTT clients. |
| 74 | +* **Authentication and authorization**: Validating client identities and enforcing access control policies to ensure only authorized clients can publish or subscribe. |
| 75 | +* **Message routing**: Receiving published messages and efficiently distributing them to all clients subscribed to the relevant topics. |
| 76 | +* **Session and state management**: Tracking client subscriptions and, if configured, storing undelivered messages for clients that are offline. |
| 77 | +* **Quality of Service (QoS)**: Guaranteeing message delivery according to the selected <a href="/products/mqtt-broker/" target="_blank" style="color: inherit; text-decoration: none;">MQTT QoS</a> level — *At most once (QoS 0)*, *At least once (QoS 1)*, or *Exactly once (QoS 2)*. |
| 78 | + |
| 79 | +In short, the broker serves as the **backbone of the MQTT network**, ensuring that communication between clients is scalable, secure, and dependable. |
| 80 | + |
| 81 | +### How It Works |
| 82 | + |
| 83 | +The operation of an MQTT system can be broken down into distinct stages — from the moment a client connects to the broker, through authentication and authorization, to message publishing and distribution. |
| 84 | + |
| 85 | +#### Client Connection |
| 86 | + |
| 87 | +* A client (device, app, or service) initiates a connection to the broker using the **CONNECT** packet. |
| 88 | +* This packet typically includes: |
| 89 | + |
| 90 | + * Client identifier (`clientId`) |
| 91 | + * Protocol version (e.g., MQTT 3.1.1 or MQTT 5.0) |
| 92 | + * Optional username and password |
| 93 | + * Clean session flag or session expiry interval (for session persistence) |
| 94 | + * Last Will and Testament (LWT) message, if defined |
| 95 | + |
| 96 | +#### Authentication & Authorization |
| 97 | + |
| 98 | +* The broker validates the connection request by checking credentials (username/password, certificates for SSL/TLS, or token-based mechanisms). |
| 99 | +* Once authenticated, the broker enforces **authorization policies**, determining which topics the client is allowed to **publish** to and **subscribe** from. |
| 100 | +* If the connection is accepted, the broker replies with a **CONNACK** packet confirming session parameters. If not, the connection is refused. |
| 101 | + |
| 102 | +#### Subscribing to Topics |
| 103 | + |
| 104 | +* To receive messages, the client sends a **SUBSCRIBE** packet specifying one or more topics (with optional wildcards) and the desired **QoS level**. |
| 105 | +* The broker registers the client’s subscription and replies with a **SUBACK** packet that confirms which QoS levels were granted. |
| 106 | + |
| 107 | +#### Publishing Messages |
| 108 | + |
| 109 | +* When a client wants to send data, it sends a **PUBLISH** packet to the broker. |
| 110 | +* The packet contains: |
| 111 | + |
| 112 | + * The topic name |
| 113 | + * The message payload |
| 114 | + * The QoS level for delivery reliability |
| 115 | + * Retain flag (if the message should be stored as the last known good value for that topic) |
| 116 | +* Depending on QoS, the broker and client may exchange acknowledgment packets (**PUBACK**, **PUBREC**, **PUBREL**, **PUBCOMP**) to guarantee delivery. |
| 117 | + |
| 118 | +#### Message Distribution |
| 119 | + |
| 120 | +* The broker receives the published message and looks up all active subscriptions that match the topic. |
| 121 | +* For each matching subscriber, the broker forwards the message: |
| 122 | + |
| 123 | + * Respecting the **QoS level** agreed upon with each subscriber. |
| 124 | + * Delivering retained messages where applicable. |
| 125 | + * Storing messages for offline subscribers if persistent sessions are enabled. |
| 126 | + |
| 127 | +#### Receiving Messages |
| 128 | + |
| 129 | +* Subscribers receive the message in a **PUBLISH** packet from the broker. |
| 130 | +* Based on QoS, the subscriber may need to send back acknowledgment packets to confirm receipt. |
| 131 | +* Once processed, subscribers can act on the message — logging it, storing it, visualizing it, or triggering actions. |
| 132 | + |
| 133 | +#### Disconnecting |
| 134 | + |
| 135 | +* When a client no longer needs the connection, it sends a **DISCONNECT** packet. |
| 136 | +* If the client disconnects unexpectedly, the broker triggers the **Last Will and Testament (LWT)** message (if configured) and may keep the session alive based on the persistence settings. |
| 137 | + |
| 138 | +This end-to-end lifecycle — from connection and authentication to message delivery and disconnection — |
| 139 | +makes MQTT a lightweight but **robust messaging protocol** for everything from simple IoT gadgets to massive distributed systems. |
| 140 | + |
| 141 | +### Key Features of an MQTT Broker |
| 142 | + |
| 143 | +An MQTT broker combines **protocol-level features** of MQTT with **system-level capabilities** to ensure efficient, secure, and reliable messaging. |
| 144 | + |
| 145 | +#### MQTT Protocol Features Supported by the Broker |
| 146 | + |
| 147 | +* **Quality of Service (QoS)**: Guarantees message delivery at different levels — *at most once (0)*, *at least once (1)*, or *exactly once (2)*. |
| 148 | +* **Keep Alive mechanism**: Ensures the connection between client and broker stays active by requiring periodic communication, helping detect broken connections quickly. |
| 149 | +* **Last Will and Testament (LWT)**: Sends a predefined message if a client disconnects unexpectedly, helping detect failures automatically. |
| 150 | +* **Retained messages**: Stores the last message on a topic so new subscribers receive the most recent state instantly. |
| 151 | +* **Topic-based routing**: Efficiently matches published messages to subscribers using hierarchical topics and wildcards. |
| 152 | +* **Session persistence**: Maintains subscriptions and undelivered messages for clients that reconnect, allowing reliable communication even after temporary disconnections. |
| 153 | +* **Shared subscriptions** (MQTT 5.0): Distributes messages among a group of subscribers to balance load. |
| 154 | + |
| 155 | +These are some of the most important MQTT features supported by brokers. |
| 156 | +Depending on the version of the protocol (MQTT 3.1.1 or 5.0) and the specific broker implementation, many more features may be available to enhance reliability, efficiency, and security. |
| 157 | + |
| 158 | +> TBMQ supports the full range of MQTT 3.x and MQTT 5.0 protocol features. |
| 159 | +
|
| 160 | +#### Broker Capabilities |
| 161 | + |
| 162 | +* **Scalability**: Handles thousands or millions of simultaneous client connections and messages with consistent reliability. |
| 163 | +* **Performance**: Optimized for low latency and high throughput, even in large distributed systems. |
| 164 | +* **Durability**: Ensures that critical messages and session data are stored persistently (e.g., in databases or disk-backed queues), so they survive restarts or crashes. |
| 165 | +* **Security**: Provides TLS/SSL encryption, authentication, and fine-grained access control to ensure safe communication. |
| 166 | +* **High availability & clustering**: Supports clustering, load balancing, and fault tolerance for production-grade deployments. |
| 167 | +* **Integration**: Connects seamlessly with external systems such as databases, Kafka, or cloud services for data processing and analytics. |
| 168 | + |
| 169 | +> TBMQ provides all of these capabilities out of the box: horizontal scalability to millions of clients, high throughput with low latency, persistence and durability powered by Redis/Kafka, |
| 170 | +> built-in TLS/SSL security, clustering with fault tolerance, and integration with external systems like Kafka, other MQTT brokers, and HTTP-based services. |
| 171 | +
|
| 172 | +### Types of MQTT Brokers |
| 173 | + |
| 174 | +MQTT brokers come in different forms depending on how they are deployed, licensed, and used. The main categories are: |
| 175 | + |
| 176 | +1. **Open-source brokers** |
| 177 | + |
| 178 | + * Free to use and highly customizable, with active developer communities. |
| 179 | + * Suitable for prototyping, self-hosted deployments, and integration into larger systems. |
| 180 | + |
| 181 | +2. **Commercial brokers** |
| 182 | + |
| 183 | + * Provide enterprise-grade features such as clustering, monitoring dashboards, advanced security, and SLA-backed support. |
| 184 | + * Ideal for organizations that need guaranteed reliability, high availability, and professional support. |
| 185 | + |
| 186 | +3. **Cloud-based brokers (MQTT-as-a-Service)** |
| 187 | + |
| 188 | + * Fully managed services where the provider handles deployment, scaling, maintenance, and uptime. |
| 189 | + * Great for rapid adoption and use cases where infrastructure management should be outsourced. |
| 190 | + |
| 191 | +4. **Embedded brokers** |
| 192 | + |
| 193 | + * Extremely lightweight brokers that run directly on edge devices, gateways, or inside applications. |
| 194 | + * Useful for local processing, offline-first scenarios, or edge computing environments where low latency is critical. |
| 195 | + |
| 196 | +### How to Choose the Right MQTT Broker |
| 197 | + |
| 198 | +Selecting the right MQTT broker depends on your project’s scale, requirements, and long-term goals. The following criteria can help guide the decision: |
| 199 | + |
| 200 | +* **Scalability**: Ensure the broker can handle your projected number of client connections and message throughput, with room to grow as your system expands. |
| 201 | +* **High availability & clustering**: Look for features like clustering, replication, and load balancing to guarantee uptime and fault tolerance in production environments. |
| 202 | +* **Performance**: Evaluate latency, throughput, and resource efficiency under real-world load conditions to ensure the broker meets your responsiveness needs. |
| 203 | +* **Security**: Check for support of TLS/SSL encryption, authentication, authorization, and fine-grained access controls to protect data and devices. |
| 204 | +* **Persistence**: Consider whether the broker provides durable message storage — including retained messages, offline queues, or integration with external databases. |
| 205 | +* **Integration capabilities**: Verify compatibility with your ecosystem, such as Kafka, SQL/NoSQL databases, monitoring tools, or cloud platforms. |
| 206 | +* **Community & support**: An active open-source community or available enterprise support can make a big difference in troubleshooting and long-term maintenance. |
| 207 | +* **Cost**: Balance your budget against needs — choosing between open-source (free, DIY), commercial (license + support), or cloud (subscription-based, managed) options. |
| 208 | + |
| 209 | +By weighing these factors, you can select a broker that not only meets your current needs but also scales with your system as it evolves. |
| 210 | + |
| 211 | +> <a href="/pricing/?section=tbmq" target="_blank" style="color: inherit; text-decoration: none;">TBMQ</a> is built to meet all these criteria — |
| 212 | +> it offers enterprise-level scalability, clustering, persistence, strong security, and deep integration options while remaining easy to operate and cost-efficient. |
| 213 | +> This makes it a strong choice for both open-source adopters and enterprises looking for a production-ready MQTT platform. |
| 214 | +
|
| 215 | +### Final Words |
| 216 | + |
| 217 | +The MQTT broker is the backbone of any MQTT-based system, enabling efficient and reliable communication between distributed devices and services. |
| 218 | +It plays a critical role in diverse domains such as IoT ecosystems, smart homes, industrial automation, connected vehicles, and large-scale data infrastructures. |
| 219 | + |
| 220 | +By offloading responsibilities like message routing, delivery guarantees, and connection management to the broker, client devices remain simple, lightweight, and resource-efficient. |
| 221 | +This not only reduces device complexity but also improves scalability, security, and overall system reliability — making the MQTT broker a cornerstone of modern connected applications. |
0 commit comments