MQTT 协议摘要

MQTT 协议概览

物联网 (IoT) 的轻量级通信标准

什么是 MQTT？

MQTT (Message Queuing Telemetry Transport) 是一种基于发布/订阅模式的轻量级消息传输协议。它专为低带宽、高延迟或网络不稳定的环境设计，是 IoT 设备事实上的标准。

核心铁三角 & 机制

Publisher (发布者)

角色：记者 / 传感器

负责产生数据并发送（如：温度传感器）。

核心

Broker (代理)

角色：邮局 / 分发中心

接收消息，筛选Topic (主题)，分发给订阅者。

Subscriber (订阅者)

角色：读者 / 手机App

只接收感兴趣的主题消息（如：显示温度）。

运作流程模拟 (Live Demo)

发布消息订阅消息

1. 连接
(TCP/IP)

→

2. 订阅
(Topic)

→

3. 发布
(Publish)

→

4. 路由
(Broker)

→

5. 接收
(Receive)

为什么适合物联网？

极低开销

报文头最小仅 2 字节。适合 GPRS/NB-IoT 等按流量计费场景。

QoS 服务质量

QoS 0: 发完即忘
QoS 1: 至少一次
QoS 2: 恰好一次

Last Will (遗嘱)

意外断线时，Broker 自动发送预设消息，便于状态监控。

Keep Alive

心跳保活机制，维持长连接，随时接收云端指令。

MQTT vs HTTP

特性	HTTP (Web)	MQTT (IoT)
设计模式	请求 / 响应	发布 / 订阅
连接方式	短连接 (通常)	长连接 (TCP)
报文大小	大 (繁重 Header)	极小 (二进制)
适用场景	网页、文件传输	传感器、实时控制

MQTT (Message Queuing Telemetry Transport) 是一种轻量级的、基于发布/订阅 (Publish/Subscribe) 模式的消息传输协议。

它专门为低带宽、高延迟或网络不稳定的环境设计，因此成为了物联网 (IoT) 和嵌入式系统事实上的标准通信协议。

以下是关于 MQTT 的详细介绍及其运作过程。

1. 核心概念：MQTT 的“铁三角”

要理解 MQTT，首先要理解它的三个核心角色和一种机制。我们可以把它想象成一个报刊订阅系统：

Publisher (发布者)：
- 相当于“记者”或“传感器”。
- 它负责产生数据（例如：温度传感器读取到 25°C）并将消息发送出去。
Subscriber (订阅者)：
- 相当于“读者” or “控制中心”。
- 它只接收它感兴趣的消息（例如：手机 App 想要显示温度）。
Broker (代理/服务器)：
- 相当于“邮局”或“报社分发中心”。
- 这是最关键的角色。它负责接收所有发布者的消息，根据“主题”进行筛选，然后分发给对应的订阅者。发布者和订阅者不需要知道彼此的存在，全靠 Broker 牵线搭桥。
Topic (主题)：
- 相当于“频道”或“报纸栏目”。
- 这是一个层级结构的字符串，例如 home/livingroom/temperature。发布者往这个主题发消息，只有订阅了这个主题的人才会收到。

2. MQTT 的运作过程 (Step-by-Step)

让我们通过一个具体的场景来演示：一个智能温度计（发布者）向你的手机 App（订阅者）发送室温数据。

第一步：连接 (Connect)

动作：温度计和手机 App 分别通过 TCP/IP 协议与 MQTT Broker 建立长连接。
细节：连接时通常需要提供 Client ID，有时还需要用户名和密码进行身份验证。

第二步：订阅 (Subscribe)

动作：手机 App 告诉 Broker：“我关心客厅温度”。
指令：App 向 Broker 发送订阅请求，主题为 home/livingroom/temp。
状态：此时，Broker 记下了 App 的需求。

第三步：发布 (Publish)

动作：温度计检测到当前温度是 24℃。
指令：温度计向 Broker 发送一条消息。
- Topic: home/livingroom/temp
- Payload (内容): "24" (或者 JSON 格式 {"val": 24})
注意：温度计并不知道手机 App 的存在，它只管发给 Broker。

第四步：路由与分发 (Broker Processing)

动作：Broker 收到消息后，检查谁订阅了 home/livingroom/temp。
结果：它发现手机 App 在订阅列表中。

第五步：接收 (Receive)

动作：Broker 将消息 "24" 转发给手机 App。
结果：App 收到数据并更新屏幕显示的温度。

3. 为什么它适合嵌入式和 IoT？

MQTT 之所以比 HTTP 更适合物联网，主要归功于以下几个特性：

A. 极低的开销

MQTT 的报文头非常小（最小只有 2 个字节）。相比于 HTTP 繁重的 Header，MQTT 在网络带宽有限（如 GPRS/NB-IoT）或按流量计费的场景下非常省流。

B. QoS (服务质量) 机制

MQTT 允许你根据网络状况和业务重要性选择三种服务级别：

QoS 0 (At most once)：“发完即忘”。只发一次，不保证送达。适用于丢失几个数据点也无所谓的传感器数据。
QoS 1 (At least once)：“至少一次”。保证送达，但可能会收到重复消息。适用于关键操作（如开锁指令）。
QoS 2 (Exactly once)：“恰好一次”。保证送达且不重复。机制最复杂，开销最大，适用于计费系统等高精度场景。

C. Last Will (遗嘱机制)

如果传感器突然断电或网络中断，Broker 会检测到连接断开。如果该设备预先设好了“遗嘱”，Broker 会自动向订阅者发送一条消息（例如：“设备已离线”）。这对于监控设备在线状态非常有用。

D. Keep Alive (心跳保活)

客户端和 Broker 之间会定时发送心跳包。如果一段时间没收到心跳，Broker 就判定客户端已掉线。这让设备能维持长连接，随时准备接收云端的控制指令。

总结对比

特性	HTTP (Web常用)	MQTT (IoT常用)
设计模式	请求/响应 (Request/Response)	发布/订阅 (Pub/Sub)
连接方式	短连接 (通常)	长连接 (TCP)
数据方向	客户端主动拉取	双向推送 (服务器可主动推给设备)
报文大小	大 (包含大量 Header)	极小 (二进制，省流量)
适用场景	网页浏览、文件上传	传感器采集、设备控制、即时通讯