MQTT 和 CoAP

MQTT 和 CoAP 

来源 https://zhuanlan.zhihu.com/p/242308137

 

一 、起源

随着越来越多的人通过PC、手机等设备相互连接，现代互联网蓬勃发展使得人们的生活发生了翻天覆地的变化。很多人预测将会有更多其他的设备相互连接，这些设备的数量将远远超过人类的数量，到时候形成的网络将是现有网络的N个量级，这个网络带给世界的变化将是无法估量的。
不像人接入互联网的简单方便，由于物联网设备大多都是资源限制型的，有限的CPU、RAM、Flash、网络宽带等。对于这类设备来说，想要直接使用现有网络的TCP和HTTP来实现设备实现信息交换是不现实的。于是为了让这部分设备能够顺利接入网络，CoAP协议就被设计出来了。

二 、概念

CoAP约束应用协议（Constrained Application Protocol）是一种专用于受限设备的Internet应用协议，如RFC 7252所定义，它使那些被称为“节点”的受约束设备能够使用类似的协议与更广泛的Internet进行通信。CoAP被设计用于同一受限网络（例如，低功耗、有损网络）上的设备之间、设备和因特网上的一般节点之间以及由因特网连接的不同受限网络上的设备之间使用。CoAP也被用于其他机制，如移动通信网络上的SMS。

简言之，CoAP是受约束设备的专用Internet应用程序协议。

三 、特点

1基于消息模型，定义了4个消息类型，以消息为数据通信载体，通过交换网络消息来实现设备间数据通信
2基于请求/响应模型 ,对CoAP Server云端设备资源操作都是通过请求与响应机制来完成，类似HTTP，设备端可通过4个请求方法（GET, PUT, POST, DELETE）对服务器端资源进行操作。 请求与响应的数据包都是放在CoAP消息里面进行传输的
3基于消息的双向通信（M2M），CoAP Client与CoAP server双方都可以独立向对方发送请求.双方可当client或者server角色
轻量最小长度仅为4B
支持可靠传输 ,数据重传，块传输。 确保数据可靠到达。
支持IP多播 , 即可以同时向多个设备发送请求（比如CoAP client搜索CoAP Server）
低功耗 ,非长连接通信
支持受限设备
支持观察模式
支持异步通信
.....

协议内容:CoAP是一个完整的二进制应用层协议，消息格式紧凑，默认运行在UDP上。

四 、区别于其他物联网协议(HTTP、CoAP、MQTT)

CoAP协议的设计参考了HTTP，CoAP和MQTT都是行之有效的物联网协议，一下为它们之间的异同。

HTTP和CoAP

HTTP代表超文本传输协议，CoAP代表约束应用协议;
HTTP协议的传输层采用了TCP，CoAP协议的传输层使用UDP;
CoAP协议是HTTP协议的简化版;
CoAP协议和HTTP协议一样使用请求/响应模型，拥有相同的方法;
CoAP开销更低，并支持多播;
CoAP专为资源构成应用而设计，如:IoT/WSN/M2M等...

CoAP和MQTT

MQTT协议使用发布/订阅模型，CoAP协议使用请求/响应模型;
MQTT是长连接，CoAP协议是无连接;
MQTT通过中间代理传递消息的多对多协议，CoAP协议是Server和Client之间消息传递的单对单协议;
MQTT不支持带有类型或者其它帮助Clients理解的标签消息，CoAP内置内容协商和发现支持，允许设备彼此窥测以找到交换数据的方式。

五 、详解CoAP协议

1数据包格式

(2位的版本编号一般区固定值0b01;2位的报文类型;4位的标签长度指示;8位的准则;16位的报文序号;32位标签;32位的选项;8位的分隔符;24位的负载)

2消息模型

COAP协议通信是通过在UDP上传输消息类完成。UDP比作公路话，消息就是公路上汽车。
COAP定义了4种类型消息，来实现设备端与云端之间双向通信
1. 需要确认消息 CON
2. 不需要确认消息 NON （适用于消息会重复频繁的发送，丢掉消息不对业务产生影响）
3. 确认应答消息 ACK
4. 复位消息 RST
基于4种消息类型，可以实现2种传输质量。即可靠消息传输 与 不可靠消息传输。

#####怎么是可靠消息传输？

主要是通过确认及重传机制来实现的，客户端发送消息后，需要等待服务器收到通知， 如果在规定时间内，没有收到需要重新发送数据。 可靠传输是基于CON消息传输的，服务器端收到CON类型的消息后，需要返回ACK消息，客户端到在指定时间ACK_TIMEOUT内收到ACK消息后，才代表这个消息以可靠到服务器端。

#####怎么是不可靠消息传输？

客户端只管发送消息， 不管服务器端有没有收到，因此可能存在丢包。不可靠传输是基于NON消息传输的。服务器端收到NON类型的消息后，不用回复ACK消息。

3 资源请求/响应模型 Requests/Responses

对于物联网，服务器上的资源可以简单的认为是物联网设备的实时运行影子， 通过访问服务器上资源就可以实现与设备间数据的交互。 上面谈到的消息模型比如汽车话， 资源请求及响应好比汽车上货物。 资源请求及响应内容最终会被放在CoAP消息包里面。CoAP请求与响应，类似HTTP，且根据RESTful架构设计的。 CoAP客户端发出请求，CoAP服务端进行请求处理然后发送响应。
COAP 请求Request方法： 请求方法与HTTP协议类似，有4个。
GET, PUT, POST, DELETE， 所有的请求方法都会放在CoAP CON/NON消息里面进行传输。
COAP 请求响应Response代码： 响应内容也与HTTP协议类似。 主要有如下3类：
Success 2.xx 代表客户端请求被成功接收并被成功处理
Client Error 4.xx 代表客户端请求有错误，比如参数错误等
Server Error 5.xx 代表服务器在执行客户端请求时出错。
所有的请求服务器响应可以放在CoAP CON/NON/ACK消息里面进行传输。针对CoAP 带CON消息请求，响应如果快速处理完（有些请求的处理需要耗时多，服务器无法立即响应），则可直接放在ACK消息包里面返回。对于无法立即响应的，服务器带资源ready后，会单独发一个响应消息包给客户端
服务器上可访问资源统一用URL来定位（比如/deviceID/temp 访问某个设备的温度信息）。客户端通过某个资源的URL来访问服务器具体资源，通过4个请求方法（GET,PUT,POST,DELETE）完成对服务器上资源增删改查操作。
举个例子：
比如某个设备需要从服务器端查询当前温度信息。
请求消息（CON）： GET /temperature , 请求内容会被包在CON消息里面
响应消息 (ACK)： 2.05 Content “22.5 C” ，响应内容会被放在ACK消息里面

 

MQTT 和 COAP 协议的区别

来源 https://zhuanlan.zhihu.com/p/153431271

之前我们说过，常见的IoT物联网通信协议中，HTTP和XMPP这两种协议网络开销较大，MQTT和CoAP则更适合物联网受限环境中设备的通信。

MQTT和CoAP是针对小设备最有前景的两种协议。

今天我们来详细区分下这两种协议。

首先，MQTT和CoAP都比HTTP更适合于受限环境，都可以提供异步传输机制，都可以在IP上运行，都是开放标准，且都有很多种实现方式。

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

 

MQTT

之前我们有简答介绍过，MQTT为轻量M2M通讯设计的一种发布/订阅消息协议，起初由IBM研发，现在是一种开放标准。（详细内容可以到https://zhuanlan.zhihu.com/p/152195617 去了解）

从协议架构上来看，MQTT是客户端/服务器模型，其中每一个传感器为一个客户端，通过TCP连接到服务器，这也称为代理。

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

每个消息发布至一个地址，称为主题。客户端也许会订阅多种主题，订阅某个主题的每一个客户端会收到所有发布到主题的消息。

举个例子说明一下，设想有一个简单的网络，有一个中间代理（TCP连接服务器）和三个客户端（三个传感器）。

三个客户端分别与代理建立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加密。

 

CoAP

CoAP是一种基于REST架构，应用于物联网的计算机协议。

架构

类似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。这些链接以应用/链接格式媒介形式，允许客户端发现提供什么样的资源，并且它们是什么媒介形式。

 

对比

MQTT和CoAP作为IoT协议应用都很广泛，但两者也有很大的区别。

MQTT是多对多通讯协议。用于在不同客户端之间通过中间代理传送消息，解耦生产者与消费者，通过使得客户端发布，让代理决定路由并且拷贝消息。

虽然MQTT支持一些持久化，但最好还是作为实时数据通讯总线使用。

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

MQTT客户端建立长连接TCP，CoAP客户端与服务器都发送与接收UDP数据包。

MQTT不提供支持消息打类型标记或者其他元数据帮助客户端理解，MQTT消息可用于任何目的，但是所有的客户端必须知道向上的数据格式以允许通讯。

而CoAP协议则恰好相反。它提供内置支持内容协商与发现，允许设备相互探测以找到交换数据的方式。

总之，两种协议各有缺点，应该根据在自己的实际情况选择合适的协议。

 

=========== End