MQTT协议学习与分享

  |   0 评论   |   0 浏览

什么是 MQTT 协议

MQTT 全称(Message Queue Telemetry Transport):一种基于发布/订阅(publish/subscribe)模式的轻量级通讯协议,通过订阅相应的主题来获取消息,是物联网(Internet of Thing)中的一个标准传输协议。

该协议将消息的发布者(publisher)与订阅者(subscriber)进行分离,因此可以在不可靠的网络环境中,为远程连接的设备提供可靠的消息服务,使用方式与传统的MQ有点类似。

TCP协议位于传输层,MQTT 协议位于应用层,MQTT 协议构建于TCP/IP协议上,也就是说只要支持TCP/IP协议栈的地方,都可以使用MQTT协议。

为什么要用 MQTT协议?

MQTT协议为什么在物联网(IOT)中如此受偏爱?而不是其它协议,比如我们更为熟悉的 HTTP协议呢?

  1. 首先HTTP协议它是一种同步协议,客户端请求后需要等待服务器的响应。而在物联网(IOT)环境中,设备会很受制于环境的影响,比如带宽低、网络延迟高、网络通信不稳定等,显然异步消息协议更为适合IOT应用程序。
  2. HTTP是单向的,如果要获取消息客户端必须发起连接,而在物联网(IOT)应用程序中,设备或传感器往往都是客户端,这意味着它们无法被动地接收来自网络的命令。
  3. 通常需要将一条命令或者消息,发送到网络上的所有设备上。HTTP要实现这样的功能不但很困难,而且成本极高。
    **
    **

特性

MQTT协议工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议,它具有以下主要的几项特性:

(1)使用发布/订阅消息模式,提供一对多的消息发布,解除应用程序耦合。

(2)对负载内容屏蔽的消息传输。

(3)使用TCP/IP提供网络连接。

主流的MQTT是基于TCP连接进行数据推送的,但是同样有基于UDP的版本,叫做MQTT-SN。这两种版本由于基于不同的连接方式,优缺点自然也就各有不同了。

(4)有三种消息发布服务质量

  “至多一次 ”,消息发布完全依赖底层TCP/IP网络。会发生消息丢失或重复。这一级别可用于如下情况,环境传感器数据,丢失一次读记录无所谓,因为不久后还会有第二次发送。这一种方式主要普通APP的推送,倘若你的智能设备在消息推送时未联网,推送过去没收到,再次联网也就收不到了。

  “至少一次 ”,确保消息到达,但消息重复可能会发生。

  “只有一次 ”,确保消息到达一次。在一些要求比较严格的计费系统中,可以使用此级别。在计费系统中,消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通讯类的APP的推送,确保用户收到且只会收到一次。 

(5)小型传输,开销很小(固定长度的头部是2字节),协议交换最小化,以降低网络流量。

这就是为什么在介绍里说它非常适合“在物联网领域,传感器与服务器的通信,信息的收集”,要知道嵌入式设备的运算能力和带宽都相对薄弱,使用这种协议来传递消息再适合不过了。

(6)使用Last Will和Testament特性通知有关各方客户端异常中断的机制。

Last Will:即遗言机制,用于通知同一主题下的其他设备发送遗言的设备已经断开了连接。

Testament:遗嘱机制,功能类似于Last Will。

MQTT协议原理

** MQTT协议实现方式**

实现MQTT协议需要客户端和服务器端通讯完成,在通讯过程中,MQTT协议中有三种身份:发布者(Publish)、代理(Broker)(服务器)、订阅者(Subscribe)。其中,消息的发布者和订阅者都是客户端,消息代理是服务器,消息发布者可以同时是订阅者。

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

(1)Topic,可以理解为消息的类型,订阅者订阅(Subscribe)后,就会收到该主题的消息内容(payload);

(2)payload,可以理解为消息的内容,是指订阅者具体要使用的内容。

网络传输与应用消息

MQTT会构建底层网络传输:它将建立客户端到服务器的连接,提供两者之间的一个有序的、无损的、基于字节流的双向传输。

当应用数据通过MQTT网络发送时,MQTT会把与之相关的服务质量(QoS)和主题名(Topic)相关连。

MQTT客户端

一个使用MQTT协议的应用程序或者设备,它总是建立到服务器的网络连接。客户端可以:

(1)发布其他客户端可能会订阅的信息;

(2)订阅其它客户端发布的消息;

(3)退订或删除应用程序的消息;

(4)断开与服务器连接。

MQTT服务器

MQTT服务器以称为"消息代理"(Broker),可以是一个应用程序或一台设备。它是位于消息发布者和订阅者之间,它可以:

(1)接受来自客户的网络连接;

(2)接受客户发布的应用信息;

(3)处理来自客户端的订阅和退订请求;

(4)向订阅的客户转发应用程序消息。

MQTT协议中的订阅、主题、会话

一、订阅(Subscription)

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

二、会话(Session)

每个客户端与服务器建立连接后就是一个会话,客户端和服务器之间有状态交互。会话存在于一个网络之间,也可能在客户端和服务器之间跨越多个连续的网络连接。

三、主题名(Topic Name)

连接到一个应用程序消息的标签,该标签与服务器的订阅相匹配。服务器会将消息发送给订阅所匹配标签的每个客户端。

四、主题筛选器(Topic Filter)

一个对主题名通配符筛选器,在订阅表达式中使用,表示订阅所匹配到的多个主题。

五、负载(Payload)

消息订阅者所具体接收的内容。

MQTT协议中的方法

MQTT协议中定义了一些方法(也被称为动作),来于表示对确定资源所进行操作。这个资源可以代表预先存在的数据或动态生成数据,这取决于服务器的实现。通常来说,资源指服务器上的文件或输出。主要方法有:

(1)Connect。等待与服务器建立连接。

(2)Disconnect。等待MQTT客户端完成所做的工作,并与服务器断开TCP/IP会话。

(3)Subscribe。等待完成订阅。

(4)UnSubscribe。等待服务器取消客户端的一个或多个topics订阅。

(5)Publish。MQTT客户端发送消息请求,发送完成后返回应用程序线程。

MQTT协议数据包结构

前边说过MQTT是一种轻量级的协议,它只专注于发消息, 所以此协议的结构也非常简单。

MQTT数据包

在MQTT协议中,一个MQTT数据包由:固定头(Fixed header)、 可变头(Variable header)、 消息体(payload)三部分构成。

固定头(Fixed header),所有数据包中都有固定头,包含数据包类型及数据包的分组标识。

可变头(Variable header),部分数据包类型中有可变头。

内容消息体(Payload),存在于部分数据包类,是客户端收到的具体消息内容。

固定头

固定头部,使用两个字节,共16位:

固定头存在于所有MQTT数据包中,其结构如下:

Bit76543210
byte 1MQTT数据包类型DUP flagQos LevelRetain
byte 2…剩余长度

MQTT 数据包类型

位置: byte 1, bits 7-4。

相于一个4位的无符号值,类型如下:

名称流方向描述
Reserved0不可用保留位
CONNECT1客户端到服务器客户端请求连接到服务器
CONNACK2服务器到客户端连接确认
PUBLISH3双向发布消息
PUBACK4双向发布确认
PUBREC5双向发布收到(保证第1部分到达)
PUBREL6双赂发布释放(保证第2部分到达)
PUBCOMP7双向发布完成(保证第3部分到达)
SUBSCRIBE8客户端到服务器客户端请求订阅
SUBACK9服务器到客户端订阅确认
UNSUBSCRIBE10客户端到服务器请求取消订阅
UNSUBACK11服务器到客户端取消订阅确认
PINGREQ12客户端到服务器PING请求
PINGRESP13服务器到客户端PING应答
DISCONNECT14客户端到服务器中断连接
Reserved15不可用保留位

标识位

位置: byte 1, bits 3-0。

在不使用标识位的消息类型中,标识位被做为保留位。如果收到无效的标志时,接收端必须关闭网络连接:

DUP Flag(重试标识)

DUP:发布消息的副本。用来在保证消息的可靠传输,如果设置为 1,则在下面的变长中增加MessageId,并且需要回复确认,以保证消息传输完成,但不能用于检测消息重复发送。

QoS Level(消息质量等级)

QoS:发布消息的服务质量,即:保证消息传递的次数

00:最多一次,即:<=1

01:至少一次,即:>=1

10:一次,即:=1

11:预留

RETAIN(持久化)

值为1:表示发送的消息需要一直持久保存,而且不受服务器重启影响,不但要发送给当前的订阅者,且以后新加入的客户端订阅了此Topic,订阅者也会马上得到推送。 注意:新加入的订阅者,只会取出最新的一个RETAIN flag = 1的消息推送。

值为0:仅为当前订阅者推送此消息。

Remaining Length(剩余长度)

在当前消息中剩余的byte(字节)数,包含可变头部和消息体payload。

2、可变头

Bit76543210
byte 1包标签符(MSB)
byte 2…包标签符(LSB)

固定头部仅定义了消息类型和一些标志位,一些消息的元数据需要放入可变头部中。可变头部内容字节长度 + 消息体payload = 剩余长度。

可变头部居于固定头部和payload中间,包含了协议名称,版本号,连接标志,用户授权,心跳时间等内容。

可变头存在于这些类型的消息:PUBLISH (QoS > 0)、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK。

3、消息体payload

消息体payload只存在于CONNECT、PUBLISH、SUBSCRIBE、SUBACK、UNSUBSCRIBE这几种类型的消息:

CONNECT:包含客户端的ClientId、订阅的Topic、Message以及用户名和密码。

PUBLISH:向对应主题发送消息。

SUBSCRIBE:要订阅的主题以及QoS。

SUBACK:服务器对于SUBSCRIBE所申请的主题及QoS进行确认和回复。

UNSUBSCRIBE:取消要订阅的主题。

消息质量(QoS )

消息质量(Quality of Service),即消息的发送质量,发布者(publisher)和订阅者(subscriber)都可以指定qos等级,有QoS 0、QoS 1、QoS 2三个等级。

边分别说明一下这三个等级的区别。

1、Qos 0 :At most once(至多一次),只发送一次消息,不保证消息是否成功送达,没有确认机制,消息可能会丢失或重复。

2、Qos 1 :At least once(至少一次),相对于QoS 0而言Qos 1增加了ack确认机制,发送者(publisher)推送消息到MQTT代理(broker)时,两者自身都会先持久化消息,只有当publisher 或者 Broker分别收到 PUBACK确认时,才会删除自身持久化的消息,否则就会重发。

但有个问题,尽管我们可以通过确认来保证一定收到客户端 或 服务器的message,可我们却不能保证仅收到一次message,也就是当客户端publisher没收到Broker的puback或者 Broker没有收到subscriber的puback,那么就会一直重发。

publisher -> broker 大致流程:

publisher store msg -> publish ->broker (传递message)

broker -> puback -> publisher delete msg (确认传递成功)

3、Qos 2 :Exactly once(只有一次),相对于QoS 1,QoS 2升级实现了仅接受一次message,publisher 和 broker 同样对消息进行持久化,其中 publisher 缓存了message和 对应的msgID,而 broker 缓存了 msgID,可以保证消息不重复,由于又增加了一个confirm 机制,整个流程变得复杂很多。

publisher -> broker 大致流程:

publisher store msg -> publish ->broker -> broker store

msgID(传递message) broker -> puberc (确认传递成功)

publisher -> pubrel ->broker delete msgID (告诉broker删除msgID)

broker -> pubcomp -> publisher delete msg (告诉publisher删除msg)

LWT(最后遗嘱)

LWT 全称为 Last Will and Testament,其实遗嘱是一个由客户端预先定义好的主题和对应消息,附加在CONNECT的数据包中,包括遗愿主题、遗愿 QoS、遗愿消息等。

当MQTT代理 Broker 检测到有客户端client非正常断开连接时,再由服务器主动发布此消息,然后相关的订阅者会收到消息。

举个栗子:聊天室中所有人都订阅一个叫talk的主题 ,但小富由于网络抖动突然断开了链接,这时聊天室中所有订阅主题 talk的客户端都会收到一个 “小富离开聊天室” 的遗愿消息。

遗嘱的相关参数:

Will Flag:是否使用 LWT,1 开启

Will Topic:遗愿主题名,不可使用通配符

Will Qos:发布遗愿消息时使用的 QoS

Will Retain:遗愿消息的 Retain 标识

Will Message:遗愿消息内容

那客户端 Client** 有哪些场景是非正常断开连接呢?**

Broker 检测到底层的 I/O 异常;

客户端 未能在心跳 Keep Alive 的间隔内和 Broker 进行消息交互;

客户端 在关闭底层 TCP 连接前没有发送 DISCONNECT 数据包;

客户端 发送错误格式的数据包到 Broker,导致关闭和客户端的连接等。

注意:当客户端通过发布 DISCONNECT 数据包断开连接时,属于正常断开连接,并不会触发 LWT 的机制,与此同时Broker 还会丢弃掉当前客户端在连接时指定的相关 LWT 参数。


MQTT协议应用场景

MQTT协议广泛应用于物联网、移动互联网、智能硬件、车联网、电力能源等领域。使用的场景也是非常非常多,下边列举一些:

物联网M2M通信,物联网大数据采集

Android消息推送,WEB消息推送

移动即时消息,例如Facebook Messenger

智能硬件、智能家具、智能电器

车联网通信,电动车站桩采集

智慧城市、远程医疗、远程教育

电力、石油与能源等行业市场


标题:MQTT协议学习与分享
作者:不断努力的青春
地址:http://songaw.com/articles/2022/06/28/1656383840197.html