MQTT服务质量等级及抓包分析

什么是服务质量？

服务质量(QualityofService,QoS)等级是消息发送方与消息接收方之间的协议，对应着消息传递时不同的可靠程度。

MQTT有三种QoS等级：

至多一次（QoS 0）
至少一次（QoS 1）
只有一次（QoS 2）

MQTT中消息的发布和订阅都有QoS等级的设置，我们需要将其分开理解

1.publish的QoS等级

1.1 QoS 0

当client1 publish一条消息时，如果设置的QoS等于0，那么client1只会发送一次这条消息，就算broker没有收到，client1也不会管。对于broker来说，它收到client1 publish的消息，就会PUBLISH给众多客户端，收不到自然也不会PUBLISH。产生的效果：broker最终会PUBLISH 0条或1条消息，即至多一次。

1.2 QoS 1

上面那个例子，如果设置QoS等于1，那么client1发送一条消息，broker收到后会发给client1一个应答PUBACK，client1如果收到应答就会停止发送，否则，继续发送。broker做的事情也很简单，收到一次消息，就将消息PUBLISH给众多客户端，同时发现QoS等级为1，就向刚刚给自己publish消息的client1发送一个响应PUBACK。但是在这种交互中存在两个问题，1：client1 publish的消息有可能broker没能收到，2：broker回复的PUBACK client1没能收到。这样会造成：broker收到消息，将消息PUBLISH出去后，client1没能收到PUBACK，就会继续发送消息，broker就会继续PUBLISH，直到client1收到PUBACK为止。产生效果：broker最终会PUBLISH 至少1条消息，即至少一次。

1.3 QoS 2

还是上面的例子，如果设置QoS等于2，那么client1发送一条消息后，broker会回一个PUBREC(publish recevied)（但是这里注意broker虽然已经收到了消息但是它不会立马PUBLISH给众多客户端，还要等待后续步骤）,client1收到PUBREC会回应一个PUBREL(publish release)(即既然你broker收到了，我client1就把这条消息释放了，保存起来太占地方),client1也不会再重复发这条消息了,因为都已经释放这个包了,broker收到PUBREL后会回复client1一个PUBCOMP(publish complete)（即这次消息传递完毕）,broker发完PUBCOMP后，才会将刚才的消息PUBLISH给众多客户端。在PUBCOMP之前的交互中，如若有丢包同样会重传。产生效果：broker最终会PUBLISH 1条消息，不会多于1条，也不会少于1条。

应用场景：

为什么要有这三种服务质量等级呢？我们结合具体需求来思考一下
QoS 0 适合什么场景呢？适合那种消息很频繁但又不那么重要的应用，如每隔几分钟上报一次气温，数据丢了就丢了，反正待会还会上报，并且丢失一次数据也不会产生多大影响。
但是，如果消息对你很重要，你宁愿收到重复的也不愿意丢失一条，那你就采用QoS 1
但是，如果像支付类的应用也采用QoS 1的话，会产生重复支付的问题（其实已经支付成功了，只是手机没有收到回应，又再次发起支付），这时候就需要使用QoS 2了，它保证有且仅有一次消息成功传递。

2.subscribe的QoS等级

说完了publish的QoS，我们再来谈谈subscribe的QoS。其实我们完全可以使用上面三个例子的分析，因为clientA、clientB、clientC 订阅 broker的消息就相当于broker发布消息给他们（这点从后面的抓包分析也可得以验证），我们仍然可用publish的那一套去理解subscribe的QoS，即client A subscribe消息时设置的QoS等于0，那么broker最多只会发一次消息给clientA。QoS设置为1，那么broker至少会发一次消息给到clientA，给不到就重发。QoS设置为2，那么broker保证有且只有一次消息给到clientA。
但是有一个问题需要注意一下，对于同一个topic，如果client1以QoS 2等级发布，clientA以QoS 0等级订阅，那么clientA最多只会收到一条消息，即两者质量等级取最低。同样的，如果clinet1以QoS 0发布一条消息，clientA以QoS 2等级去订阅，clientA仍然最多只会收到一条消息，因为原则是两者QoS取最低。所以如果要想达到真正的QoS 2质量，就要保证publish和subscribe都设置为 QoS 2

3.抓包

下面结合抓包做一些直观的展示

192.168.2.195为客户端

211.159.189.50为服务端

3.1 connect 连接请求报文

从截图中可以看出，MQTT是基于TCP的，MQTT连接前先进行的是TCP的三次握手建立TCP连接
客户端通过发送MQTT连接控制报文向服务端发起连接请求，控制报文类型为0x10,可变长报头包含协议名、保活时间等信息，有效载荷包含客户端ID信息

3.2 CONNACK – 确认连接请求

服务端给客户端发送确认信息

3.3 订阅请求

3.4 订阅请求应答

3.5 发布消息

因为发布的消息服务质量等级为 QoS 0，所以无响应

现在我们将publish 的服务质量等级设为 QoS 1

再次抓包

发现每一个publish的消息服务端都会有一个回应

再将服务质量等级提升到 QoS 2

抓包

和上面分析的QoS 2一致，每次消息传递都需要四次交互，即(publish)Publish Message、(PUBREC)Publish Received、(PUBREL)Publish Release、(PUBCOMP)Publish Complete

3.6 还想看一下subscribe的QoS

我在客户端同时发布和订阅了相同的topic，服务质量等级都设为QoS 2，
截图中，方框框住的上面四条为客户端向服务端publish消息时产生的交互，满足上面的QoS 2等级的分析。下面四条为客户端订阅了topic而收到消息时的交互，同时也验证了客户端订阅就相当于服务端发布的猜想。

参考文章：https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels

MQTT服务质量等级及抓包分析相关推荐

Linux服务器下的HTTP抓包分析
2019独角兽企业重金招聘Python工程师标准>>> 说到抓包分析,最简单的办法莫过于在客户端直接安装一个Wireshark或者Fiddler了,但是有时候由于客户端开发人员(可能 ...
零窗口探测怎么抓包_Linux服务器下的HTTP抓包分析
说到抓包分析,最简单的办法莫过于在客户端直接安装一个Wireshark或者Fiddler了,但是有时候由于客户端开发人员(可能是第三方)知识欠缺或者其它一些原因,无法顺利的在客户端进行抓包分析,这种情 ...
模块学习4：（2）MQTT协议连接、发布、订阅、心跳、断链等分析和代码实现，并且通过mqtt.fx连接服务器，使用wireshark抓包分析mqtt实现过程
文章目录一.MQTT控制报文的结构 (1)固定报头(类型/标志 + 剩余长度) 剩余长度(这个要注意下,要注意它的计算方法,有一点特殊) 可变报头有效载荷二.下面直接开整各个具体的报文(MQTT ...
抓包分析360浏览器和360搜索配对使用的安全性-WEB服务端分析
接上文抓包分析360浏览器和360搜索配对使用的安全性-环境部署根据:"360搜索会通过360安全卫士和360浏览器将用户平时浏览网页的信息反馈给360的搜索爬虫服务器,然后再由爬虫对相 ...
NMap参数抓包分析——主机发现，端口扫描，服务和版本探测
1. NMap (1)NMap 介绍: NMap(Network Mapper)是一个网络连接端扫描软件,用来扫描网上电脑开放的网络连接端.确定哪些服务运行在哪些连接端,并且推断计算机运行哪个操作系统 ...
转 Wireshark和TcpDump抓包分析心得
1. Wireshark与tcpdump介绍 Wireshark是一个网络协议检测工具,支持Windows平台和Unix平台,我一般只在Windows平台下使用Wireshark,如果是Linux的话 ...
DNS抓包分析--wireshark
DNS抓包分析–wireshark DNS-(Domain Name System,域名系统),是因特网上作为余名和IP地址相互映射的一个分布式数据库,能够使用户更加方便地访问互联网,而不是去记住能够 ...
DHCP数据抓包分析--wireshark
DHCP数据抓包分析–wireshark DHCP-(Dynamic Host Configuration Procotol,动态主机配置协议),是一个局域网的网络协议,主要用于给内部网络或网络服务供 ...
ICMP协议抓包分析-wireshark
ICMP协议抓包分析-wireshark ICMP- (Internet Control Message Protocol,网际报文协议)是Internet协议族的核心协议之一,也可称为是网际控制报文 ...

MQTT服务质量等级及抓包分析

MQTT服务质量等级及抓包分析相关推荐

最新文章

热门文章