MQTT、HTTP 、XMPP 、 COAP 与IOT物联网应用

贴了一篇博文 ，写的不错https://blog.csdn.net/u010648018/article/details/80963913

1.物联网的组成
生活中常见的共享单车、智能手环、智能家居等都是物联网的实际引用。物联网最初在
1999年提出：即通过射频识别（ RFID）、 红外感应器、全球定位系统、激光扫描器、气体感应
器等信息传感设备，按约定的协议，把任何物品与互联网连接起来，进行信息交换和通讯，以
实现智能化识别、定位、跟踪、监控和管理的一种网络。简而言之，物联网就是“物物相连的

互联网”。
物联网组成一般包括：
(1)设备 通常含有各种传感器，如图像传感器、光学传感器、温度传感器、湿度传感器、 加速
度传感器、磁场传感器等。
(2)网络 近距离通信(蓝牙、 RFID、 NFC)，远距离蜂窝通信(GSM、 WCDMA、 LTE、 NB-IOT)，远距
离非蜂窝通信(WiFi、 ZigBee)，有线通信。
(3)物联网服务 数据的接收与发送，数据的处理与保存。

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进行寻址(如
[email protected])

适用范围：即时通信的应用程序，还能用在网络管理、 协同工具、档案共享、游戏、远端系统监控等。

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协议最初由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工作模式

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，但订阅者依然可以收到消息。