物联网的三种实时协议

110 阅读 0 评论 73 点赞

我是靠谱客的博主甜蜜手链，最近开发中收集的这篇文章主要介绍物联网的三种实时协议，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

目前物闻网设备所广泛使用的三大实时协议包括：XMPP、CoAP以及MQTT。

XMPP

XMPP的全称为可扩展通讯与表示协议。这项立足于XML的TCP通信协议能够以近实时方式在两个甚至更多联网功能实体之间进行结构化数据交换。XMPP当中的现成功能包括表示信息以及联系人名单维护。尽管这两项功能最初都是针对即时通讯需求设计而成，但它们在物联网应用程序当中仍然能够起到不错的效果。鉴于其出色的开放特性并以XML为基础，XMPP已经被扩展至各类公共订阅系统当中——而这也恰好适合物联网应用的实际需求。

XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。

服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。

利用XMPP作为物联网通信协议，我们能够享受到几大突出优势:

●首先就是XMPP的分散特性。XMPP的运作方式与电子邮件比较相似，游走于由传输代理构建而成的分布式网络当中，而非高度依赖于单一中央服务器或者代理节点(CoAP与MQTT皆属于这种情况)。

●与电子邮件一样，每个人都能够轻松运行属于自己的XMPP服务器，这就使得设备制造商以及API供应方能够创建并管理自己的设备网络体系。

●而由于大家都有能力运行自己的服务器，所以出于安全考虑，我们可以在必要时利用内置TLS加密机制将该服务器隔离在企业内网的安全验证协议之下。

遗憾的是，XMPP也存在着一些弊端。其最大的问题之一就是缺少端到端加密机制。尽管在不少场景之下，这类加密机制基本算是可有可无，但归根结底大多数物联网设备仍然需要利用加密来保障安全。端到端加密机制的缺失无疑会令物联网设备制造商陷入被动当中。

XMPP的另一个问题在于不具备服务质量(简称QoS)控制。在物联网领域，确保消息交付的重要性甚至比即时通讯领域还要高。如果大家的警报系统没能切实收到相关信息并正确触发，那么接下来的后续影响可能会非常可怕。

CoAP

CoAP的全称为受限应用协议，其开发目的在于允许资源相对有限的设备利用UDP而非TCP通过互联网实现通信。开发人员可以同任意支持CoAP的设备进行交互，具体方式与采用传统REST API的设备完全一致。CoAP的主要适用场景包括低功耗传感器以及需要通过互联网加以控制的设备。

CoAP是一种简单的请求/响应协议(与REST非常相似)，且遵循传统的客户端/服务器模式。客户端可以面向资源发出GET、PUT、POST以及DELETE等请求。CoAP数据包采用位字段以最大限度提升内存利用效率，且经常将字符串映射至整数以降低数据包在设备内部以及网络中传输时所占用的带宽。除了数据包体积极度小巧之外，CoAP的另一大优势在于其采用UDP;数据报文使得CoAP能够在各类基于数据包的技术之上起效——例如短信。

所有CoAP消息皆可被标记为“确认”或者“未确认”，并作为应用层级的QoS机制。尽管SSL/TLS加密无法在UDP之上实现，但CoAP使用数据传输层安全(简称DTLS)作为替代——其可以算是TLS的TCP版本。默认加密级别相当于一条3072位的RSA密钥。尽管包含这些强大的安全保障能力，CoAP仍然能够运行在内存仅为10 KB的微控制器当中。

CoAP的弊端之一在于，它属于一对一协议。尽管我们可以通过扩展方式实现组广播，但这种广播能力并非原生存在。除此之外，CoAP的另一大缺陷在于不提供公共订阅消息队列。

CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型:
●CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。
●NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。
●ACK——应答消息，接受到CON消息的响应。
●RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。

CoAP消息格式使用简单的二进制格式，最小为4个字节。

一个消息=固定长度的头部header + 可选个数的option + 负载payload。Payload的长度根据数据报长度来计算。

MQTT

MQTT的全称为消息队列遥测传输，这是一种公共订阅消息收发协议。与CoAP类似，它在设计当中同样考虑到运行设备资源有限的状况。MQTT采用轻量级数据包结构设计，旨在最大程度节约内存使用量及运行功耗。联网设备以订阅方式监听托管在MQTT代理端的话题。每一次在其它设备或者服务向该话题发送数据，所有参与订阅的设备都将自动获取到这一更新信息。

MQTT的最大优势在于其公共订阅消息队列机制以及多对多广播能力。有了指向MQTT代理端的长效TCP连接的支持，以有限带宽进行消息收发变得简单而轻松。

MQTT的短板在于，其始终存在的连接限制了设备进入休眠状态的整体时长。如果相关设备在运行中多数处于休眠状态，我们不妨优先选择另一种MQTT协议——MQTT-S，其利用UDP取代原始协议中的TCP。

MQTT的另一大弊端是缺少基础协议层面的加密机制。MQTT被设计为一种轻量化协议，而内置加密的方式会给传输连接增加很大负担。虽然我们也能够在应用程序层级添加定制化安全机制，但这可能需要进行大量的调整工作。

MQTT协议的优势是可以支持所有平台，它几乎可以把所有的联网物品和互联网连接起来。

它具有以下主要的几项特性：

1、使用发布/订阅消息模式，提供一对多的消息发布和应用程序之间的解耦；

2、消息传输不需要知道负载内容；

3、使用 TCP/IP 提供网络连接；

4、有三种消息发布的服务质量：

QoS 0：“最多一次”，消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如，这个等级可用于环境传感器数据，单次的数据丢失没关系，因为不久后还会有第二次发送。
QoS 1：“至少一次”，确保消息可以到达，但消息可能会重复。
QoS 2：“只有一次”，确保消息只到达一次。例如，这个等级可用在一个计费系统中，这里如果消息重复或丢失会导致不正确的收费。

5、小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量；

6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制；

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

CoAP与MQTT的区别

MQTT和CoAP都是行之有效的物联网协议，但两者还是有很大区别的，比如MQTT协议是基于TCP，而CoAP协议是基于UDP。从应用方向来分析，主要区别有以下几点：

1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息，也就是说所有MQTT Clients必须要知道消息格式。而CoAP协议则相反，因为CoAP内置发现支持和内容协商，这样便能允许设备相互窥测以找到数据交换的方式。

2、MQTT是长连接而CoAP是无连接。MQTT Clients与Broker之间保持TCP长连接，这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话，那就需要采取一些NAT穿透性手段。

3、MQTT是多个客户端通过中央代理进行消息传递的多对多协议。它主要通过让客户端发布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相当于消息传递的实时通讯总线。CoAP基本上就是一个在Server和Client之间传递状态信息的单对单协议。

HTTP与CoAP的区别

CoAP是6LowPAN协议栈中的应用层协议，基于REST（表述性状态传递）架构风格，支持与REST进行交互。通常用户可以像使用HTTP协议一样用CoAP协议来访问物联网设备。而且CoAP消息格式使用简单的二进制格式，最小为4个字节。HTTP使用报文格式对于嵌入式设备来说需要传输数据太多，太重，不够灵活。

在大多数情况下，我们都能够利用 Firebase、Socket.io或者Built.io构建起自己的物联网平台，而且这种方式也能为大家节省下大量开发时间。