mqttsession保持订阅消息_常用物联网协议MQTT详解

常用物联网协议-----MQTT详解

协议简述

MQTT协议实现方式

实现MQTT协议需要客户端和服务器端通讯完成&＃xff0c;在通讯过程中&＃xff0c;MQTT协议中有三种身份&＃xff1a;发布者(Publish)、代理(Broker)(服务器)、订阅者(Subscribe)。其中&＃xff0c;消息的发布者和订阅者都是客户端&＃xff0c;消息代理是服务器&＃xff0c;消息发布者可以同时是订阅者。MQTT传输的消息分为&＃xff1a;主题(Topic)和负载(payload)两部分&＃xff1a;        (1)Topic&＃xff0c;可以理解为消息的类型&＃xff0c;订阅者订阅(Subscribe)后&＃xff0c;就会收到该主题的消息内容(payload)&＃xff1b;

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

发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。

下图是MQTT的发布&＃xff0f;订阅消息模式

网络传输与应用消息

MQTT会构建底层网络传输&＃xff1a;它将建立客户端到服务器的连接&＃xff0c;提供两者之间的一个有序的、无损的、基于字节流的双向传输。当应用数据通过MQTT网络发送时&＃xff0c;MQTT会把与之相关的服务质量(QoS)和主题名(Topic)相关联。

下图是MQTT为可靠传递消息的三种消息发布服务质量

MQTT客户端

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

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

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

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

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

MQTT服务器

MQTT服务器以称为“消息代理”(Broker)&＃xff0c;可以是一个应用程序或一台设备。它是位于消息发布者和订阅者之间&＃xff0c;它可以&＃xff1a;

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

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

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

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

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

订阅(Subscription)

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

会话(Session)

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

主题名(Topic Name)

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

主题筛选器(Topic Filter)

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

负载(Payload)

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

MQTT协议中的方法

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

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

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

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

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

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

MQTT协议数据包结构

在MQTT协议中&＃xff0c;一个MQTT数据包由&＃xff1a;固定头(Fixed header)、 可变头(Variable header)、 消息体(payload)三部分构成。MQTT的传输格式非常精小&＃xff0c;最小的数据包只有2个bit&＃xff0c;且无应用消息头。

(1)固定头(Fixed header)。存在于所有MQTT数据包中&＃xff0c;表示数据包类型及数据包的分组类标识。

(2)可变头(Variable header)。存在于部分MQTT数据包中&＃xff0c;数据包类型决定了可变头是否存在及其具体内容。

(3)消息体(Payload)。存在于部分MQTT数据包中&＃xff0c;表示客户端收到的具体内容。

如何通过MQTT传输设备数据 

下面以我们的网关为例&＃xff0c;介绍将如何通过MQTT传输我们的数据。

每一个网关属于MQTT传输中的一个client&＃xff0c;客户端通过网络连接到服务端&＃xff0c;它可以

• 发布应用消息给其它相关的客户端。

• 订阅以请求接受相关的应用消息。

• 取消订阅以移除接受应用消息的请求。

• 从服务端断开连接。

CONNECT – 连接服务端

客户端到服务端的网络连接建立后&＃xff0c;客户端发送给服务端的第一个报文必须是CONNECT报文&＃xff0c;在一个网络连接上&＃xff0c;客户端只能发送一次CONNECT报文。服务端必须将客户端发送的第二个CONNECT报文当作协议违规处理并断开客户端的连接。有效载荷包含一个或多个编码的字段。包括客户端的唯一标识符&＃xff0c;Will主题&＃xff0c;Will消息&＃xff0c;用户名和密码。除了客户端标识之外&＃xff0c;其它的字段都是可选的&＃xff0c;基于标志位来决定可变报头中是否需要包含这些字段。CONNECT报文如下表所示&＃xff1a;

1. 网络连接建立后&＃xff0c;如果服务端在合理的时间内没有收到CONNECT报文&＃xff0c;服务端应该关闭这个连接。2. 服务端必须验证CONNECT报文&＃xff0c;如果报文不符合规范&＃xff0c;服务端不发送CONNACK报文直接关闭网络连接。3. 服务端可以检查CONNECT报文的内容是不是满足任何进一步的限制&＃xff0c;可以执行身份验证和授权检查。如果任何一项检查没通过&＃xff0c;它应该发送一个适当的、返回码非零的CONNACK响应&＃xff0c;并且必须关闭这个网络连接。如果验证成功&＃xff0c;服务端会执行下列步骤。

• 如果ClientId表明客户端已经连接到这个服务端&＃xff0c;那么服务端必须断开原有的客户端连接

• 服务端必须执行清理会话的过程。

• 服务端必须发送返回码为零的CONNACK报文作为CONNECT报文的确认响应

• 开始消息分发和保持连接状态监视。

允许客户端在发送CONNECT报文之后立即发送其它的控制报文&＃xff1b;客户端不需要等待服务端的CONNACK报文。如果服务端拒绝了CONNECT&＃xff0c;它不能处理客户端在CONNECT报文之后发送的任何数据。

PUBLISH – 发布消息

PUBLISH控制报文是指从客户端向服务端或者服务端向客户端传输一个应用消息。PUBLISH报文如下&＃xff1a;

有效载荷(包含发布的应用消息)&＃xff0e;&＃xff0e;&＃xff0e;

客户端使用PUBLISH报文发送应用消息给服务端&＃xff0c;目的是分发到其它订阅匹配的客户端。服务端使用PUBLISH报文发送应用消息给每一个订阅匹配的客户端。

客户端使用带通配符的主题过滤器请求订阅时&＃xff0c;客户端的订阅可能会重复&＃xff0c;因此发布的消息可能会匹配多个过滤器。对于这种情况&＃xff0c;服务端必须将消息分发给所有订阅匹配的QoS等级最高的客户端。服务端之后可以按照订阅的QoS等级&＃xff0c;分发消息的副本给每一个匹配的订阅者。

收到一个PUBLISH报文时&＃xff0c;接收者的动作取决于QoS等级。如果服务端实现不授权某个客户端发布PUBLISH报文&＃xff0c;它没有办法通知那个客户端。它必须按照正常的QoS规则发送一个正面的确认&＃xff0c;或者关闭网络连接。

SUBSCRIBE - 订阅主题

客户端向服务端发送SUBSCRIBE报文用于创建一个或多个订阅。每个订阅注册客户端关心的一个或多个主题。为了将应用消息转发给与那些订阅匹配的主题&＃xff0c;服务端发送PUBLISH报文给客户端。SUBSCRIBE报文也(为每个订阅)指定了最大的QoS等级&＃xff0c;服务端根据这个发送应用消息给客户端。消息报文如下所示&＃xff1a;

服务端收到客户端发送的一个SUBSCRIBE报文时&＃xff0c;必须使用SUBACK报文响应。SUBACK报文必须和等待确认的SUBSCRIBE报文有相同的报文标识符。允许服务端在发送SUBACK报文之前就开始发送与订阅匹配的PUBLISH报文。如果服务端收到一个SUBSCRIBE报文&＃xff0c;报文的主题过滤器与一个现存订阅的主题过滤器相同&＃xff0c;那么必须使用新的订阅彻底替换现存的订阅。新订阅的主题过滤器和之前订阅的相同&＃xff0c;但是它的最大QoS值可以不同。与这个主题过滤器匹配的任何现存的保留消息必须被重发&＃xff0c;但是发布流程不能中断。如果主题过滤器不同于任何现存订阅的过滤器&＃xff0c;服务端会创建一个新的订阅并发送所有匹配的保留消息。如果服务端收到包含多个主题过滤器的SUBSCRIBE报文&＃xff0c;它必须如同收到了一系列的多个SUBSCRIBE报文一样处理那个&＃xff0c;除了需要将它们的响应合并到一个单独的SUBACK报文发送

DISCONNECT –断开连接

DISCONNECT报文是客户端发给服务端的最后一个控制报文。表示客户端正常断开连接。DISCONNECT报文格式如下&＃xff1a;

服务端必须验证所有的保留位都被设置为0&＃xff0c;如果它们不为0必须断开连接。DISCONNECT报文没有可变报头&＃xff0c;没有有效载荷。客户端发送DISCONNECT报文之后&＃xff0c;必须关闭网络连接&＃xff0c;不能通过那个网络连接再发送任何控制报文。服务端在收到DISCONNECT报文时&＃xff0c;必须丢弃任何与当前连接关联的未发布的遗嘱消息&＃xff0c;关闭网络连接。

MQTT数据包格式

设备通过CONNECT连接到服务端以后&＃xff0c;设备可以发布消息到服务端&＃xff0c;消息体类容具体格式如下图所示&＃xff1a;

通讯包通过MQTT携带JSON数据的方式进行传输。

JSON数据文本采用“UTF-8” 的编码方式。

JSON数据文本压缩采用Zlib库压缩。

简单模型的定义

设备基本信息JSON描述&＃xff1a;

设备属性信息JSON描述&＃xff1a;

设备报警信息JSON描述&＃xff1a;

其中Json数据包中“实际数据”指具体设备采集值&＃xff0c;如能耗监控系统中&＃xff0c;BMS数据格式如下所示&＃xff1a;

复杂模型的定义&＃xff1a;