MQTT报文分析

一、问题引入#

MQTT属于应用层协议，基于 TCP/IP 架构实现，那么它的报文是如何定义的呢？

或许可以像分析 http协议 那样，利用抓包工具：wireshark 分析报文。

二、解决过程#

📌 注意：wireshark版本为 Wireshark-win64-4.0.5，若版本过低，无法解析应用层协议数据包；MQTT协议版本为 MQTT v3.1.1

2-1 CONNECT 和 CONNACK 报文#

• MQTT.fx 客户端连接 MQTT Broker

红框中前三个包是TCP的三次握手。握手完成后，客户端发送 Connect Command 请求，服务器作出应答 Connect Ack

• MQTT Broker 连接应答 MQTT.fx 客户端

2-2 DISCONNECT 报文#

• MQTT.fx 客户端断开 MQTT Broker

红框中后四个包是TCP的四次挥手，第一个包是 DISCONNECT 报文

2-3 SUBSCRIBE 和 SUBACK 报文#

• MQTT.fx 客户端 订阅Topic

2-4 PUBLISH 和 PUBACK 报文#

• MQTT Broker 响应Topic的订阅

💡 抓包未体现 PUBACK报文。Qos 0 表示：最多分发一次，消息的分发依赖于底层网络的能力。接收者不会发送响应，发送者也不会重试。消息可能送达一次，也可能根本每送达。

---

将Qos=0 修改为 Qos=1后：

💡 QoS 1：至少分发一次，可能会多发，QoS 1的PUBLISH报文的可变报头包含一个报文标识符，需要PUBACK报文确认

---

👉 将Qos=0 修改为 Qos=2后：

👉 当Qos=2 时，一次完正的消息发布过程应该是这样：PUBLISH --> PUBREC --> PUBREL --> PUBCOMP --> TCP ACK

💡 QoS 2：仅分发一次，最高等级的服务质量，消息丢失和重复都是不可接受的。使用这个服务质量等级会有额外的开销。

2-5 UNSUBSCRIBE 和 UNSUBACK 报文#

• MQTT.fx 客户端 取消订阅Topic

2-6 PINGREQ 和 PINGRESP 报文#

三、反思总结#

分析 协议类相关的报文结构，最直接的方法是抓包验证，没有比这更好的方法了。

当然抓包是理论具体实现，但还是要参考MQTT 报文理论。

四、参考引用#

无