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 工作流程
- 客户端首先与MQTT服务器建立TCP连接,连接成功后,客户端发送一个
CONNECT
消息,包含客户端标识、用户名、密码等信息。 - 服务器验证这些信息后,返回一个
CONNACK
消息,确认连接。发布者客户端发送PUBLISH
消息,将消息发送到特定的主题(Topic
),消息包含主题名称、消息有效荷载(Payload
)和质量服务等级(QoS
)。 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相关工具
- 调试工具 : 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)