MQTT协议之PUBLISH发布QoS0、QoS1消息报文分析

本文详细介绍了MQTT协议中PUBLISH报文在QoS0和QoS1级别下的发送与响应过程。对于QoS0,服务器接收到消息通常会回传,尽管协议未做强制要求;而对于QoS1,服务器需发送PUBACK作为响应。通过网络抓包分析,展示了报文的固定报头、可变报头、消息ID及有效载荷等关键字段。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、PUBLISH发布QoS0消息

二、抓包消息

 

 

1.1 固定报头

30 10
其中:
30 – 对应的控制报文类型为PUBLISH,重发标志DUP位0,QoS等级为0,
RETAIN标志位0
10 – 剩余长度0x10 = 16个字节

1.2 可变报头

00 06 74 6f 70 69 63 31
其中:
00 06 – 这里就是Topic Name的长度,共6个字节
74 6f 70 69 63 31 – topic1

1.3 有效载荷

31 32 33 33 33 32 34 35
其中,这里没有载荷的长度。
--对应的ASCII码:12333245

2.发布QoS消息的响应报文示例

MQTT协议中规定,PUBLISH报文的接收者必须按照根据PUBLISH报文中的QoS等级发送响应,下表描述了预期的响应规定

服务质量等级 预期响应
QoS0 无响应
QoS1  PUBACK报文
QoS2 PUBACK报文


注意:对于QoS 0类型的消息响应,协议规定可以无响应,但是并不是强制的,一般服务器接收到QoS 0类型的消息,都会按照原样返回,这对于Client其实是不影响的,因为客户端发送的Topic,一般都不会自己订阅,所以接收到没有订阅的Topic消息,不动作即可。
这里我的是没有应答。 

三、PUBLISH发布QoS1消息

 四、抓包消息

1.1 固定报头

32 12
其中:
32 – 对应的控制报文类型为PUBLISH,重发标志DUP位0,QoS等级为1,
RETAIN标志位0
12 – 剩余长度0x12 = 18个字节

1.2 可变报头

00 06 74 6f 70 69 63 31
其中:
00 06 – 这里就是Topic Name的长度,共6个字节
74 6f 70 69 63 31 – topic1

1.3 消息ID

00 09 -就是发送消息的序号,每发一次加一

1.4 有效载荷

31 32 33 33 33 32 34 35
其中,这里没有载荷的长度。
--对应的ASCII码:12333245

五、服务器应答抓包消息

1.1 固定报头

 40 02:应答报头和剩余长度

1.2 消息ID

00 09 -就是应答发送消息的序号

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Ching·

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值