1. MQTT协议概述

1.1 MQTT协议是什么

MQTT : Message Queuing Telemetry Transport

• 模式 : 发布 / 订阅主题
• 优点 : 代码量小、低带宽、实时可靠
• 应用 : 物联网、小型设备、移动应用
• MQTT 常用端口 : 1883

MQTT是一个网络协议，和HTTP类似，因为轻量简单，很多时候传输效率是后者的数十倍。
它仅用极少的代码和有限的带宽，就能为连接远程设备提供实时可靠的消息服务，所以逐渐在物联网(IOT)领域成为了最佳选择。
其实，日常生活中我们也许使用过MQTT，比如你用手机解锁一辆共享单车的时候。

1.2 MQTT里的角色

MQTT里有3个角色，基于发布 / 订阅模式

• 代理 Broker (服务器) (消息中转站)
  • 负责接收各个设备发送来的消息，然后把消息转发给需要的设备
• 发布者 Publisher (客户端)
• 订阅者 Subscriber (客户端)

可以用视频软件（如抖音/B站）举例子，你(订阅者)关注了某个创作者(发布者)，当这个创作者发布新视频的时候，你就会收到B站的推送通知。MQTT协议和上面的简直一模一样。

2. MQTT协议的工作原理

MQTT协议的消息传输基于客户端-服务器模型，客户端可以是发布者(Publisher)或订阅者(Subscriber)，而服务器则负责消息的路由和分发。

2.1 工作流程

1. 客户端首先与MQTT服务器建立TCP连接，连接成功后，客户端发送一个CONNECT消息，包含客户端标识、用户名、密码等信息。
2. 服务器验证这些信息后，返回一个CONNACK消息，确认连接。发布者客户端发送PUBLISH消息，将消息发送到特定的主题(Topic)，消息包含主题名称、消息有效荷载(Payload)和质量服务等级(QoS)。
3. MQTT服务器接收到PUBLISH消息后，根据消息的主题，将消息分发给所有订阅了该主题的客户端。这个过程是异步的，确保了消息的高效分发。

2.2 MQTT底层是TCP/IP

MQTT底层是TCP/IP

• 连接 : 主动连接服务器，连接的时候带了很多的信息，比如用户名和密码
  • 信息匹配成功后，才会给你响应
• 发送心跳 & 回应心跳 : 发布者或订阅者发起，服务端响应。
  • 如果长时间没有发送心跳，服务端会认为这个客户端已经离线了，会主动断开连接。
• 服务质量等级QoS
  • 等级 QoS0 : “最多一次” : 只管发送，不管接收
  • 等级 QoS1 : “最少一次” : 发布以后，服务器必须要回复。如果没收到回复，那么还会继续发，直到你给我回复。
  • 等级 QoS2 : “仅一次” : 发布以后，服务器回复，客户端收到回复以后，发布释放，客户端回复发布完成
    • 应用 : 计费的场景，对次数有严格要求，只要求有一次就够了

除了基于 TCP 的 MQTT，也存在基于 UDP 的 MQTT-SN 等变种协议，不过它们的应用场景和特性与基于 TCP 的 MQTT 有所不同。

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）”。

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级别传递。这个消息必须准确无误地在智能家居系统和支付系统之间传递，既不能丢失也不能重复，以确保你的服务能够正确开通，同时避免因为重复支付而造成损失。

6. 其他

参考

物联网系列 - MQTT协议原理与数据包结构
用B站解释MQTT协议
MQTT协议的工作原理——消息传输
MQTT协议原理与应用精讲
MQTT 协议入门：基础知识和快速教程 | EMQ

MQTT协议测试——MQTT X工具使用_梦的博客-CSDN博客_mqtt测试
推荐八款常用 MQTT 客户端工具 - 知乎 (zhihu.com)
两款常用的 MQTT 调试工具_zuozewei的博客-CSDN博客_mqtt测试工具
MQTT基础 三： 发布、订阅和取消订阅 - 简书 (jianshu.com)