📚 课程目录第4章 MQTT控制报文详解

MQTT控制报文详解：CONNECT、CONNACK、PUBLISH、PUBACK、SUBSCRIBE、SUBACK等报文的用途与格式

核心原理：MQTT报文的分层结构与固定头

MQTT协议的所有交互行为都建立在14种控制报文之上。每种报文都遵循统一的三段式结构：固定头（Fixed Header）、可变头（Variable Header）和有效载荷（Payload）。固定头是所有报文共有的基础，其第一个字节由报文类型（4位）、DUP标志（1位）、QoS等级（2位）和RETAIN标志（1位）组成。第二个字节是剩余长度（Remaining Length），表示可变头与有效载荷的总字节数，采用变长编码方式，最多可表示256MB的数据包。

理解固定头是解析一切MQTT流量的起点。例如，当抓包看到第一个字节为0x10时，高4位0001表示这是CONNECT报文，低4位0000表示QoS为0且无重发标志。而0x30则代表PUBLISH报文（QoS 0），0x32代表QoS 1的PUBLISH，0x34代表QoS 2的PUBLISH。这种紧凑的位级设计使得MQTT非常适合低带宽、高延迟的物联网场景。

方法流程：连接建立与消息确认的报文交互

MQTT会话的建立始于客户端发送CONNECT报文。该报文的可变头必须包含协议名"MQTT"（或"MQIsdp"用于3.1版本）、协议级别（4表示3.1.1版本，5表示5.0版本）、连接标志（用于指定清洁会话、遗嘱标志、用户名/密码标志等）以及保活周期（单位秒）。有效载荷中则携带客户端标识符（Client ID），这是每个客户端唯一的身份标识。若连接标志中启用了遗嘱功能，还需附加遗嘱主题和遗嘱消息。

服务端收到CONNECT后，会返回CONNACK报文作为响应。CONNACK的可变头包含两个字节：连接确认标志（第1字节，目前仅使用bit 0表示会话已存在）和返回码（第2字节）。返回码0x00表示连接已被接受，0x01表示不支持的协议版本，0x02表示客户端标识符被拒绝，0x03表示服务端不可用，0x04表示用户名或密码错误，0x05表示未授权。客户端必须等待CONNACK后才能发送其他报文。

连接建立后，客户端通过PUBLISH报文发布消息。PUBLISH的可变头包含主题名（UTF-8编码字符串）和可选的报文标识符（仅当QoS大于0时存在）。有效载荷即消息内容。当QoS为1时，接收方需回复PUBACK报文确认收到；当QoS为2时，则涉及PUBREC、PUBREL、PUBCOMP四步握手。订阅操作使用SUBSCRIBE报文，其有效载荷包含一个或多个主题过滤器及对应的最大QoS等级，服务端以SUBACK报文逐一返回授予的QoS等级（0x00、0x01、0x02或0x80表示失败）。

典型连接与订阅流程示例

客户端 → 服务端：CONNECT
  固定头: 0x10 0x0E
  可变头: 协议名"MQTT"(0x00 0x04 0x4D 0x51 0x54 0x54)
          协议级别 0x04
          连接标志 0x02 (清洁会话=1)
          保活周期 0x00 0x3C (60秒)
  有效载荷: 客户端ID "sensor-01"

服务端 → 客户端：CONNACK
  固定头: 0x20 0x02
  可变头: 0x00 0x00 (会话不存在，连接成功)

客户端 → 服务端：SUBSCRIBE
  固定头: 0x82 0x0A (QoS=1)
  可变头: 报文标识符 0x00 0x01
  有效载荷: 主题过滤器 "home/+/temp" + 请求QoS 0x01

服务端 → 客户端：SUBACK
  固定头: 0x90 0x03
  可变头: 报文标识符 0x00 0x01
  有效载荷: 返回码 0x01 (授予QoS 1)

客户端 → 服务端：PUBLISH (QoS=1)
  固定头: 0x32 0x0F
  可变头: 主题 "home/room1/temp" + 报文标识符 0x00 0x02
  有效载荷: "23.5"

服务端 → 客户端：PUBACK
  固定头: 0x40 0x02
  可变头: 报文标识符 0x00 0x02

案例场景：智能家居温度上报与远程控制

以智能家居系统为例，温度传感器作为MQTT客户端，通过以下报文序列与部署在云端的Broker通信：

传感器上电后，发送CONNECT报文，携带客户端标识符temp-sensor-客厅，设置清洁会话标志为1，保活周期为30秒。
Broker回复CONNACK，返回码0x00，连接建立成功。
传感器每10秒发送一次PUBLISH报文，主题为home/livingroom/temperature，QoS设为1，确保数据不丢失。Broker收到后回复PUBACK。
用户手机App发送SUBSCRIBE报文，订阅主题home/+/temperature，请求QoS为1。Broker返回SUBACK，授予QoS 1。
当温度超过28℃时，传感器发布一条QoS 1的告警消息到home/livingroom/alarm，App通过已建立的订阅实时收到该消息并推送通知。

该场景中，QoS 1的PUBLISH/PUBACK机制保证了温度数据在Wi-Fi波动时不会丢失，而SUBSCRIBE的主题过滤器home/+/temperature则让App无需关心具体房间号即可订阅所有温度数据。

误区与复盘：报文使用中的常见错误

误区	错误表现	正确做法
CONNECT报文缺少协议名	Broker返回返回码`0x01`（协议版本不支持）	确保可变头前两个字节为`0x00 0x04`，后跟ASCII码"MQTT"
QoS 1的PUBLISH未携带报文标识符	Broker直接断开连接	QoS>0时必须在可变头中包含非零的报文标识符
SUBSCRIBE报文固定头QoS位设置错误	报文被Broker视为非法	SUBSCRIBE固定头第1字节应为`0x82`（QoS至少为1）
收到PUBACK后仍重发相同报文标识符的PUBLISH	造成消息重复	PUBACK确认后，该报文标识符即可复用，但需等待确认后再发送新消息
CONNACK返回码`0x04`时未检查用户名密码标志	反复连接失败	检查CONNECT连接标志中用户名/密码位是否与Broker配置一致

复盘实际项目中的排障经验：当客户端连接被Broker拒绝且返回码为0x05（未授权）时，多数原因是CONNECT报文有效载荷中用户名或密码的编码方式错误——MQTT要求用户名和密码均为UTF-8编码的二进制数据，且长度前缀为两字节。此外，保活周期设置过短（如小于5秒）会导致客户端频繁发送PINGREQ，浪费带宽；设置过长则可能使NAT网关超时断开连接。建议根据网络环境在30~120秒之间调整。

另一个常见误区是混淆SUBACK返回码与QoS等级。SUBACK有效载荷中的每个字节对应SUBSCRIBE中一个主题过滤器的授予结果，0x80表示该订阅被拒绝，而非QoS 0。若客户端请求QoS 2但Broker只支持QoS 1，SUBACK会返回0x01，客户端后续发布消息时需按授予的QoS等级发送，否则可能触发协议违规。