MQTT_0">1. MQTT协议概述
MQTT_1">1.1 MQTT协议是什么
MQTT : Message Queuing Telemetry Transport
MQTT是一个网络协议，和HTTP类似，因为轻量简单，很多时候传输效率是后者的数十倍。
它仅用极少的代码和有限的带宽，就能为连接远程设备提供实时可靠的消息服务，所以逐渐在物联网(IOT)领域成为了最佳选择。
其实，日常生活中我们也许使用过MQTT，比如你用手机解锁一辆共享单车的时候。
MQTT_14">1.2 MQTT里的角色
MQTT里有3个角色，基于发布 / 订阅模式
- 代理 Broker (服务器) (消息中转站)
- 负责接收各个设备发送来的消息，然后把消息转发给需要的设备
- 发布者 Publisher (客户端)
- 订阅者 Subscriber (客户端)
可以用视频软件（如抖音/B站）举例子，你(订阅者)关注了某个创作者(发布者)，当这个创作者发布新视频的时候，你就会收到B站的推送通知。MQTT协议和上面的简直一模一样。
MQTT_25">2. MQTT协议的工作原理
MQTT协议的消息传输基于客户端-服务器模型，客户端可以是发布者(Publisher)或订阅者(Subscriber)，而服务器则负责消息的路由和分发。
2.1 工作流程
- 客户端首先与MQTT服务器建立TCP连接，连接成功后，客户端发送一个
CONNECT消息，包含客户端标识、用户名、密码等信息。 - 服务器验证这些信息后，返回一个
CONNACK消息，确认连接。发布者客户端发送PUBLISH消息，将消息发送到特定的主题(Topic)，消息包含主题名称、消息有效荷载(Payload)和质量服务等级(QoS)。 MQTT服务器接收到PUBLISH消息后，根据消息的主题，将消息分发给所有订阅了该主题的客户端。这个过程是异步的，确保了消息的高效分发。
MQTTTCPIP_34">2.2 MQTT底层是TCP/IP
MQTT底层是TCP/IP
- 连接 : 主动连接服务器，连接的时候带了很多的信息，比如用户名和密码
- 信息匹配成功后，才会给你响应
- 发送心跳 & 回应心跳 : 发布者或订阅者发起，服务端响应。
- 如果长时间没有发送心跳，服务端会认为这个客户端已经离线了，会主动断开连接。
- 服务质量等级QoS
- 等级 QoS0 : “最多一次” : 只管发送，不管接收
- 等级 QoS1 : “最少一次” : 发布以后，服务器必须要回复。如果没收到回复，那么还会继续发，直到你给我回复。
- 等级 QoS2 : “仅一次” : 发布以后，服务器回复，客户端收到回复以后，发布释放，客户端回复发布完成
- 应用 : 计费的场景，对次数有严格要求，只要求有一次就够了
除了基于 TCP 的 MQTT，也存在基于 UDP 的 MQTT-SN 等变种协议，不过它们的应用场景和特性与基于 TCP 的 MQTT 有所不同。
MQTT_48">3. MQTT数据结构
在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、可变头（Variable header）、消息体 （payload）三部分构成。MQTT数据包结构如下：
- 固定头部（Fixed Header） : 这是每个 MQTT 消息都有的部分，长度最小为 2 字节。它包含了消息类型和标志位等信息。
- 可变头部（Variable Header） : 可选(根据消息类型来判定是否存在)
- 存在于部分MQTT数据包中，数据包类型决定了可变头是否存在及其具体内容。
- 有效载荷（Payload） : 可选(根据消息类型来判定是否存在)
- 存在于部分MQTT数据包中，表示客户端收到的具体内容。
3.1 固定头部
这是每个 MQTT 消息都有的部分，长度最小为 2 个字节，最多为 5 个字节。
3.1.1 第一个字节
MQTT 协议明确规定高 4 位用于表示消息类型，低 4 位用于表示标志位（如 QoS 级别、保留位、重复位等）。这种定义是基于一种默认的、统一的位顺序来理解的，所有遵循 MQTT 协议的实现都应该按照这个规定的顺序来解析和处理消息。
3.1.2 第二个字节 - 至多五个字节
第二个字节，高位第一个字节如果为1，表明存在第三个字节，如果为0，表示不存在第三个字节。
3.2 可变报头
如果是连接请求，可见报头就是下图所示这样。
Byte1-Byte2 是 协议长度。
Byte3-Byte6 是 协议名。
Byte7 是 协议级别。
Byte8 是 连接标志，用来确定是否包含 用户名、密码等。
Byte9-Byte10 用作心跳间隔时间。
3.3 有效载荷
如果是连接请求，有效载荷就是下图所示这样。
客户端标识符 : 表示你设备的名字，
还有用户名和密码就是放在这里的 (如果有的话)
4. 抓包
4.1 连接的请求报文
可以看到固定报头、可变报头和有效载荷， Message Type是Connect Command。
4.2 连接的响应报文
没有有效载荷，只有固定报头和可变报头
4.3 发布的请求报文
Message Type : Publish Message
Topic Length : 主题的长度
Topic : 主题
Message Identifier : 消息ID
Message : 有效载荷，其实解析后就是一个JSON字符串
4.4 发布的应答报文
5. 智能家居场景示例
5.1 设备角色介绍
想象一下，你有一个智能家居系统。在这个系统中，有各种各样的设备，就像一个个“小通讯员”。其中包括温度传感器、湿度传感器、智能灯泡和智能窗帘等设备，这些设备就是MQTT中的“客户端（Client）”。
Broker_109">5.2 代理服务器（Broker）的作用
在这个智能家居网络中，还有一个“消息中转站”，也就是MQTT代理（Broker）。它就像是一个社区的收发室，负责接收各个设备发送来的消息，然后把消息转发给需要的设备。
5.3 发布/订阅模式的体现
- 发布过程：温度传感器就像一个小广播员，它会定期检测室内的温度，然后把温度信息发送（发布）出去。例如，它会把温度数据发布到一个主题（Topic）下，这个主题可以是“home/temperature”。这就好比广播员在广播频道“家庭温度频道”上广播室内温度信息。
- 订阅过程：智能空调是一个对温度很感兴趣的设备，它会订阅“home/temperature”这个主题。当温度传感器发布了新的温度消息后，代理服务器就会把这个消息转发给智能空调。这就像智能空调一直收听“家庭温度频道”，一旦有新的温度消息广播，它就能收到并根据温度信息来决定是否调整制冷或制热模式。
5.4 不同QoS级别的应用场景
- QoS 0 - 最多一次传递：智能灯泡的颜色变化信息可以采用QoS 0级别。假设你有一个可以改变颜色的智能灯泡，你通过手机应用设置了一个灯光颜色变化的动态效果。这个颜色变化的消息对于偶尔丢失几条数据不太敏感。如果因为网络问题，有一两条关于颜色变化的指令没有传达到灯泡，可能不会被用户明显察觉，因为灯光效果的连续性不会因为偶尔的丢失而受到严重影响。
- QoS 1 - 至少一次传递：对于智能窗帘的控制指令可以采用QoS 1级别。比如你发送一个指令让窗帘打开，这个指令比较重要，不能丢失。如果因为网络波动，代理服务器没有收到智能窗帘的确认消息，它会重新发送这个指令，这样就确保了窗帘至少能收到一次打开的指令。即使偶尔收到两次相同的指令，窗帘也只是执行相同的动作（打开），不会产生严重的后果。
- QoS 2 - 恰好一次传递：在智能家居系统与外部支付系统进行联动的场景下，例如当你购买了一个智能家居服务套餐，支付成功的消息需要以QoS 2级别传递。这个消息必须准确无误地在智能家居系统和支付系统之间传递，既不能丢失也不能重复，以确保你的服务能够正确开通，同时避免因为重复支付而造成损失。
MQTT_119">6. MQTT相关工具
- 调试工具 : MQTTX
- 抓包工具 :Wireshark
- 密钥计算工具 : 用于生成用户名和密码加密后的字符串
- hex_hmac_sha1.js
- hex_md5.js
- sign.html
7. 其他
参考
物联网系列 - MQTT协议原理与数据包结构
用B站解释MQTT协议
MQTT协议的工作原理——消息传输
MQTT协议原理与应用精讲
MQTT 协议入门：基础知识和快速教程 | EMQ
MQTT协议测试——MQTT X工具使用_梦的博客-CSDN博客_mqtt测试
推荐八款常用 MQTT 客户端工具 - 知乎 (zhihu.com)
两款常用的 MQTT 调试工具_zuozewei的博客-CSDN博客_mqtt测试工具
MQTT基础 三： 发布、订阅和取消订阅 - 简书 (jianshu.com)
