MQTT 3.1 与 3.1.1 核心差异：协议规范变化、连接报文、遗嘱消息等关键区别
MQTT 3.1.1（OASIS 标准）与 3.1（IBM 草案）之间并非颠覆性重写，而是针对互操作性、歧义消除和错误码语义的精准修订。理解这些差异，对设备固件选型、Broker 兼容性测试以及排查“连接被拒”类问题至关重要。本节聚焦三个最易引发线上故障的差异面：协议规范层面的命名与行为约束、CONNECT/CONNACK 报文的字段级变化，以及遗嘱消息（Will Message）的发布时机与标志位规则。
一、核心原理：从“草案”到“标准”的语义收紧
3.1.1 的修订哲学是“消除一切可被不同实现解读出不同行为的表述”。最直观的变化是协议名称与版本号字段：3.1 时代协议名称为 MQIsdp，版本号固定为 0x03；而 3.1.1 将协议名称改为 MQTT，版本号固定为 0x04。这一改动直接导致旧版 Broker 无法识别新版客户端的 CONNECT 报文——如果 Broker 只支持 3.1，收到协议名 MQTT 时会直接断开连接。
规范层面三大关键收紧：
- 保留标志位（RETAIN）与 QoS 的合法性校验：3.1.1 明确规定 PUBLISH 报文中 QoS=3 为非法值，且 QoS=0 时 DUP 标志必须为 0。3.1 对此未做强制约束，导致部分实现发送了 QoS=3 的报文后，Broker 行为不可预期。
- 会话状态清理规则：3.1.1 明确 Clean Session=0 时，Broker 必须存储会话状态直至会话过期；3.1 中“持久会话”的持续时间未明确定义，部分 Broker 在重启后即清空会话。
- 遗嘱消息的“延迟发布”语义：3.1.1 规定遗嘱消息仅在网络连接异常关闭（如 I/O 错误、心跳超时）或 Broker 检测到协议违规时发布，而客户端主动发送 DISCONNECT 报文则不得触发遗嘱发布。3.1 对此场景描述模糊，导致部分客户端在正常断开时误触发遗嘱。
二、方法流程：CONNECT/CONNACK 报文逐字节对比
连接报文是版本差异最集中的区域。下表列出 3.1 与 3.1.1 在可变头部与标志位上的具体差异，这些字段直接决定 Broker 是否接受连接以及返回何种错误码。
| 字段/行为 | MQTT 3.1 | MQTT 3.1.1 |
|---|---|---|
| 协议名称 | MQIsdp（6 字节） |
MQTT（4 字节） |
| 协议级别 | 0x03 |
0x04 |
| Clean Session 标志 | 位置相同，但语义未强制 | 明确为 0/1 二值，且与持久会话绑定 |
| 遗嘱 QoS 字段 | 允许 QoS=3（非法） | 仅允许 0/1/2，否则 CONNACK 返回 0x01 |
| 遗嘱保留标志 | 未定义行为 | 若遗嘱保留=1，遗嘱消息作为保留消息发布 |
| 用户名/密码标志 | 若密码标志=1 但用户名为空，部分 Broker 接受 | 若密码标志=1 但用户名为空，必须返回 0x04（拒绝） |
| CONNACK 返回码 | 0x00-0x05（含“不允许连接”） | 0x00-0x05，但 0x03（服务器不可用）语义更严格 |
一个典型的 3.1.1 CONNECT 报文（不含 Payload）十六进制如下：
10 12 00 04 4D 51 54 54 04 02 00 3C 00 00
│ │ │ │ └─ 协议级别=0x04
│ │ │ └──── 协议名 "MQTT"
│ │ └─────── 剩余长度=18
│ └────────── 报文类型=CONNECT(1)
└───────────── 固定头起始其中第 10 字节 0x02 表示 Clean Session=1、遗嘱标志=0；若改为 0x06（二进制 0000 0110），则遗嘱 QoS=1 且遗嘱标志=1。3.1.1 要求 Broker 必须校验该字节中保留位（bit0）为 0，否则断开连接。
三、案例/场景：遗嘱消息误触发的真实故障
某智能门锁项目使用 MQTT 3.1 协议，设备端在正常休眠前主动发送 DISCONNECT 报文。但 Broker 日志显示，每次设备休眠后，云端都会收到遗嘱消息“设备离线”，导致 App 误报。排查后发现：设备固件基于 3.1 草案实现，其 MQTT 库在发送 DISCONNECT 后未正确清除遗嘱标志，且 Broker 对 3.1 的“正常断开是否触发遗嘱”未做严格区分。
升级到 3.1.1 后，协议规范明确：
- 客户端发送 DISCONNECT 后，Broker 必须丢弃该会话关联的遗嘱消息；
- 只有连接异常中断（如 TCP 超时、心跳丢失）才发布遗嘱；
- 遗嘱消息的 Topic 和 Payload 在 CONNECT 时固定，后续不可修改。
修复方案：将设备端协议栈升级至 3.1.1，并在 CONNECT 报文中将遗嘱标志位正确置 0（若无需遗嘱）。同时，在 Broker 端开启“严格协议校验”模式，拒绝任何版本号非 0x04 的连接。升级后，设备休眠不再触发遗嘱，误报率降为 0。
实操建议：若需同时兼容 3.1 与 3.1.1 设备，Broker 应通过 CONNECT 报文中的协议级别字段（0x03 或 0x04）动态选择解析规则。切勿假设所有设备都支持 3.1.1——部分老式传感器模块仅实现 3.1，且无法远程升级。
四、误区/复盘：版本差异引发的典型认知偏差
误区 1：认为 3.1.1 只是“改名”，不影响报文交互。实际上，协议名称从 MQIsdp 改为 MQTT 后，任何硬编码了旧协议名的 Broker 或防火墙规则都会拒绝新客户端。某智慧园区项目曾因安全网关只允许 MQIsdp 前缀的报文通过，导致所有 3.1.1 设备无法连接。
误区 2：混淆遗嘱消息与 Last Will 的“保留”属性。3.1.1 中，遗嘱消息可以设置保留标志（Will Retain），但该标志与 PUBLISH 报文的 RETAIN 标志独立。若遗嘱保留=1，遗嘱消息会作为保留消息存储在 Broker 上，后续订阅者立即收到；若遗嘱保留=0，则仅对当前在线订阅者发布。3.1 未明确此行为，导致部分实现将遗嘱消息一律视为非保留。
误区 3：忽略 CONNACK 返回码 0x03 的语义变化。3.1 中 0x03 表示“服务器不可用”，但未说明客户端应如何处理；3.1.1 明确要求客户端收到 0x03 后应等待一段时间再重试，且不得立即重连。某车联网项目因客户端收到 0x03 后立即重连，导致 Broker 过载雪崩。
复盘要点：在协议迁移测试中，务必使用协议分析器（如 Wireshark 的 MQTT 解析器）逐字节比对 CONNECT 报文。重点检查：协议名长度字段（3.1 为 6，3.1.1 为 4）、协议级别值、遗嘱标志位组合（bit2-bit4）是否合法。任何一位错误都会导致 Broker 静默断开或返回 0x01（不接受的协议版本）。
下表总结了版本迁移时最需关注的 5 个检查点，可作为固件升级前的自检清单：
- CONNECT 可变头部中协议名是否为
MQTT且长度字段为 4； - 协议级别字段是否为
0x04； - 遗嘱标志位为 1 时，遗嘱 QoS 是否在 0~2 范围内；
- Clean Session=0 时，是否在会话中正确存储订阅与未确认消息；
- 客户端主动 DISCONNECT 后，Broker 是否不再发布遗嘱消息。
从上述对比可见，3.1.1 并非新增功能，而是将 3.1 中“可做可不做”的灰色地带全部转为强制性要求。对于正在维护多版本设备接入的物联网平台，建议在 Broker 前置网关处增加协议版本解析层，将 CONNECT 报文中的协议级别字段映射为内部路由标识，从而对不同版本的设备实施差异化的会话管理和遗嘱策略。这不仅能避免升级过程中的兼容性阵痛，也能为后续协议版本演进（如 MQTT 5.0）预留清晰的扩展路径。