📚 课程目录第4章 QoS机制原理

QoS机制原理：消息确认机制、重传策略、去重与顺序保证、会话状态与持久会话

MQTT 的 QoS（Quality of Service）并非简单的“发送后不管”或“尽力送达”，而是一套由消息确认机制、重传策略、去重与顺序保证以及会话状态管理共同构成的可靠传输协议。理解这四者如何协同工作，是掌握 QoS 优化、诊断消息丢失或重复问题的前提。本章将拆解 QoS 0/1/2 的底层运作逻辑，并重点剖析持久会话（Persistent Session）在其中的关键作用。

4.1 消息确认机制：QoS 等级的分水岭

MQTT 协议中，消息的“确认”并非由应用层业务代码完成，而是由协议层的控制报文（Control Packet）承担。不同 QoS 等级对应不同的确认报文组合，这也是 QoS 0 与 QoS 1/2 的本质区别。

QoS 0（至多一次）：发送方发出 PUBLISH 报文后，不等待任何确认，也不存储消息。适用于传感器高频上报等允许丢失的场景。
QoS 1（至少一次）：发送方发出 PUBLISH 后，必须等待接收方返回 PUBACK 报文。若超时未收到，发送方将重发该消息。接收方可能收到重复消息，需由应用层或会话层去重。
QoS 2（恰好一次）：采用两阶段握手。发送方发出 PUBLISH 后，接收方返回 PUBREC（收到记录）；发送方收到后必须回复 PUBREL（释放）；接收方收到 PUBREL 后才返回 PUBCOMP（完成）。整个流程确保消息不重不漏。

下表对比了三种 QoS 的报文交互与可靠性特征：

QoS 等级	确认报文	重传行为	消息重复风险	适用场景
QoS 0	无	不重传	可能丢失	环境温度、GPS 坐标
QoS 1	PUBACK	超时重发	可能重复	设备状态上报、日志
QoS 2	PUBREC / PUBREL / PUBCOMP	四步握手，严格去重	不重不漏	支付指令、OTA 固件下发

关键认知：QoS 1 的“至少一次”意味着接收方可能收到重复消息，但发送方不会丢失消息。QoS 2 的“恰好一次”通过两阶段握手在协议层完成了去重，但代价是额外的报文往返，延迟更高。

4.2 重传策略：超时与 DUP 标志

重传是 QoS 1/2 保证可靠性的核心手段。发送方在发出 PUBLISH（QoS 1）或 PUBREL（QoS 2）后，会启动一个重传定时器。若在 retryInterval（通常由客户端或 Broker 配置，默认 60 秒）内未收到对应的确认报文，则重新发送该报文，并将报文的 DUP（Duplicate）标志位置为 1。

重传策略的关键细节如下：

报文标识符（Packet ID）：每个 QoS > 0 的消息在发送时都会分配一个 16 位的 Packet ID。重传时使用相同的 Packet ID，接收方据此识别是否为重复消息。
DUP 标志：仅表示“这是否是重发的报文”，并不代表消息内容重复。接收方不能仅凭 DUP 标志决定是否丢弃消息，而应结合 Packet ID 和会话状态判断。
重传次数：MQTT 协议本身未规定最大重传次数，但实际实现中通常有上限（如 3~5 次）。超过上限后，发送方应放弃并通知上层应用。

// 伪代码：QoS 1 发送方重传逻辑
send(PUBLISH, packetId, qos=1);
startTimer(retryInterval);

onTimeout():
    if (retryCount < MAX_RETRY) {
        send(PUBLISH, packetId, qos=1, dup=true);
        retryCount++;
        startTimer(retryInterval);
    } else {
        notifyFailure("消息发送失败，超过最大重传次数");
    }

onReceive(PUBACK, packetId):
    cancelTimer();
    markAsCompleted(packetId);

常见误区：不要将 DUP 标志当作去重依据。DUP=1 只表示“这是重传”，但接收方可能第一次收到该消息（例如前一次传输在网络中丢失）。正确的去重必须依赖 Packet ID 与接收方的会话记录。

4.3 去重与顺序保证：接收方的状态机

接收方（Broker 或客户端）需要维护一个已接收消息的 Packet ID 集合，用于去重。对于 QoS 2，接收方在收到 PUBLISH 后，会先检查该 Packet ID 是否已存在于“待释放”列表中：

若不存在，则保存消息内容，返回 PUBREC，并将该 Packet ID 标记为“待释放”。
若已存在，说明是重复的 PUBLISH，直接返回 PUBREC（不重复保存消息）。
收到 PUBREL 后，将消息投递给订阅者，并返回 PUBCOMP，同时从“待释放”列表中移除该 Packet ID。

顺序保证方面，MQTT 协议规定：在同一个连接（Connection）内，发送方必须按顺序发送消息，且接收方必须按顺序处理相同 QoS 的消息。但需要注意，QoS 0 消息不受此约束，且不同 QoS 等级之间的顺序也可能因重传而被打乱。例如，发送方先发 QoS 1 消息 A，再发 QoS 0 消息 B，若 A 重传，B 可能先被处理。

上图展示了 QoS 2 的完整交互流程。接收方通过维护 Packet ID 状态，确保即使收到重复的 PUBLISH，也不会重复投递消息给订阅者。这种状态机机制是 QoS 2 能够实现“恰好一次”的根本原因。

4.4 会话状态与持久会话

MQTT 的会话（Session）是客户端与 Broker 之间的逻辑连接状态。会话状态包括：

已订阅的 Topic 列表及其 QoS 等级。
所有 QoS 1/2 消息的 Packet ID 状态（待确认、待释放）。
Broker 尚未发送给客户端的 QoS 1/2 消息队列。
客户端尚未确认的 QoS 1/2 消息队列。

持久会话（Persistent Session）通过 CONNECT 报文中的 Clean Session 标志位控制。当 Clean Session = 0 时，Broker 会持久化上述会话状态；当客户端断开后重新连接，Broker 会恢复会话，并继续发送未完成的消息。若 Clean Session = 1，则每次连接都是全新会话，断开即清除所有状态。

持久会话的典型应用场景：

设备（如智能门锁）在弱网环境下频繁断线重连。若使用持久会话，设备离线期间 Broker 会暂存发给它的 QoS 1 消息（如远程开锁指令），待设备重新上线后立即补发，确保指令不丢失。反之，若使用 Clean Session = 1，离线期间的消息将被 Broker 丢弃，设备重连后无法收到离线指令。

持久会话的代价是 Broker 需要为每个持久会话维护内存和磁盘状态。当大量设备长期离线且消息积压时，可能耗尽 Broker 资源。因此，持久会话并非“永久会话”——Broker 通常会设置会话过期时间（Session Expiry Interval，MQTT 5.0 特性），超过期限后自动清理。

4.5 案例复盘：QoS 1 消息重复投递的排查

场景：某工厂使用 MQTT 采集 PLC 数据，QoS 1 上报。运维人员发现数据库中出现重复记录，且重复间隔约 60 秒（与 Broker 重传间隔一致）。

排查过程：

抓包分析发现，客户端发送 PUBLISH 后，Broker 已返回 PUBACK，但客户端因网络抖动未及时收到。
客户端在 60 秒后重发该消息（DUP=1），Broker 此时已处理完第一条消息，但未保存 Packet ID 历史记录（因为 QoS 1 不要求 Broker 去重）。
Broker 将重复消息再次转发给订阅者（数据库写入服务），导致重复记录。

解决方案：

在数据库写入端增加业务幂等性：以 PLC 时间戳 + 数据点 ID 作为唯一键，重复写入时忽略。
或将 QoS 提升至 2，由 Broker 在协议层完成去重，但需评估额外延迟是否可接受。
调整客户端重传间隔，使其小于 Broker 的会话过期时间，减少重传窗口。

核心复盘结论：QoS 1 只保证“至少一次”，不保证“不重复”。任何依赖 QoS 1 的业务系统，都必须在应用层实现幂等处理。不要试图通过修改 Broker 配置来让 QoS 1 变成“恰好一次”——这是协议设计使然，而非配置缺陷。

理解 QoS 的确认、重传、去重与会话机制，是优化消息可靠性的基础。在实际项目中，应根据业务对丢失与重复的容忍度，合理选择 QoS 等级，并配合持久会话与业务幂等设计，构建真正可靠的物联网消息链路。