物联网协议MQTT漫谈
https://blog.csdn.net/u010648018/article/details/80963913
目录
第一部分 物联网的组成
第二部分 常见物联网通信协议比较
第三部分 MQTT协议及开源实现
第四部分 IOT架构及设备接入实践
1.物联网的组成
生活中常见的共享单车、智能手环、智能家居等都是物联网的实际引用。物联网最初在
1999年提出:即通过射频识别( RFID)、 红外感应器、全球定位系统、激光扫描器、气体感应
器等信息传感设备,按约定的协议,把任何物品与互联网连接起来,进行信息交换和通讯,以
实现智能化识别、定位、跟踪、监控和管理的一种网络。简而言之,物联网就是“物物相连的
互联网”。
物联网组成一般包括:
(1)设备 通常含有各种传感器,如图像传感器、光学传感器、温度传感器、湿度传感器、 加速
度传感器、磁场传感器等。
(2)网络 近距离通信(蓝牙、 RFID、 NFC),远距离蜂窝通信(GSM、 WCDMA、 LTE、 NB-IOT),远距
离非蜂窝通信(WiFi、 ZigBee),有线通信。
(3)物联网服务 数据的接收与发送,数据的处理与保存。
以膜拜单车开锁流程为例,膜拜智能锁开锁流程:
1.打开膜拜APP扫描单车二维码 2.识别二维码后自动向云端发送解锁请求 3.云端系统识别用户信息、校验单车情况等 4.业务处理成功后云端系统向智能锁发送解锁 5.智能锁执行开锁命令,并上报开锁结果 6.膜拜APP开锁进度更新,并开始计费 7.单车定时上报位置信息, APP端更新行驶 | ![]() |
2.常见物联网通信协议比较
IOT网络中,通常设备和网络是受限的。因此在选择数据通信协议时需要考虑设备的计算、
存储、能耗,窄带宽和网络不稳定等因素。常见的数据通信协议有: HTTP、 XMPP、 COAP、 MQTT。
2.1.HTTP
自1990年出现的HTTP协议作为web的标准协议已被广泛使用,在物联网中同样可以采用HTTP协议。例如手机、 PC等终端设备。但是作为适应浏览器场景的HTTP协议,并不适用于物联网的其他备。
适用范围:开放物联网中资源,实现服务被其他应用所调用。
优势:
1.简单的工作模式,请求/响应
2.完整的方法定义。
3.合理的状态码设计
4.友好的媒体类型支持。文本、图片、视频
缺点:
1.单向传输,可以通过客户端轮询实现类似推送效果或者HTTP 2.0。
2.安全性不高, HTTP是明文协议,可以使用HTTPS传输
3.HTTP是文本协议,冗长的协议头部,对于运算、存储、带宽资源受限的设备来说开销大。
2.2.XMPP(Extensible Messaging and Presence Protocol可扩展消息与存在协议)
XMPP的前身是Jabber开源社区于1999年开发的Jabber协议, 用于即时通信、状态信息(比如即时通信客户端显示用户在线、忙碌、视频中等)、通讯录管理。通过类似邮箱地址的JID进行寻址(如
zhangsan@jabber.com)
适用范围:即时通信的应用程序,还能用在网络管理、 协同工具、档案共享、游戏、远端系统监控等。
优势: 1.去中心化,类似于邮件网络架构。 2.安全,支持SASL安全认证和TLS加密。 3.灵活,基于XML的数据格式可以自定义功能。 4.应用广泛,众多的客户端、服务端实现。 缺点: 1.不支持服务质量(Qos) 2.基于文本协议的通信带来高的网络负载 3.二进制数据传输支持较差 | ![]() |
2.3.CoAP (Constrained Application Protocol 受限的应用协议)
CoAP是为了让低功耗受限设备可以接入互联网,由IETF组织制定的,它借鉴了HTTP大量成功经验,同样使用请求/响应工作模式。
适用范围:适用于局域网环境下一对一M2M通信。
优势:
1.采用和HTTP相似语义的请求和响应码,并使用二进制报文减小了报文大小
2.传输层基于UDP协议,比TCP数据包小,并不需要建立连接带来握手的开销
3.资源发现支持,通过观察者模式实现类似发布/订阅效果
缺点:
1.基于UDP的不可靠传输,但通过四种报文类型的组合及重传机制提高传输的可靠性。
2.基于UDP的无连接传输,不利于不同网络间消息的回传。
2.4.MQTT (Message Queuing Telemetry Transport 消息队列遥测传输)
MQTT协议最初由IBM公司于1999年开发,用于将石油管道上的传感器与卫星相连接。 2014年正式成为OASIS开放标准。MQTT使用类似MQ常用的发布/订阅模式,起到应用程序解耦,异步消息,削峰填谷的作用。很多MQ中间件也支持MQTT协议,比如ActiveMQ、 RabbitMQ、 HiveMQ、 WebSphereMQ等。
适用范围:在低带宽、不可靠的网络下提供基于云平台的远程设备的数据传输和监控。
优势:
1.使用发布/订阅模式,提供一对多的消息发布,使消息发送者和接收者在时间和空间上解耦。
2.二进制协议, 网络传输开销非常小(固定头部是2字节)。
3.灵活的Topic订阅、 Qos、临终遗言等特性。
缺点:
1.集中化部署,服务端压力大,需要考虑流程控制及高可用。
2.对于请求/响应模式的支持需要在应用层根据消息ID做发布主题和订阅主题之间的关联
总体来看, HTTP和XMPP网络开销大, CoAP和MQTT更适合物联网受限环境中设备的通信。从市场应用层面看, MQTT发展相对成熟、应用相对广泛,也比较适合设备的远程监控与管理。
3. MQTT协议简介及开源实现
MQTT是基于发布订阅模式的,有主题过滤器、 Qos保证、临终遗言、 Session持久化
等特性,下面我们一起通过报文来了解一下吧。
3.1.MQTT工作模式
3.2.MQTT协议报文组成(基于v3.1.1)
可变头和消息体根据不同报文类型而不同, 可以看出:
1.MQTT协议最小报文仅有2个字节(只有固定头且剩余长度为1个字节),如心跳报文PINGREQ、PINGRESP
2.报文类型最多2^4=16。目前共有14种报文类型, 2个保留类型。下面着重看下连接、发布、订阅相关报文。
3.3.CONNECT报文整体结构
CONNECT报文的可变头中存在以下非常重要的标志位。
1.Clean Session
作用:该标志用于指定客户端连接到服务端后,是否清除之前持久化的session信息(如果存在),并且当连接断开后是否持久化本次会话的session信息。
场景:由于网络等原因造成设备临时下线,当设备重新连接服务端时,如果上次连接Clean
Session=1则之前订阅的主题及设备下线期间发送的消息就会丢失,如果需要设备下线期间消息
不丢失可以设置Clean Session=0。
Session中存储信息有哪些?
1.ClientId用于识别客户端
2.客户端的订阅的主题
3.已经发送或正在发送到客户端的Qos1和Qos2消息,还没有完全确认(发给订阅者)
4.已经接收到客户端发送的Qos2消息,还没有完全确认(接收发布者)
5.在发送中的Qos0消息(可选)
2.Will Flag
作用:客户端连接异常断开时触发服务端向订阅客户端发送消息通知。
场景:由于网络异常导致客户端下线,可使用临终遗嘱通知订阅了该遗嘱topic的客户端,从而进行应对处理。
当Will Flag=1,连接建立后,服务端会保存Will Message。 当网络连接关闭后(除服务端接收到DISCONNECT报文外),遗嘱消息会被发布。服务端发布遗嘱消息时按照Will Qos和Will Retain(是否保留消息)标志位发布。
3.Will Qos(服务质量)
MQTT支持三种服务质量等级:
Qos0:至多一次交付消息。接收方能否接收到消息完全依赖于网络传输情况。一般用于实时性较高的情况下,如传感器发送当前温度数据,如果丢失一次数据也没有影响,因为马上会有最新的数据到来。
Qos1:至少一次交付消息。接收方可能接收到重复消息。应用于确保消息到达,并有幂等处理的系统。
Qos2:准确一次交付消息。接收方只能接收到一次消息。应用于比较严格的如计费系统,重复或者丢失数据都会导致不正确的结果。
需要注意的是Qos保证不是端到端的,而是客户端和服务器之间的。订阅者收到MQTT消息
的Qos级别,取决于发布消息的Qos和订阅主题的Qos,当二者不同是,会产生降级,以最低的
Qos级别为准。
4.Retain
作用:保存客户端最新发布的消息。
场景:通常情况下,订阅者需要在发布者发布消息前订阅。使用Retain标志位可以在服务端保
留最新的消息,当新的客户端订阅相关主题时可以立即收到该主题上的最新消息。
3.4.PUBLISH报文整体结构
1.PUBLISH报文固定头中有三个重要的标志位,其中Qos、 RETAIN和前面介绍的CONNECT报文可变头中标志位语义相同。
DUP flag是报文重传标志,在Qos1和Qos2的报文重传过程中会把DUP flag置为1。
2.不同Qos报文发送的过程
(1)Qos0 消息发布流
(2)Qos1 消息发布流
(3)Qos2 消息发布流
3.5.SUBSCRIBE报文整体结构
订阅和发布都是针对topic的, topic根据”/” 分隔为不同的层级。一个PUBLISH报文中只能有一个topic,一个SUBCRIBE报文中可以有多个topic filter。 topic filter中可以使用通配符。
多层级通配符#
(1)可以匹配父层级主题和任意数量子层级主题
(2)必须是主题过滤器的最后一个字符
单层级通配符-
(1)匹配一个层级
(2)可以出现在主题过滤器的任意位置,也可以和#搭配使用
特殊情况: 以#或+通配符开头的topic filter不匹配以$开头的主题。通常以$SYS/前缀的主题用于获取服务器相关的信息或者是控制API
3.6.MQTT的开源实现
1.客户端 Eclipse Paho 支持Java、 C/C++、 Python、 Go、 JavaScript、 Rust
2.服务端 mosquitto、 emqttd、 Apache ActiveMQ、 RabbitMQ
4.IOT架构及设备接入实践
4.1.IOT架构
目前,业界像BAT公司都提供了基于自家云服务的IOT接入整套解决方案,如设备接入、通
信与管理,安全认证,设备影子,消息存储与分析计算等。大体架构如下:
4.1.设备影子
在IOT平台中除了提供MQTT服务端外,还有一个重要概念——设备影子。设备影子是一个
JSON文档,用于存储设备上报状态、应用程序期望状态信息。
场景1:设备在不稳定网络中频繁上下线,应用程序可能无法获取到设备最新状态信息。
设备在状态变化时存储最新状态信息到设备影子中,则应用程序从影子中获取设备状态即可。
场景2:应用程序多次请求获取设备状态,增加了设备的负载。使用设备影子减小设备的
压力。
场景3:应用程序发送指令给设备,由于网络不稳定,指令可能无法到达。若使用Qos1或2
则增加服务端的压力,将指令加时间戳存在影子中,设备上线时根据时间戳来判断是否执行指
令。
4.2.IOT设备接入实践
百度天工、阿里物接入等
4.3.Clean Session 实践
1.客户端连接时不勾选CleanSession,则CleanSession=false(0)
2.这里使用emq broker,可以看到,服务端有一个session
3.断开客户端连接(如下图),发现服务端session还存在(如上图所示), subscription也存在
4.再打开一个客户端作为发布者,向/temperature主题发布消息;订阅者客户端重新连接后,打开订阅者log日志,可以看虽然没有重新订阅/temperature,但订阅者依然可以收到消息。