IoT -- (六) MQTT和CoAP对比分析

Published on with 0 views

IoT物联网需要标准协议,针对小设备最有前景的两种是MQTT和CoAP。

MQTT和CoAP两者均:

开放标准;

比HTTP更适合于受限环境;

提供异步传输机制;

在IP上运行;

有很多种实现

MQTT在传输模式上更为灵活,对二进制数据而言就像是管道,CoAP为面向网络的设计。

MQTT
为轻量M2M通讯设计的一种发布/订阅消息协议,起初由IBM研发,现在是一种开放标准。

架构
客户端/服务器模型,其中每一个传感器为一个客户端,通过TCP连接到服务器,也称为代理。

MQTT以消息为导向,每个消息是具体的一组数据,对代理是透明的。

每个消息发布至一个地址,称为主题,客户端也许会订阅多种主题,订阅某个主题的每一个客户端会收到所有发布到主题的消息。举个例子说明,设想一个简单的网络,有一个中间代理和三个客户端。

所有三个客户端与代理建立TCP连接,客户端B、C订阅温度主题

01.png

稍后,客户端A给温度主题发布了一个值22.5,代理转发消息给所有订阅客户端。

02.png

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

主题匹配
MQTT中,主题是层次结构的,像文件系统(例如:kitchen/oven/temperature)。当注册订阅时允许通配符,但不是发布时,允许整个层次结构被客户端观察。

通配符+匹配任意单个目录名称,#匹配任意数量任意名称目录。

例如:主题kitchen/+/temperature可以匹配kitchen/foo/temperature,但是不能匹配

kitchen/foo/bar/temperature,而kitchen/# 可以匹配 kitchen/fridge/compressor/valve1/temperature。

应用级QoS
支持三种服务质量等级:触发而遗忘、至少传送一次、仅仅传送一次。

遗愿遗嘱
MQTT客户端可以注册一个典型的遗愿遗嘱消息,如果它们断开连接,由代理发送。这些消息可以用于向订阅者发出信号,当设备断开连接时。

持久化
MQTT支持在代理上存储持久化消息,当发布消息时,客户端也许会要求代理能够持久化消息。只有最近的持久消息会被存储。当客户端订阅一个主题时,任何持久化消息会被发送至客户端。

不像消息队列,MQTT代理不允许持久化消息在服务器内部备用。

安全
MQTT代理也许会要求用户名、密码认证,为确保隐私,TCP连接也许会用SSL/TLS加密。

MQTT-SN
虽然MQTT设计为轻量的,但是对于受限设备来说,有两个缺点。

每一个MQTT客户端必须支持TCP,任何时候都要求保持连接到代理。对于丢包很严重或者计算资源稀缺的环境来说,这会是一个问题。

MQTT主题名称通常是长字符串,使得其对802.15.4不切实际。

MQTT-SN协议解决这些问题,定义MQTT UDP映射,增加代理支持主题名称索引。

CoAP
来自CoRE(受限资源环境)IETF 组的受限应用协议
架构
类似HTTP,CoAP是文本输出协议,但是不像HTTP,CoAP为受限制的设备设计。
CoAP数据包比HTTP TCP流小得多,比特域与从字符串映射到整型广泛运用以节省空间。数据包易于生成,可以原位解析,不用消耗受限制设备内的额外RAM。

CoAP运行在UDP上,而不是TCP。客户端与服务器通过无连接的数据报进行通讯,在应用栈内实现重传与重排序。无需TCP也许会使得小型微处理器全部IP网络化,CoAP允许使用UDP广播与多播用于地址。

CoAP遵循客户端/服务器模型,客户端向服务器请求,服务器回送响应,客户端可以GET、PUT、POST和DELETE资源。

CoAP用于通过简单代理与HTTP、RESTFUL网络交互。

因为CoAP基于数据报文,也许会用于SMS或者其他基于分组的通讯协议之上。

应用级QoS
请求与响应也许会被标记为可确认的或者非确认的,可确认的消息必须由接收方通过ACK包进行确认。

非确认的消息是触发而忘记的。

内容协商
像HTTP,CoAP支持内容协商,客户端使用Accept选项表达倾向的资源表示,服务器回复Content-Type选项告知客户端它们接收的东西。和HTTP一样,这允许客户端与服务器独立演进,增加新的表达方式,而互不影响。

CoAP请求也许会使用查询字符串形式如?a=b&c=d,这些可以用于给客户端提供搜索、分页与其他特性。

安全
因为CoAP建立在UDP而不是TCP之上,SSL/TLS不可用于提供安全性。DTLS数据报传输层安全提供了与TLS同样的保证机制,但是针对UDP之上数据传输。通常来说,具备DTLS能力的CoAP设备支持RSA、AES或者ECC、AES。

观察
CoAP拓展了HTTP请求模型,有能力观察资源。当观察标记在CoAP GET请求之上设定时,服务器会继续应答在初始文档已经传输过后。这使得服务器能够将状态变化发生时流向客户端。两边一方结束会取消观察。

资源发现
CoAP为资源发现定义标准机制,服务端提供资源列表(同时包括相关的元数据)在/.well-known/core。这些链接以应用/链接格式媒介形式,允许客户端发现提供什么样的资源,并且它们是什么媒介形式。

NAT问题
CoAP, 传感器节点一般是一个服务器,而不是一个客户端(虽然有可能两者都是)。传感器(或者)提供客户端可以访问的资源,或者改变传感器状态。

虽然CoAP传感器是服务器,它们必须能够接收数据包。NAT后合理运行,设备也许会先发送一个请求,像在LWM2M中做的,允许路由器关联两者。虽然CoAP不需要IPV6,在设备直接路由的IP环境内最易于使用。

对比
MQTT和CoAP作为IoT协议都很有用,但是也有重要的区别。

MQTT是多对多通讯协议用于在不同客户端之间通过中间代理传送消息,解耦生产者与消费者,通过使得客户端发布,让代理决定路由并且拷贝消息。虽然MQTT支持一些持久化,最好还是作为实时数据通讯总线。

CoAP主要是一个点对点协议,用于在客户端与服务器之间传输状态信息。虽然支持观察资源,CoAP最好适合状态传输模型,不是完全基于事件。

MQTT客户端建立长连接TCP,这通常表示没有问题,CoAP客户端与服务器都发送与接收UDP数据包,在NAT环境中,隧道或者端口转发可以用于允许CoAP,或者像LWM2M,设备也许会先初始化前端连接。

MQTT不提供支持消息打类型标记或者其他元数据帮助客户端理解,MQTT消息可用于任何目的,但是所有的客户端必须知道向上的数据格式以允许通讯,CoAP,相反地,提供内置支持内容协商与发现,允许设备相互探测以找到交换数据的方式。

两种协议各有优缺点,选择合适的取决于自己的应用

说你懂得生之微末,我便做了这壮大与你看,你说再热闹也终需离散,我便做了这一辈子与你看,你说冷暖自知,我便做了这冬花夏雪与你看,你说恋恋旧日好时光,我便做了这描金绣凤的浮世绘与你看。你说应愁高处不胜寒,我便拱手河山,讨你欢。
Responses