MQTT协议学习与分享

什么是 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数据包中,其结构如下:

Bit

7

6

5

4

3

2

1

0

byte 1

MQTT数据包类型

DUP flag

Qos Level

Retain

byte 2…

剩余长度

 

MQTT数据包类型

位置:byte 1, bits 7-4。

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

名称

流方向

描述

Reserved

0

不可用

保留位

CONNECT

1

客户端到服务器

客户端请求连接到服务器

CONNACK

2

服务器到客户端

连接确认

PUBLISH

3

双向

发布消息

PUBACK

4

双向

发布确认

PUBREC

5

双向

发布收到(保证第1部分到达)

PUBREL

6

双赂

发布释放(保证第2部分到达)

PUBCOMP

7

双向

发布完成(保证第3部分到达)

SUBSCRIBE

8

客户端到服务器

客户端请求订阅

SUBACK

9

服务器到客户端

订阅确认

UNSUBSCRIBE

10

客户端到服务器

请求取消订阅

UNSUBACK

11

服务器到客户端

取消订阅确认

PINGREQ

12

客户端到服务器

PING请求

PINGRESP

13

服务器到客户端

PING应答

DISCONNECT

14

客户端到服务器

中断连接

Reserved

15

不可用

保留位

 

标识位

位置: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、可变头

Bit

7

6

5

4

3

2

1

0

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

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

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

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

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

 

posted @ 2022-06-28 10:25  不断努力的青春  阅读(513)  评论(0编辑  收藏  举报