• 物联网协议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,但订阅者依然可以收到消息。



  • 相关阅读:
    【Java并发编程】之十一:线程间通信中notify通知的遗漏
    【Java并发编程】之十:使用wait/notify/notifyAll实现线程间通信的几点重要说明
    【Java并发编程】之九:死锁
    【Java并发编程】之八:多线程环境中安全使用集合API
    【Java并发编程】之七:使用synchronized获取互斥锁的几点说明
    多线程开发中遇到的问题
    Linux 设置IP,gate, 以及自动获取IP的方法
    C语言实现http get请求程序
    DHCP(动态主机配置协议)工作流程
    多线程程序中死锁的分析和解决方案
  • 原文地址:https://www.cnblogs.com/birdBull/p/13931214.html
Copyright © 2020-2023  润新知