📚 课程目录第4章 MQTT协议详解

MQTT协议详解：MQTT原理、发布/订阅模型、主题、服务质量(QoS)、保留消息、遗嘱消息

一、MQTT核心原理：轻量级消息传输的诞生逻辑

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是一种基于TCP/IP协议栈的轻量级发布/订阅消息协议，由IBM于1999年提出，专为低带宽、高延迟、网络不稳定的物联网环境设计。它的核心设计哲学是“极简协议头 + 异步解耦通信”，一个最小的MQTT控制报文仅需2字节固定头，远小于HTTP动辄数百字节的头部开销。

MQTT协议工作在TCP之上，默认端口为1883（明文）和8883（TLS加密）。与HTTP的请求/响应模式不同，MQTT采用客户端-代理（Broker）架构，所有消息都经由Broker中转，客户端之间不直接通信。这种设计使得设备无需知道彼此IP地址，也无需同时在线即可完成消息交换。

上图展示了MQTT的基本通信模型：ESP8266传感器作为发布者，将温度数据发布到主题 sensor/temp；手机App、PC看板、继电器分别作为订阅者，向Broker订阅自己关心的主题。Broker负责将消息路由给所有匹配的订阅者，整个过程发布者与订阅者完全解耦。

二、发布/订阅模型与主题（Topic）机制

MQTT的发布/订阅模型是一种消息模式，它打破了传统点对点通信的束缚。发布者发送消息时不指定接收者，只指定一个主题；订阅者声明自己感兴趣的主题，Broker负责匹配并转发。这种模式带来三大优势：

空间解耦：发布者和订阅者不需要知道对方的存在，无需交换IP地址。
时间解耦：订阅者离线时，发布者仍可发布消息（配合保留消息或持久会话）。
同步解耦：发布/订阅操作都是异步的，不会阻塞发送方。

主题（Topic）是MQTT消息路由的核心，采用UTF-8字符串，用/作为层级分隔符，形成树状结构。主题支持两种通配符：

通配符	名称	匹配规则	示例
`+`	单层通配符	匹配一个层级	`sensor/+/temp` 匹配 `sensor/room1/temp`、`sensor/room2/temp`
`#`	多层通配符	匹配任意多个层级（必须放在末尾）	`sensor/#` 匹配 `sensor/temp`、`sensor/room1/humidity`

主题设计建议：采用设备类型/位置/数据类别的层级结构，例如 esp8266/客厅/温度。避免以/开头或结尾（如 /sensor 或 sensor/），因为这会创建空层级，容易造成通配符匹配混乱。主题中不要包含空格或中文（部分Broker支持但兼容性差），建议使用room1_temp或room1/temp格式。

三、服务质量（QoS）：消息可靠性的三级保障

MQTT定义了三个QoS等级，用于控制消息投递的可靠性，用户需在发布端和订阅端分别指定QoS，Broker取两者中的最大值作为实际投递等级。

QoS等级	名称	发送机制	消息可靠性	适用场景
0	至多一次	直接发送，不等待确认	可能丢失	传感器高频数据（温度每5秒上报，丢一帧无所谓）
1	至少一次	发送后等待PUBACK确认，超时重发	不丢失，但可能重复	设备状态上报（重复收到可覆盖处理）
2	恰好一次	四次握手（PUBLISH→PUBREC→PUBREL→PUBCOMP）	不丢失、不重复	计费指令、开关控制（重复执行会造成严重问题）

在ESP8266的PubSubClient库中，通过publish()和subscribe()函数的第三个参数指定QoS：

// 发布QoS 1消息
client.publish("sensor/temp", "25.5", 1);

// 订阅QoS 2主题
client.subscribe("device/switch", 2);

// 回调函数中处理消息
void callback(char* topic, byte* payload, unsigned int length) {
  // 注意：QoS 1可能收到重复消息，需做去重处理
}

QoS误区提醒：QoS 2并不代表“绝对不丢消息”，它只保证在网络连接正常的前提下不重不丢。如果设备断电或网络长时间中断，消息仍然会丢失。另外，QoS等级越高，网络开销越大（QoS 2需要4次报文交互），在ESP8266这类资源受限设备上，不要对所有消息都使用QoS 2，应根据业务重要性分级使用。

四、保留消息（Retained Message）与遗嘱消息（Will Message）

保留消息是MQTT为“新订阅者快速获取最新状态”设计的机制。当发布者以retained=true发布消息时，Broker会存储该主题的最后一条保留消息。当有新的订阅者订阅该主题时，Broker会立即将这条保留消息推送给新订阅者，而无需等待下一次发布。

// 发布保留消息（ESP8266上电时发布当前状态）
client.publish("device/status", "online", 1, true);  // 第4个参数retained=true

// 清除保留消息（发布空消息体并设置retained=true）
client.publish("device/status", "", 1, true);

遗嘱消息（Will Message）是MQTT为“异常离线通知”设计的机制。客户端在连接Broker时，可以预先登记一条遗嘱消息（包含主题、内容、QoS、保留标志）。当客户端非正常断开（如断电、网络断线、设备崩溃）时，Broker会代替该客户端发布这条遗嘱消息，通知其他订阅者“此设备已离线”。

// 在connect时设置遗嘱消息
const char* willTopic = "device/status";
const char* willMsg = "offline";
client.connect("ESP8266_01", "username", "password", 
               willTopic, 1, true, willMsg);  
// 参数依次为：遗嘱主题、遗嘱QoS、遗嘱保留标志、遗嘱内容

  实战场景：智能家居网关管理。网关正常关机时，主动发布 device/status = "offline"（保留消息）；若网关突然断电，Broker检测到连接断开后，自动发布遗嘱消息 device/status = "offline"。手机App订阅 device/status 后，无论哪种情况都能及时更新设备状态。若网关重启后发布 device/status = "online"（保留消息），新订阅的App也能立即获取当前状态。

五、案例复盘：ESP8266温控系统消息设计

下面是一个完整的ESP8266温控项目消息设计示例，综合运用了上述所有机制：

// 主题规划
// 传感器数据上报（QoS 0，高频，允许丢失）
//   esp/room1/temp     → 温度值，如 "25.5"
//   esp/room1/humidity → 湿度值，如 "60.2"
// 设备控制指令（QoS 2，必须不重不丢）
//   esp/room1/relay    → "ON" / "OFF"
// 设备状态通知（QoS 1 + 保留消息）
//   esp/room1/status   → "online" / "offline"
// 遗嘱消息（QoS 1，保留）
//   主题: esp/room1/status，内容: "offline"

// 连接时设置遗嘱
client.connect("ESP8266_Room1", NULL, NULL, 
               "esp/room1/status", 1, true, "offline");

// 上电发布在线状态（保留）
client.publish("esp/room1/status", "online", 1, true);

// 定时上报温度（QoS 0）
client.publish("esp/room1/temp", String(temp).c_str(), 0);

// 处理继电器控制指令（QoS 2订阅）
client.subscribe("esp/room1/relay", 2);

常见误区复盘：

误区1：所有消息都用QoS 2。实际上高频传感器数据用QoS 0即可，QoS 2会显著增加网络流量和延迟。
误区2：忘记设置遗嘱消息。设备异常离线时，其他节点无法感知，导致“幽灵设备”问题。
误区3：保留消息不更新。设备状态变化后必须重新发布保留消息，否则新订阅者会收到过期状态。
误区4：主题层级过浅或过深。过浅（如temp）容易冲突，过深（如home/floor1/room/esp8266/sensor/temp）增加匹配开销。
误区5：在回调函数中执行耗时操作（如延时、串口打印大量数据），会阻塞MQTT消息接收，导致掉线。

掌握MQTT的这五大核心机制，是构建可靠物联网应用的基础。在实际项目中，建议先在本地用Mosquitto Broker + MQTT.fx工具验证消息流程，再移植到ESP8266上，能大幅减少调试时间。