MQTT协议史上最全解析(纯干货分享)

这篇具有很好参考价值的文章主要介绍了MQTT协议史上最全解析(纯干货分享)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

MQTT是什么?

MQTT协议全称是(Message Queuing Telemetry Transport),即消息队列遥测传输协议。

是一种基于发布/订阅(Publish/Subscribe)模式的轻量级通讯协议,并且该协议构建于TCP/IP协议之上,我们知道TCP协议本身就具有高可靠性的特点,因此基于其上的MQTT协议同样也是具有高可靠、低开销的特点,之所以低开销,是以为MQTT协议传输的最小的报文也只有两个字节。

在物联网开发中,MQTT不是唯一的选择,与MQTT互相竞争的协议有XMPP和CoAP协议等。

关于发布和订阅的概念我们拿抖音平台来举个例子,我们每一个用户就都是一个客户端,而抖音就是MQTT协议中的服务器,当我们(用户一)关注某一个视频发布者(用户二)时,这样一个关注的行为就可以理解为订阅;同时用户二也可以关注你,那么这就是相互订阅。当用户二发布作品的时候,这个作品是发布到了抖音平台,也就是我们现在的服务器,这个过程就是消息的发布。

在这里需要注意的是:用户二(客户端)发布的消息并不是直接发布给了用户一,而是发布到了抖音平台(服务器),由于用户一订阅了用户二的消息(相当于点了关注),所以抖音平台(服务器)就会向用户一推送这个消息(注意发布和推送的区别)。这就是MQTT协议订阅&发布的一个简单比喻。

mqtt 返回结果,通讯协议,网络,服务器,MQTT,嵌入式

上面是一个比喻,再来对比一下实际的MQTT协议通信模型:
mqtt 返回结果,通讯协议,网络,服务器,MQTT,嵌入式
实现MQTT协议需要客户端和服务器端通讯完成,在通讯过程中,MQTT协议中有三种身份:发布者(Publish)、代理(Broker)(服务器)、订阅者(Subscribe)。其中,消息的发布者和订阅者都是客户端,消息代理是服务器,消息发布者可以同时是订阅者。

MQTT传输的消息分为:主题(Topic)和负载(payload)两部分

  • Topic,可以理解为消息的类型,订阅者订阅(Subscribe)后,就会收到该主题的消息内容(payload)
  • payload,可以理解为消息的内容,是指订阅者具体要使用的内容

一些术语解释

网络连接 Network Connection

MQTT 使用的底层传输协议(TCP)基础设施。

  • 客户端使用它连接服务端。
  • 它提供有序的、可靠的、双向字节流传输。

应用消息 Application Message

MQTT 协议通过网络传输应用数据。应用消息通过 MQTT 传输时,它们有关联的服务质量(QoS) 和主题(Topic) 。

客户端 Client

使用 MQTT 的程序或设备。客户端总是通过网络连接到服务端。它可以

  • 发布应用消息给其它相关的客户端。
  • 订阅以请求接受相关的应用消息
  • 取消订阅以移除接受应用消息的请求。
  • 从服务端断开连接。

服务端 Server

一个程序或设备,作为发送消息的客户端和请求订阅的客户端之间的中介。服务端

  • 接受来自客户端的网络连接。
  • 接受客户端发布的应用消息。
  • 处理客户端的订阅和取消订阅请求。
  • 转发应用消息给符合条件的已订阅客户端。

订阅 Subscription

订阅包含一个主题过滤器(Topic Filter)和一个最大的服务质量(QoS)等级。订阅与单个会话(Session)关联。会话可以包含多于一个的订阅。会话的每个订阅都有一个不同的主题过滤器。

主题名 Topic Name

附加在应用消息上的一个标签,服务端已知且与订阅匹配。服务端发送应用消息的一个副本给每一个匹配的客户端订阅。

主题过滤器 Topic Filter

订阅中包含的一个表达式,用于表示相关的一个或多个主题。主题过滤器可以使用通配符。

会话 Session

客户端和服务端之间的状态交互。一些会话持续时长与网络连接一样,另一些可以在客户端和服务端的多个连续网络连接间扩展。

控制报文 MQTT Control Packet

通过网络连接发送的信息数据包。MQTT规范定义了十四种不同类型的控制报文,其中一个(PUBLISH报文) 用于传输应用消息。

MQTT特点

1.客户端使用它连接服务端。
2.它提供有序的、可靠的、双向字节流传输。
3.使用发布/订阅消息模式,提供了一对多的消息分发和应用之间的解耦。
4.消息传输不需要知道负载内容。
5.提供三种等级的服务质量QoS :
6.很小的传输消耗和协议数据交换,最大限度减少网络流量
7.异常连接断开发生时,能通知到相关各方。

消息质量(QoS)

MQTT消息质量有三个等级,QoS 0,QoS 1和 QoS 2。

QoS 0:最多分发一次。消息的传递完全依赖底层的TCP/IP网络,协议里没有定义应答和重试,消息要么只会到达服务端一次,要么根本没有到达。消息可能会丢失。例如,这个等级可用于环境传感器数据,单次的数据丢失没关系,因为不久之后会再次发送。

QoS 1:至少分发一次。服务器的消息接收由PUBACK消息进行确认,如果通信链路或发送设备异常,或者指定时间内没有收到确认消息,发送端会重发这条在消息头中设置了DUP位的消息。(保证交付功能)

QoS 2:只分发一次。这是最高级别的消息传递,消息丢失和重复都是不可接受的,使用这个服务质量等级会有额外的开销。例如,这个等级可用在一个计费系统中,这里如果消息重复或丢失会导致不正确的收费。

eg.
目前流行的共享单车智能锁,智能锁可以定时使用QoS level 0质量消息请求服务器,发送单车的当前位置,如果服务器没收到也没关系,反正过一段时间又会再发送一次。之后用户可以通过App查询周围单车位置,找到单车后需要进行解锁,这时候可以使用QoS level 1质量消息,手机App不断的发送解锁消息给单车锁,确保有一次消息能达到以解锁单车。最后用户用完单车后,需要提交付款表单,可以使用QoS level 2质量消息,这样确保只传递一次数据,否则用户就会多付钱了。

MQTT控制报文格式

MQTT 控制报文的结构

Fixed header 固定报头,所有控制报文都包含
Variable header 可变报头,部分控制报文包含
Payload 有效载荷,部分控制报文包含

注:固定报头必须有,可变报头和有效负载可以没有。

固定报头】:第一个字节高4位是MQTT控制报文的类型 + 第一个字节低4位用于指定控制报文类型的标志位(只在PUBLISH发布消息时用到) + 剩余长度1~4个字节(剩余长度字段最大4个字节)
mqtt 返回结果,通讯协议,网络,服务器,MQTT,嵌入式剩余长度包括可变报头和负载的数据。
剩余长度不包括用于编码剩余长度字段本身的字节数。
剩余长度字段使用一个变长度编码方案,对小于 128 的值它使用单字节编码。更大的值按下面的方式处理。
低 7 位有效位用于编码数据,最高有效位用于指示是否有更多的字节。因此每个字节可以编码 128 个数值和一个延续位(continuation bit) 。
剩余长度字段最大4个字节。

可变报头】:可变报头的内容根据报文类型的不同而不同。
某些MQTT控制报文包含一个可变报头部分。它在固定报头和负载之间。可变报头的报文标识符(Packet Identifier) 字段存在于在多个类型的报文里。
报文标志符(2字节):包含报文标识符的9个控制报文有:PUBLISH(QoS>0),PUBACK ,PUBREC ,PUBREL ,PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK

报文标志符的注意项:
1.客户端和服务端彼此独立地分配报文标识符。因此,客户端服务端组合使用相同的报文标识符可以实现并发的消息交换。
2. SUBSCRIBE,UNSUBSCRIBE 和 PUBLISH(QoS 大于 0)控制报文 必须包含一个非零的 16 位报文标识符(Packet Identifier)
3. 客户端每次发送一个新的这些类型的报文时都必须分配一个当前未使用的报文标识符。如果一个客户端要重发这个特殊的控制报文,在随后重发那个报文时,它必须使用相同的标识符。当客户端处理完这个报文对应的确认后,这个报文标识符就释放可重用。
4. QoS 设置为 0 的 PUBLISH 报文 不能包含报文标识符。
5.PUBACK, PUBREC, PUBREL 报文 必须包含与最初发送的 PUBLISH 报文相同的报文标识符。类似地,SUBACK 和 UNSUBACK 必须包含在对应的 SUBSCRIBE 和 UNSUBSCRIBE 报文中使用的报文标识符。
6. 作用:基于标志位来决定可变报头中是否需要包含这些字段

有效载荷】:某些 MQTT 控制报文在报文的最后部分包含一个有效载荷,例如对于 PUBLISH 来说有效载荷就是应用消息。
可能包含有效载荷的控制报文有:CONNECT,PUBLISH,SUBSCRIBE,SUBACK,UNSUBSCRIBE

十四种控制报文

mqtt 返回结果,通讯协议,网络,服务器,MQTT,嵌入式注:C->S指的是客户端到服务端,S->C指的是服务端到客户端,C<->S指的是两个方向都允许
0和15类型值保留无效。
表格中的值指的是固定报头第一个字节的高4位即MQTT控制报文的类型的值
PUBREC和PUBREL和PUBCOMP只有在QoS2等级时才存在

1号控制报文:CONNECT – 连接到服务端

注:客户端到服务端的网络连接建立后,客户端发送给服务端的第一个报文 必须是 CONNECT 报文
在一个网络连接上,客户端只能发送一次 CONNECT 报文。服务端 必须将客户端发送的第二个 CONNECT报文当作协议违规处理并断开客户端的连接。
CONNECT 报文的可变报头按下列次序包含四个字段:协议名(Protocol Name),协议级别(Protocol Level),连接标志(Connect Flags)和保持连接(Keep Alive)
注:客户端用 8 位的无符号值表示协议的修订版本。对于 3.1.1 版协议,协议级别字段的值是 4(0x04)。如果发
现不支持的协议级别,服务端 必须给客户端发送一个返回码为 0x01(不支持的协议级别)的 CONNACK报文响应CONNECT 报文,然后断开客户端的连接
注:连接标志字节包含一些用于指定 MQTT 连接行为的参数。它还指出有效载荷中的字段是否存在。此连接标志将预示后面有效载荷的内容
注:服务端 必须验证 CONNECT 控制报文的保留标志位(第 0 位)是否为 0,如果不为 0 必须断开客户端连接

CONNECT控制报文的内容:
固定报头 MQTT 4位报文类型加4位保留位即10 ,剩余长度字节由后续的数据长度决定
可变报头 固定协议名6字节 长度00 04 + MQTT UTF-8编码 00 04 4D 51 54 54
协议级别1字节 04 代表3.1.1 版协议
连接标志1字节 C2 置位密码标志,用户名标志,清理会话标志
保持连接时间2字节 00 78 代表120秒
有效载荷 客户端ID数据长度2字节 + 客户端ID ASC码 + 用户名数据长度2字节 + 用户名 ASC码 + 密码长度2字节 + 密码 ASC码

注意!CONNECT 报文的有效载荷(payload)包含一个或多个以长度为前缀的字段,可变报头中的连接标志决定是否
包含这些字段。如果包含的话, 必须按这个顺序出现:客户端标识符,遗嘱主题,遗嘱消息,用户名,密码

报文举例:
10 | 25 | 00 04 4D 51 54 54 | 04 | C2 | 00 78 | 00 09 35 32 38 39 38 36 38 37 35 | 00 06 32 34 38 34 39 33 | 00 06 6B 66 62 73 6B 64

固定报头0x10表示客户端请求连接服务端
固定报头0x25表示可变报头和有效负载一共37个字节数据,本身不算在内
协议名00 04 4D 51 54 54 ,00 04表示4个字节 ,4D 51 54 54是MQTT 的 UTF-8 编码的字符串(也是ASC码值)
协议级别04客户端用 8 位的无符号值表示协议的修订版本。对于 3.1.1 版协议,协议级别字段的值是 4(0x04)
连接标志C2
保持连接 00 78 即120秒
00 09 35 32 38 39 38 36 38 37 35 设备ID ,9个字节,528986875的ASC码,以下相同
00 06 32 34 38 34 39 33 产品ID 248493
00 06 6B 66 62 73 6B 64 鉴权信息 kfbskd

2号控制报文:CONNACK – 确认连接请求

注意:服务端发送 CONNACK 报文响应从客户端收到的 CONNECT 报文。服务端发送给客户端的第一个报文 必须是 CONNACK 报文
如果客户端在合理的时间内没有收到服务端的 CONNACK 报文,客户端 应该关闭网络连接。合理的时间取决于应用的类型和通信基础设施。
CONNACK控制报文的内容:
固定报头 MQTT 4位报文类型加4位保留位即20 ,剩余长度字节由后续的数据长度决定
可变报头 两字节:连接确认标志(前7位必须为0,最低位取决于连接标志中的清理会话标志)+连接返回码(正常为00,否则指示故障)
有效载荷 无

报文举例:
20 02 01 00
固定报头20 02:20标志报文类型2,02剩余长度
可变报头01 00
有效负载无

3号控制报文:PUBLISH – 发布消息

PUBLISH 控制报文是指从客户端向服务端或者服务端向客户端传输一个应用消息。
客户端使用 PUBLISH 报文发送应用消息给服务端,目的是分发到其它订阅匹配的客户端。
服务端使用 PUBLISH 报文发送应用消息给每一个订阅匹配的客户端。

报文内容组成:
固定报头 第一个字节高4位报文类型3 ,低4位分别是DUP重发标志-QoS等级高位-QoS等级低位-保留位,第2个字节开始是剩余长度
可变报头 可变报头按顺序包含主题名(UTF-8编码)和报文标识符。主题名之前有两字节主题名的长度,报文标志符是两字节。
注意报文标志符只在QoS等级1和2的报文中有,等级0没有直接忽略
有效负载 有效载荷包含将被发布的应用消息。数据的内容和格式是应用特定的。长度计算是剩余长度-可变报头的长度

关于DUP重发标志:如果 DUP 标志被设置为 0,表示这是客户端或服务端第一次请求发送这个 PUBLISH 报文。如果 DUP 标志
被设置为 1,表示这可能是一个早前报文请求的重发。
客户端或服务端请求重发一个 PUBLISH 报文时, 必须将 DUP 标志设置为 1 。对于 QoS 0 的消息,DUP 标志 必须设置为 0 。

关于QoS等级标志位:PUBLISH 报文不能将QoS所有的位设置为 1。如果服务端或客户端收到QoS所有位都为1的 PUBLISH报文,它必须关闭网络连接

关于保留位:如果客户端发给服务端的 PUBLISH 报文的保留(RETAIN)标志被设置为 1,服务端 必须存储这个应用消息和它的服务质量等级(QoS),以便它可以被分发给未来的主题名匹配的订阅者。
如果客户端发给服务端的 PUBLISH 报文的保留标志位 0,服务端 不能存储这个消息也 不能移除或替换任何现存的保留消息。

报文举例:
30 0E 00 09 6B 66 62 5F 74 6F 70 69 63 31 32 33 QoS等级0 数据:123,等级0没有回复

32 10 00 09 6B 66 62 5F 74 6F 70 69 63 00 01 31 32 33 等级1 数据:123

34 10 00 09 6B 66 62 5F 74 6F 70 69 63 00 01 31 32 33 等级2 数据:123

这里面的主题名称是kfb_topic: 6B 66 62 5F 74 6F 70 69 63,主题名之前有两字节主题名的长度00 09
报文标志符只在QoS等级1和2的报文中有,例子中报文标识符是00 01

4号控制报文:PUBACK – 发布确认

PUBACK 报文是对 QoS 1 等级的 PUBLISH 报文的响应。

报文内容组成:
固定报头 报文类型40+剩余长度02
可变报头 包含等待确认的 PUBLISH 报文的报文标识符两个字节。具体内容取决于之前的 PUBLISH 报文中的报文标志符。
有效负载 无

报文举例:
40 02 00 01 等级1的回复,表示签收
固定报头40 02:40标志报文类型4,02剩余长度
可变报头00 01 与等待确认的PUBLISH报文的报文标识符一致
有效负载无

5号控制报文:PUBREC – 发布收到(QoS 2 ,第一步)

PUBREC 报文是对 QoS 等级 2 的 PUBLISH 报文的响应。(通常由接收方回复)它是 QoS 2 等级协议交换的第二个报文。

报文内容组成:
固定报头 报文类型50+剩余长度02
可变报头 包含等待确认的 PUBLISH 报文的报文标识符两个字节。具体内容取决于之前的 PUBLISH 报文中的报文标志符。
有效负载 无

报文举例:
50 02 00 01 等级2的第一次服务器的回复,等级2有两次回复,客户端再次发送62 02 00 01,得到服务器的二次回复70 02 00 01表示成功
固定报头50 02:40标志报文类型5,02剩余长度
可变报头00 01 与等待确认的PUBLISH报文的报文标识符一致
有效负载无

6号控制报文:PUBREL – 发布 释放(QoS 2 ,第二步)

PUBREL 报文是对 PUBREC 报文的响应。(通常是发送方发出)它是 QoS 2 等级协议交换的第三个报文。
注意!PUBREL 控制报文固定报头的第 3,2,1,0 位是保留位, 必须被设置为 0,0,1,0。服务端 必须将其它的任何值都当做是不合法的并关闭网络连接。

报文内容组成:
固定报头 报文类型62+剩余长度02
可变报头 包含等待确认的 PUBLISH 报文的报文标识符两个字节。具体内容取决于之前的 PUBLISH 报文中的报文标志符。
有效负载 无

报文举例:
62 02 00 01 等级2 再次询问

7号控制报文:PUBCOMP – 发布 完成(QoS 2 ,第三步)

PUBCOMP 报文是对 PUBREL 报文的响应。(通常由接收方回复)它是 QoS 2 等级协议交换的第四个也是最后一个报文。

报文内容组成:
固定报头 报文类型70+剩余长度02
可变报头 包含等待确认的 PUBLISH 报文的报文标识符两个字节。具体内容取决于之前的 PUBLISH 报文中的报文标志符。
有效负载 无

报文举例:
70 02 00 01 等级2的第二次回复,表示彻底完成

8号控制报文:SUBSCRIBE - 订阅主题

客户端向服务端发送 SUBSCRIBE 报文用于创建一个或多个订阅。
为了将应用消息转发给与那些订阅匹配的主题,服务端发送 PUBLISH 报文给客户端。
SUBSCRIBE报文也(为每个订阅)指定了最大的 QoS 等级,服务端根据这个发送应用消息给客户端。

报文内容组成:
固定报头 报文类型82+剩余长度
可变报头 报文标识符两个字节。
有效负载 主题过滤器长度两字节+主题过滤器(+【可包含多个】后一个主题过滤器长度两字节+主题过滤器+)服务质量等级1字节仅低两位有效

SUBSCRIBE 报文的有效载荷 必须包含至少一对主题过滤器 和 QoS 等级字段组合。
每一个过滤器后面跟着一个字节,这个字节被叫做服务质量要求(Requested QoS)。它给出了服务端向客户端发送应用消息所允许的最大 QoS 等级。

报文举例:
82 0E 00 0A 00 09 61 70 70 5F 74 6F 70 69 63 00 等级0
82 0E 00 0B 00 09 61 70 70 5F 74 6F 70 69 63 01 等级1
订阅的主题名为app_topic:61 70 70 5F 74 6F 70 69 63 ,前面的00 09是主题名长度

9号控制报文:SUBACK – 订阅确认

服务端发送 SUBACK 报文给客户端,用于确认它已收到并且正在处理 SUBSCRIBE 报文。
SUBACK 报文包含一个返回码清单,它们指定了 SUBSCRIBE 请求的每个订阅被授予的最大 QoS 等级。

报文内容组成:
固定报头 报文类型90+剩余长度
可变报头 可变报头包含等待确认的 SUBSCRIBE 报文的报文标识符。两个字节。
有效负载 针对上一个订阅主题报文的等级回复。字节数与上一个SUBSCRIBE报文中的主题过滤器数量相同。
有效载荷包含一个返回码清单。每个返回码对应等待确认的 SUBSCRIBE 报文中的一个主题过滤器。返回码的顺序必须和 SUBSCRIBE 报文中主题过滤器的顺序相同。
允许的返回码值:
0x00 - 最大 QoS 0
0x01 - 成功 – 最大 QoS 1
0x02 - 成功 – 最大 QoS 2
0x80 - Failure 失败

报文举例:
90 03 | 00 0A | 00 对应上面订阅第一条的报文标识符
90 03 | 00 0B | 01 对应上面订阅第二条的报文标识符

10号控制报文:UNSUBSCRIBE – 取消订阅

客户端发送 UNSUBSCRIBE 报文给服务端,用于取消订阅主题。

报文内容组成:
固定报头 报文类型A2+剩余长度
可变报头 可变报头包含一个报文标识符。两个字节。
有效负载 UNSUBSCRIBE 报文的有效载荷包含客户端想要取消订阅的主题过滤器列表。长度两字节+主题过滤器(+长度两字节+主题过滤器)
UNSUBSCRIBE 报文的有效载荷 必须至少包含一个消息过滤器。

报文举例:
A2 0D 00 0C 00 09 61 70 70 5F 74 6F 70 69 63
00 0C是报文标识符
主题名app_topic,即61 70 70 5F 74 6F 70 69 63,前面的00 09是长度

11号控制报文:UNSUBACK – 取消订阅确认

服务端 必须发送 UNSUBACK 报文响应客户端的 UNSUBSCRIBE 请求。UNSUBACK 报文 必须包含和UNSUBSCRIBE 报文相同的报文标识符

报文内容组成:
固定报头 报文类型B0+剩余长度02
可变报头 可变报头包含等待确认的 UNSUBSCRIBE 报文的报文标识符。两个字节。
有效负载 无

报文举例:
B0 02 00 0C
00 0C对应上一条取消订阅的报文标志符

12号控制报文:PINGREQ – 心跳请求

客户端发送 PINGREQ 报文给服务端的。用于:

  1. 在没有任何其它控制报文从客户端发给服务的时,告知服务端客户端还活着。
  2. 请求服务端发送 响应确认它还活着。
  3. 使用网络以确认网络连接没有断开。

报文内容组成:
固定报头 报文类型C0+剩余长度00
可变报头 无
有效负载 无
服务端 必须发送 PINGRESP 报文响应客户端的 PINGREQ 报文

报文:
C0 00 (只有这一种)

13号控制报文:PINGRESP – 心跳响应

服务端发送 PINGRESP 报文响应客户端的 PINGREQ 报文。表示服务端还活着。

报文内容组成:
固定报头 报文类型D0+剩余长度00
可变报头 无
有效负载 无

报文:
D0 00 (只有这一种)

14号控制报文:DISCONNECT – 断开连接

DISCONNECT 报文是客户端发给服务端的最后一个控制报文。表示客户端"正常"断开连接。

报文内容组成:
固定报头 报文类型E0+剩余长度00
可变报头 无
有效负载 无

报文:
E0 00 (只有这一种)

注意:客户端发送 DISCONNECT 报文之后:
1.必须关闭网络连接。
2.不能通过那个网络连接再发送任何控制报文 。
服务端在收到 DISCONNECT 报文时:
1.必须丢弃任何与当前连接关联的未发布的遗嘱消息。
2.应该关闭网络连接,如果客户端 还没有这么做。

关于CONNECT控制报文中的连接标志

mqtt 返回结果,通讯协议,网络,服务器,MQTT,嵌入式

关于密码标志位:
如果密码(Password)标志被设置为 0,有效载荷中不能包含密码字段。
如果密码(Password)标志被设置为 1,有效载荷中必须包含密码字段。
如果用户名标志被设置为 0,密码标志也必须设置为 0。

关于用户名标志位:
如果用户名(User Name)标志被设置为 0,有效载荷中 不能包含用户名字段。
如果用户名(User Name)标志被设置为 1,有效载荷中 必须包含用户名字段。

关于遗嘱保留位:
如果遗嘱标志被设置为 0,遗嘱保留(Will Retain)标志也 必须设置为 0。
如果遗嘱标志被设置为 1:
1.如果遗嘱保留被设置为 0,服务端必须将遗嘱消息当作非保留消息发布。
2.如果遗嘱保留被设置为 1,服务端必须将遗嘱消息当作保留消息发布。

关于遗嘱QoS位:
这两位用于指定发布遗嘱消息时使用的服务质量等级。
如果遗嘱标志被设置为 0,遗嘱 QoS 也 必须设置为 0(0x00)。
如果遗嘱标志被设置为 1,遗嘱 QoS 的值可以等于 0(0x00),1(0x01),2(0x02)。它的值不能等于3。

关于遗嘱标志位:
遗嘱消息由服务端发布,通常是断开连接后紧接着发布的消息
遗嘱标志(Will Flag)被设置为 1,表示如果连接请求被接受了,遗嘱(Will Message)消息(在有效载荷中)必须被存储在服务端并且与这个网络连接关联。之后网络连接关闭时,服务端必须发布这个遗嘱消息,除非服务端收到DISCONNECT 报文时删除了这个遗嘱消息

遗嘱消息发布的条件,包括但不限于:

  • 服务端检测到了一个 I/O 错误或者网络故障。
  • 客户端在保持连接(Keep Alive)的时间内未能通讯。
  • 客户端没有先发送 DISCONNECT 报文直接关闭了网络连接。
  • 由于协议错误服务端关闭了网络连接。

如果遗嘱标志被设置为 1,连接标志中的 Will QoS 和 Will Retain 字段会被服务端用到,同时有效载荷中必须包含 Will Topic 和 Will Message 字段。一旦被发布或者服务端收到了客户端发送的 DISCONNECT 报文,遗嘱消息就必须从存储的会话状态中移除。
如果遗嘱标志被设置为 0,连接标志中的 Will QoS 和 Will Retain 字段 必须设置为 0,并且有效载荷中 不能包含 Will Topic 和 Will Message 字段。网络连接断开时, 服务端更加不能发送遗嘱消息。
服务端应该在条件成立时迅速发布遗嘱消息。在关机或故障的情况下,服务端可以推迟遗嘱消息的发布直到之后的重启。
如果发生了这种情况,在服务器故障和遗嘱消息被发布之间可能会有一个延迟。

关于清理会话标志:
指定了会话状态的处理方式。客户端和服务端可以保存会话状态,以支持跨网络连接的可靠消息传输。这个标志位用于控制会话状态的
生存时间。
如果清理会话(CleanSession)标志被设置为 1,客户端和服务端 必须丢弃之前的任何会话并开始一个新的会话。会话仅持续和网络连接同样长的时间。与这个会话关联的状态数据不能被任何之后的会话重用。
清理会话标志设置为 1 的客户端不会收到旧的应用消息,而且在每次连接成功后都需要重新订阅任何相关的主题。
为了确保在发生故障时状态的一致性,客户端应该使用会话状态标志 1 重复请求连接,直到连接成功。
(通常使用置1即可)

关于CONNECT控制报文中的保持连接时间

保持连接(Keep Alive)是一个以秒为单位的时间间隔,表示为一个 16 位的字,它是指在客户端传输完成一个控制报文的时刻到发送下一个报文的时刻,两者之间允许空闲的最大时间间隔。客户端负责保证控制报文发送的时间间隔不超过保持连接的值。如果没有任何其它的控制报文可以发送,客户端 必须发送一个PINGREQ 报文。
不管保持连接的值是多少,客户端任何时候都可以发送 PINGREQ 报文,并且使用 PINGRESP 报文判断网络和服务端的活动状态。
如果保持连接的值非零,并且服务端在1.5倍的保持连接时间内没有收到客户端的控制报文,它必须断开客户端的网络连接,认为网络连接已断开。
客户端发送了 PINGREQ 报文之后,如果在合理的时间内仍没有收到 PINGRESP 报文,它 应该关闭到服务端的网络连接。
保持连接的值为零表示关闭保持连接功能。这意味着,服务端不需要因为客户端不活跃而断开连接,即可以一直保持连接。注意:
不管保持连接的值是多少,任何时候,只要服务端认为客户端是不活跃或无响应的,可以断开客户端的连接。
保持连接的实际值是由应用指定的,一般是几分钟。允许的最大值是 18 小时 12 分 15 秒。文章来源地址https://www.toymoban.com/news/detail-709378.html

到了这里,关于MQTT协议史上最全解析(纯干货分享)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • MQTT(3):MQTT协议原理

    官方文档中对于MQTT协议包的结构有着具体的说明:http://mqtt.org/documentation 在MQTT协议中,一个MQTT数据包由:固定头(Fixed header)、可变头(Variable header)、消息体(payload)三部分构成。MQTT数据包结构如下: (1)固定头(Fixed header)。存在于所有MQTT数据包中,表示数据包类

    2024年02月06日
    浏览(30)
  • 【MQTT】MQTT协议与指令下发;MQTT与Kafka比较

    相关文章: (一)MQTT协议与指令下发;MQTT与Kafka比较 (二)用MQTT在Spring Boot项目中实现异步消息通信 详细讲讲MQTT协议 当涉及到 物联网 和 设备通信 时,MQTT(Message Queuing Telemetry Transport)是一种轻量级、开放、灵活的协议。MQTT最初是为低带宽、不稳定网络环境下的传感器

    2024年02月02日
    浏览(37)
  • 【MQTT协议】使用c++实现mqtt协议(Mosquitto源码编译)

    MQTT(Message Queuing Telemetry Transport)是一种轻量级的、基于发布/订阅模式的消息传输协议,其最初由IBM开发,现已成为OASIS标准。MQTT协议常用于物联网领域,特别是在传输 低带宽、高延迟、不稳定网络 条件下的数据,例如传感器数据和遥测数据等。 MQTT协议的优点: 轻量级:

    2023年04月12日
    浏览(87)
  • 什么是MQTT,物联网MQTT协议详解

    老俊目前正在从事物联网行业,对MQTT有一定的了解,本文为您简述什么是MQTT,以及MQTT怎么使用 物联网 (IoT) 和机器对机器 (M2M) 通信对我们与技术交互的方式产生了持久影响。到 2022 年底,全球连接的物联网设备数量增长了 18%,达到 144 亿, 到 2025 年估计连接的物联网设备将

    2024年02月12日
    浏览(51)
  • 【MQTT协议】使用Mosquitto实现mqtt协议(二):编写视频帧的发布/订阅服务

    更多内容详见 【MQTT协议】使用c++实现mqtt协议(Mosquitto源码编译) MQTT协议中的QoS(Quality of Service)表示消息传输的服务质量等级,它是MQTT协议中非常重要的一个概念。 MQTT协议中定义了三个不同等级的QoS: QoS 0:最多一次(At most once)传输。消息发布者只发送一次消息,不

    2023年04月14日
    浏览(43)
  • MQTT协议连接华为云

    目录 操作中使用到的相关链接资料: 一、华为云产品设备的创建 二、MQTT.fx调试 操作步骤: 三、网络调试助手NetAssist调试 1.CONNECT 报文--用于连接项目产品 最终CONNECT 报文 PING报文--用于保活 断开连接发送 2.PUBLISH – 发布消息 最终 PUBLISH 报文 四、串口调试助手XCOM调试(这里

    2024年02月01日
    浏览(34)
  • MQTT 协议简介

    MQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),是一种基于 发布/订阅 (publish/subscribe)模式的“ 轻量级 ”通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。 MQTT最大优点在于,用极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。 作

    2024年02月04日
    浏览(33)
  • MQTT协议简介

    MQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),是一种基于 发布/订阅 (publish/subscribe)模式的“ 轻量级 ”通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。 MQTT最大优点在于,用极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。 作

    2024年02月08日
    浏览(34)
  • 【物联网协议】MQTT

    MQTT是一种基于发布/订阅模式的协议,其中客户端(称为发布者)向主题发布消息,并允许其他客户端(称为订阅者)从这些主题订阅消息。MQTT支持多个QoS级别以及最后遗愿消息(LWT)等高级特性。 MQTT客户端通常需要与MQTT代理服务器进行通信以发布或订阅消息。它们可以运

    2024年02月02日
    浏览(49)
  • 物联网协议之MQTT

    MQTT 可以简单看做一个网络协议,用于 机器对机器 的通信(与客户端到服务器的传输有点区别)。智能传感器、可穿戴设备和其他物联网(IoT)设备通常必须通过 带宽有限 的 资源受限 网络传输和接收数据。这些物联网设备使用 MQTT 进行数据传输,因为它易于实施,并且可

    2024年02月05日
    浏览(51)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包