第1章 MQTT协议基础回顾

1. MQTT协议基础回顾

各位同学好，我是你们的老朋友。今天咱们正式开始聊MQTT安全这个话题。不过在深入TLS加密之前，我觉得有必要先把MQTT协议的基础再过一遍。你可能会说：「这些我都懂啊！」——别急，我当年也这么想，结果在项目里栽过跟头。所以咱们还是踏踏实实把地基打牢。

MQTT最核心的思想，就是发布/订阅模型。说白了，它跟传统的客户端-服务器模式不太一样。传统模式里，客户端直接跟服务器对话，就像你打电话给客服——一对一。但MQTT不一样，它引入了一个「中间人」，我们叫它Broker（代理服务器）。

举个例子。我在做智能家居项目时，有个温度传感器需要把数据传给手机App。如果用传统HTTP，传感器得知道手机App的IP地址，手机也得知道传感器的地址——这在实际场景里根本行不通。MQTT怎么解决的呢？

这样一来，发布者和订阅者完全解耦。它们不需要知道对方的存在，甚至不需要同时在线。我个人觉得，这是MQTT最优雅的地方。

关键点：MQTT的发布/订阅模型实现了空间解耦、时间解耦和同步解耦。发布者不用等订阅者确认，订阅者也不用一直在线等着收消息。

聊完模型，咱们看看MQTT的报文长什么样。MQTT的报文非常精简，这也是它适合物联网设备的原因——带宽小、内存小、CPU弱，都能跑。

一个MQTT报文由三部分组成：

嗯，这里要注意。固定头部里的「剩余长度」字段，用的是变长编码。什么意思呢？就是小于128字节时用1个字节表示，大于128字节时用多个字节。我刚开始做MQTT开发时，就因为这个变长编码踩过坑——解析报文时忘了处理多字节情况，结果设备一直连不上Broker。排查了半天才发现是这个问题。

MQTT 3.1.1版本定义了14种报文类型，常用的有：

小技巧：调试MQTT时，我习惯用Wireshark抓包，然后过滤mqtt协议。这样能清楚看到每个报文的交互过程，排查问题特别方便。

QoS（Quality of Service，服务质量）是MQTT里一个非常重要的概念。它决定了消息传递的可靠性。MQTT定义了三个等级：

QoS等级	名称	发送次数	可靠性	适用场景
0	至多一次	1次	最低	传感器数据（丢一两条无所谓）
1	至少一次	至少1次	中等	控制指令（允许重复）
2	恰好一次	2次（四次握手）	最高	计费、支付等关键数据

QoS 0：说白了就是「发出去就不管了」。Broker收到消息后不会回复确认，发布者也不知道消息到底到没到。我在做环境监测项目时，温度数据就用QoS 0——因为传感器每秒发一次数据，丢一两条完全不影响。

QoS 1：保证消息至少到达一次。Broker收到后会回复PUBACK确认。如果发布者没收到确认，就会重发。但问题来了——可能重复。我曾经在一个智能灯控项目里用过QoS 1，结果因为网络抖动，灯控指令被重复执行了两次。嗯，从那以后我就记住了：QoS 1不适用于「只执行一次」的场景。

QoS 2：这是最可靠的等级。它通过四次握手（PUBLISH→PUBREC→PUBREL→PUBCOMP）确保消息恰好到达一次。你想想看，这需要额外的开销，所以延迟会高一些。我只有在处理计费数据时才会用QoS 2——毕竟钱的事不能含糊。

避坑指南：我曾经在一个项目里对所有消息都用了QoS 2，结果设备性能严重下降。后来才发现，QoS 2的握手过程会占用大量内存和带宽。建议根据业务场景选择合适的QoS等级，不要盲目追求高可靠性。

好了，MQTT的基础就回顾到这里。发布/订阅模型、报文结构、QoS等级，这三块是后续学习安全机制的前提。下一节咱们正式进入TLS加密实战，看看怎么给MQTT通信加上一把「锁」。