IoT协议 MQTT Coap

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

MQTT和CoAP两者均：

开放标准；

比HTTP更适合于受限环境；

提供异步传输机制；

在IP上运行；

有很多种实现

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

MQTT

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

架构

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

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

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

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

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

发布/订阅模型允许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，相反地，提供内置支持内容协商与发现，允许设备相互探测以找到交换数据的方式。

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