3. MQTT 会话状态详解：Clean Session、过期时间与持久/临时会话

聊到会话隔离，咱们得先搞清楚 MQTT 会话到底是个什么东西。说白了，它就是 Broker 和客户端之间维持的一个“状态契约”。我见过不少团队，安全策略做得挺严，结果在会话配置上翻了车——攻击者利用一个残留的旧会话，直接绕过了认证。嗯，这节咱们就把会话的底裤扒干净。

3.1 Clean Session 标志位：会话的“开关”

Clean Session 是 CONNECT 报文里的一个标志位，它决定了 Broker 要不要为这个客户端保留状态。我个人习惯把它理解成“是否要失忆”。

• Clean Session = 1（临时会话）：Broker 不保留任何状态。连接断开后，会话、未投递的消息、订阅关系全部删除。每次重连都是全新的开始。
• Clean Session = 0（持久会话）：Broker 保留会话状态。断开后，Broker 会缓存离线消息和订阅信息，等客户端下次用相同的 Client ID 重连时恢复。

我在项目中遇到过一个问题：某设备用固定 Client ID 连接，Clean Session = 0。设备断网后，Broker 一直保留着它的会话。后来设备被攻击者仿冒，用同样的 Client ID 连上来，直接继承了原来的订阅和权限——这就是典型的会话劫持。你想想看，这多危险。

3.2 会话过期时间：给状态加个“定时炸弹”

MQTT 5.0 引入了 Session Expiry Interval，它解决了旧版本里持久会话“永远不过期”的痛点。你可以给会话设置一个存活时间，超时后 Broker 自动清理。

取值	行为	典型场景
0	连接断开后立即过期，等同于 Clean Session = 1	传感器上报，无需离线消息
0xFFFFFFFF	永不过期，等同于 Clean Session = 0	关键控制设备，必须保证离线消息不丢
自定义值（秒）	到期后 Broker 清理会话和所有相关状态	移动设备，断连后保留一段时间，超时自动清理

3.3 持久会话 vs 临时会话：怎么选？

这两种会话模式，说白了就是“要可靠性”还是“要资源效率”的权衡。我建议你根据设备角色来定。

• 持久会话（Clean Session = 0 / Session Expiry Interval > 0）：
  • 适合：控制指令下发、状态同步、需要离线消息的设备。
  • 风险：会话残留时间长，容易被横向攻击利用。
• 临时会话（Clean Session = 1 / Session Expiry Interval = 0）：
  • 适合：纯上报数据、不关心离线消息、连接频繁的设备。
  • 优势：无状态残留，攻击面小。

3.4 会话状态的核心组成

Broker 到底在会话里存了啥？我列个清单给你看：

1. 订阅信息：客户端订阅了哪些 Topic 和 QoS 等级。
2. 未确认的 QoS 1/2 消息：已发送但未收到确认的消息。
3. 离线消息：客户端离线期间，Broker 暂存的消息。
4. Client ID：会话的唯一标识。
5. Will Message（遗嘱消息）：客户端异常断开时，Broker 代发的消息。

这些状态，就是攻击者眼中的“香饽饽”。如果能劫持一个持久会话，攻击者就能直接拿到订阅关系，甚至伪造遗嘱消息。嗯，这就是为什么会话隔离策略里，第一道防线就是管好会话生命周期。

3.5 会话状态流转图

下面这张图，帮你理清会话从创建到销毁的完整路径：

3.6 会话隔离的切入点

理解了会话状态，咱们就能找到隔离的发力点。我个人总结了三道防线：

• 第一道：限制会话生命周期——给每个会话设合理的过期时间，别让它“长生不老”。
• 第二道：绑定 Client ID 与设备身份——确保会话只能被合法的设备恢复，防止仿冒。
• 第三道：最小化会话状态——只存必要信息，减少攻击者可利用的数据。