2、MQTT协议基础回顾：发布/订阅模型、主题(Topic)与通配符、服务质量(QoS)等级、保留消息与遗嘱消息
聊MQTT安全之前，咱们得先把地基夯实。MQTT这协议，说白了就是物联网设备间的“传话筒”。我最早接触它是在一个工厂数据采集项目里，当时被它的轻量级惊到了——一个数据包才几个字节，比HTTP那种动不动就几百个头的协议清爽太多。
但轻量不代表简单。MQTT的几个核心机制，你要是理解不透，后面做安全策略就容易踩坑。咱们一个一个过。
2.1 发布/订阅模型：解耦的核心
MQTT用的是发布/订阅模型，不是传统的客户端/服务器请求响应。什么意思呢？
- 发布者（Publisher）：只管发消息，不关心谁收。
- 订阅者（Subscriber）：只管收消息，不关心谁发。
- 代理（Broker）：中间人，负责消息的路由和分发。
这三者完全解耦。发布者和订阅者不需要知道对方的存在，甚至不需要同时在线。我在一个智慧楼宇项目里就遇到过这种情况：传感器半夜上报数据，但后台系统凌晨才启动分析任务。没关系，Broker把消息存着，订阅者上线就能拿到。
核心优势：空间解耦（不知道对方IP）、时间解耦（不需要同时在线）、同步解耦（发布后不用等响应）。
你想想看，如果每个设备都要直接跟其他设备建立连接，那网络拓扑得多复杂？MQTT这种模型，天然适合设备多、网络不稳定的IoT场景。
2.2 主题（Topic）与通配符：消息的“地址”
消息怎么路由？靠主题。主题是一个UTF-8字符串，用“/”分层。比如：
factory/floor1/temperature
factory/floor1/humidity
factory/floor2/temperature这就像文件系统的路径。发布者发消息到某个主题，订阅者订阅感兴趣的主题，Broker负责匹配。
但问题来了——如果我要订阅所有楼层的温度数据，难道要一条一条写？不用。MQTT提供了通配符：
| 通配符 | 名称 | 匹配规则 | 示例 |
|---|---|---|---|
+ |
单层通配符 | 匹配一个层级 | factory/+/temperature 匹配 floor1、floor2 |
# |
多层通配符 | 匹配剩余所有层级 | factory/# 匹配 factory 下所有主题 |
注意：# 只能放在主题末尾，+ 可以放在任意层级。我曾经见过有人把 # 放中间，结果Broker直接报错——这是协议规定的硬限制。
通配符很强大，但也是安全风险点。你想想，如果有人订阅了 #，那整个系统的消息都暴露了。后面讲安全策略时，我会专门讲怎么限制通配符的使用。
2.3 服务质量（QoS）等级：消息可靠性的三档选择
MQTT定义了三个QoS等级，控制消息的投递可靠性。我习惯把它们理解为快递服务：
| 等级 | 名称 | 投递保证 | 开销 | 适用场景 |
|---|---|---|---|---|
| QoS 0 | 至多一次 | 不保证送达，不重试 | 最低 | 传感器高频数据，丢一帧无所谓 |
| QoS 1 | 至少一次 | 保证送达，可能重复 | 中等 | 控制指令，允许去重 |
| QoS 2 | 恰好一次 | 保证送达且不重复 | 最高 | 计费、报警等关键数据 |
QoS 0最简单——发出去就不管了，适合温度、湿度这种连续上报的数据。QoS 1会重试直到收到确认，但可能重复。QoS 2用了四次握手，确保不重复，但延迟和带宽开销都大。
我的建议：别一上来就用QoS 2。我在一个车联网项目里，所有消息都设成QoS 2，结果Broker负载飙升，消息堆积严重。后来改成：控制指令用QoS 1，状态上报用QoS 0，只有OTA升级指令用QoS 2。系统立马稳了。
2.4 保留消息：新订阅者的“见面礼”
假设一个温度传感器每隔5秒上报一次数据。新设备上线后订阅了温度主题，但它要等最多5秒才能收到第一条消息。如果它需要立即知道当前温度呢？
保留消息就是干这个的。发布者可以设置消息的 Retain 标志为 true，Broker会存下这条消息。当有新订阅者上线时，Broker立即把这条保留消息推过去。
// 发布保留消息（伪代码）
client.publish("factory/floor1/temperature", "25.3", 1, true); // 最后一个参数是 retain避坑指南：我曾经在一个项目中，所有传感器都发了保留消息，但没人清理过期的保留消息。结果Broker内存里堆了几万条陈旧的保留消息，新设备上线时收到一堆过时数据，差点触发误报警。记住：保留消息需要定期清理，或者用空消息覆盖。
清理方式很简单：向同一个主题发布一条空消息，retain设为true，内容为空。Broker就会删除该主题的保留消息。
2.5 遗嘱消息：设备“临终”的最后一声
设备突然掉线了，怎么通知其他系统？MQTT的遗嘱消息（Will Message）就是干这个的。
设备在连接Broker时，可以设置一个遗嘱主题和遗嘱消息。如果设备非正常断开（比如网络中断、断电），Broker会替它发布这条遗嘱消息。
// 连接时设置遗嘱（伪代码）
MqttConnectOptions options = new MqttConnectOptions();
options.setWill("device/status", "offline".getBytes(), 1, false);正常断开时，Broker不会发遗嘱消息。只有Broker检测到连接超时或网络异常时才会触发。
实际用途：我在一个工厂项目中，用遗嘱消息做设备心跳检测。每个设备每30秒发一次心跳，如果Broker超过60秒没收到心跳，就判定设备离线，自动发布遗嘱消息到告警系统。比传统的轮询方案省带宽多了。
但要注意：遗嘱消息的QoS等级和保留标志也要设置合理。如果遗嘱消息设成QoS 0，可能丢失；如果设了保留，那新订阅者上线时还会收到这条“离线”消息，可能造成误判。
2.6 本章知识体系总览
下面这张图把MQTT的核心机制串起来了。你可以看到发布者、订阅者、Broker三者如何通过主题、QoS、保留消息和遗嘱消息协同工作。
这张图把MQTT的核心要素都串起来了。发布者只管往主题上扔消息，Broker根据主题匹配和QoS等级做路由，订阅者被动接收。保留消息和遗嘱消息则是在特殊场景下的补充机制。