控制报文与会话

MQTT 在已建立的网络连接上交换 Control Packet
第一个包必须是 CONNECT；会话与 Keep Alive 决定“断线后还记不记得你”

依据：OASIS MQTT 5.0 / 3.1.1 控制报文章节。

**官方字节级格式（Fixed Header / CONNECT / PUBLISH / SUBSCRIBE…）**见：
10-MQTT控制报文格式总览.md 起整组文档（对齐 OASIS §2 / §3）。

---

1. 控制报文一览

报文	方向	作用
CONNECT	C→S	连接请求（协议级登录）
CONNACK	S→C	连接确认
PUBLISH	双向	发布消息
PUBACK	双向	QoS1 确认
PUBREC / PUBREL / PUBCOMP	双向	QoS2 握手
SUBSCRIBE	C→S	订阅
SUBACK	S→C	订阅确认
UNSUBSCRIBE	C→S	取消订阅
UNSUBACK	S→C	取消确认
PINGREQ / PINGRESP	C↔S	Keep Alive 心跳
DISCONNECT	双向（5.0 更完整）	断开
AUTH	双向（仅 5.0）	增强认证交换

固定头很小：报文类型 + flags + Remaining Length。

---

2. CONNECT 关键字段（概念）

字段	含义
Protocol Name / Level	MQTT / 版本（3.1.1 或 5.0）
Client Identifier	客户端 ID（会话主键之一）
Clean Session / Clean Start	是否清理旧会话
Keep Alive	秒；最大空闲间隔相关
Username / Password	可选认证
Will*	遗嘱相关标志与载荷
Properties（5.0）	Session Expiry、Receive Maximum 等

规范要求：网络连接建立后，客户端发送的第一包必须是 CONNECT。

---

3. 会话（Session）

会话状态可能包括：

• 订阅集合
• 未完成的 QoS1/2 报文流
• （实现相关）排队消息

3.1 Clean Session（3.1.1） vs Clean Start + Session Expiry（5.0）

版本	控制方式
3.1.1	Clean Session=1 不保留；=0 尽量恢复
5.0	Clean Start + Session Expiry Interval 更精细

断线重连时：

• 若会话仍在：可恢复订阅与未完成流（少丢、少重订）
• 若已清理：需重新 SUBSCRIBE

---

4. Keep Alive

Client 声明 Keep Alive（秒）。若在约 1.5 × Keep Alive 内无控制报文往来，Broker 可断开连接，并可能触发 Will。

Client 侧用 PINGREQ 保活；Server 回 PINGRESP。

经验：

• 移动网络：不要设过短导致假掉线，也不要过长导致故障发现慢
• 常见起点：30～60s，按现场调

---

5. 订阅流

Client: SUBSCRIBE (Packet ID, Topic Filter, Requested QoS, ...)
Broker: SUBACK   (Packet ID, Reason Codes / Granted QoS)

Broker 可降级 QoS（Granted ≤ Requested）。
应用必须看 SUBACK，不要假设一定按请求 QoS 成交。

---

6. 发布流（按 QoS）

详见 03-QoS与消息投递.md。概要：

• QoS0：PUBLISH 即止
• QoS1：PUBLISH → PUBACK
• QoS2：PUBLISH → PUBREC → PUBREL → PUBCOMP

---

7. 正常断开 vs 异常断开

情况	典型行为
发 DISCONNECT 后关连接	正常下线；通常不触发 Will
TCP 重置 / 超时 / Keep Alive 失败	异常；可能触发 Will、会话按策略保留或过期

MQTT 5 的 DISCONNECT 可带 Reason Code，便于诊断“为什么踢人”。

---

8. 多连接与 Client ID

• 同一 Client ID 重复连接：Broker 通常踢掉旧连接（行为以实现/设置为准）
• 千万不要多设备共用一个 Client ID（会互相踢）
• 动态设备可用随机 ID + Clean Start，或稳定 ID + 会话恢复策略

下一篇：03-QoS与消息投递.md