MQTT: The Nervous System of IoT – Overview and Key Features

Billions of smart devices are interconnected worldwide. When these devices interact with each other like their owners, they form a global nervous system – the Internet of Things (IoT). IoT reshapes the IT landscape and demands attention to performance, security, and scalability.

Message Queuing Telemetry Transport (MQTT)

MQTT is a lightweight, publish/subscribe messaging protocol built on top of TCP/IP for machine‑to‑machine (M2M) communication. It provides telemetry capabilities that enable the rapid growth of diverse smart devices. The first version was authored by Stanford‑Clark, IBM, and Arlen Nipper.

Why Use MQTT?

A well‑known foreign company (abbreviated as FB) adopted MQTT for its messenger app, which requires a persistent connection without draining battery life. MQTT’s low bandwidth consumption and small code footprint make it ideal for devices with limited memory and processing power, especially over intermittent networks.

Other notable MQTT characteristics include:

· Open‑source and royalty‑free, easy to adopt and adapt

· Follows a one‑to‑many publish/subscribe model

· Small message header (2‑byte binary)

· Multiple Quality of Service (QoS) levels

· Simple command messages

· Payload‑agnostic data types

· Retained messages

· Clean sessions and persistent connections

· Last Will and Testament (LWT)

MQTT vs. HTTP

MQTT

HTTP

Design

Data‑centric

File‑centric

Model

Publish/Subscribe

Request/Response

Complexity

Simple commands

Complex

Message size

Small, binary header of 2 bytes

Larger, text‑based header

Service level

Three QoS levels

Uniform service level for all messages

Distribution

One‑to‑many

One‑to‑one

Example MQTT topology:

Quality of Service Levels

The QoS value determines how each message is delivered and is set per message.

QoS 0 (At most once)

When QoS 0 is set, no acknowledgment is expected and there is no retry policy. The message may arrive once or not at all; if the client disconnects or the server fails, the message is lost. This is the fastest delivery mode.

QoS 1 (At least once)

The client or broker attempts to deliver the message at least once, but duplicates may occur. After receiving a message, the broker sends a PUBACK. If the sender does not receive PUBACK, it retransmits with the DUP flag set. The broker then republishes to all subscribers and sends another PUBACK. Messages are stored persistently (e.g., on disk) until PUBACK is received. QoS 1 messages contain a Message ID.

QoS 2 (Exactly once)

QoS 2 adds an extra handshake to guarantee single delivery. The flow is PUBLISH → PUBREC → PUBREL → PUBCOMP. The message is stored on both client and broker until the final PUBCOMP is received, ensuring no duplicate delivery. QoS 2 messages also carry a Message ID.

Security in MQTT

MQTT is designed for lightweight communication in IoT, but security incurs processing and bandwidth overhead. Most implementations augment MQTT with SSL/TLS.

Security is layered:

Network level: Physical security or VPNs provide secure connections.

Transport level: TLS/SSL encrypts traffic and authenticates parties.

Application level: Client IDs, usernames/passwords, and optional payload encryption enable device authentication.

MQTT in Action: Home Monitoring Solution

A typical MQTT‑based application is a home monitoring system, e.g., reporting the current temperature of a room heater on demand.

As with any distributed application, monitoring is essential to detect failures and ensure a good user experience.

Catchpoint now supports MQTT monitoring, allowing performance and availability testing by publishing/subscribing to topics and measuring latency.

In an upcoming blog we will dissect MQTT traffic captured with Wireshark, helping readers understand the interaction between MQTT clients and brokers.