物联网传输协议 - CoAP_专栏

物联网传输协议 - CoAP

什么是CoAP

CoAP（Constrained Application Protocol）是一种简化压缩的 HTTP RESTful API 协议。其目标是实现在资源受限 ( 低能源、网络环境差 ) 的环境下的应用（例如M2M应用）进行通信。

什么是M2M 应用？

M2M （ Machine to Machine ）是指通过一些移动通信对设备进行有效控制。例如移动监控、移动物流管理等。

CoAP 的特点

在受限制的环境下可以满足 M2M 所需要的Web协议环境。
可选转为可靠的 UDP 进行绑定，支持单播和多播。
异步交换信息。
简单的报文头部。
URI 和内容类型（ Content-type ）的支持。
简单的代理和缓存功能。
可通过构建代理以提供 HTTP 统一方式来访问的接口。
绑定数据包传输层安全性协议。

名词解释：

单播一个节点只与一个节点进行通信。

类似你和你朋友聊天，你一句他一句。
多播一个节点与多个节点进行通信。

例如网络视频会议，网络直播。一个人讲，多个人看。

CoAP 内部详解

CoAP 是一个很像 HTTP Client/Server 模型的协议。可以简单将CoAP 分为两层。

UDP 层：基于UDP 进行消息传输。
CoAP 消息传递层：用于处理UDP 和异步交互。

CoAP 的URI

CoAP 的 URI 也是类似 HTTP 。使用 "coap" ( 类似 http )、 "coaps"（类似 https ）来区分是否为 CoAP 服务。

官方提醒：随着时间的流逝，其URI的格式已经十分的复杂。需要仔细检查。

Implementation Note: Unfortunately, over time, the URI format has acquired significant complexity. Implementers are encouraged to examine [RFC3986] closely. For example, the ABNF for IPv6 addresses is more complicated than maybe expected. Also, implementers should take care to perform the processing of percent-decoding or percent-encoding exactly once on the way from a URI to its decoded components or back. Percent-encoding is crucial for data transparency but may lead to unusual results such as a slash character in a path component.

CoAP URI 格式：

coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]

注：[] 内为可选值

与 HTTP 不同，CoAP 协议的默认端口为：5683。

CoAPs URI 格式：

coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty [ "?" query ]

注：[] 内为可选值

与 HTTPS 不同，CoAPS 协议的默认端口为：5684。

关于URI的一些规范

CoAP 协议后的参数和 HTTP 相同，即为 key=value 键值对，并用 (U+0026 AMPERSAND "&") 进行分隔。
COAP 协议规定如何端口等于协议的默认端口，则通常取消其端口展示。

如： coap：//example.com：5683 /〜sensors / temp.xml

等于：coap：//example.com/〜sensors / temp.xml

CoAP 内的路径如果不填，则默认为绝对路径 "/"
Host 不区分大小写。
除了 "保留的字符集" 以外，其他的字符等同于其百分比的编码。

下面三个链接意义相等。

coap：//example.com：5683 /〜sensors / temp.xml

coap：//EXAMPLE.com/%7Esensors/temp.xml

coap：//EXAMPLE.com：/%7esensors/temp.xml

消息类型

CoAP 基于UDP 进行信息交换。每条消息包含一个消息ID，用于检测重复和可靠性（可选）。CoAP 协议规定共有四种消息类型：

CON -- 指定需要被确定（ ACK ）的请求。如果对方返回则会进行重试。（用以要求可靠性的请求）
ACK -- 对CON的确认应答。
RST -- 复位消息。如果接收端不可处理或者错误则返回 RST 消息。

NON -- 指定不需要被确定的请求。（用以不要求可靠性的请求）

Request/Response 模型

简单通信

如果客户端和服务端之间通信可以立马返回相关的响应，则其称其为（ Piggybacked response ），如下图：

异步通信

如果服务端不能理解返回客户端所需要的响应，则会先返回一个空的ACK 报文，当服务端处理完成后，将会重新发送给客户端一个CON 报文进行把刚才响应进行传输。

不可靠通信

基于 UDP 的 CoAP 可以发送不可靠的通信包。经常用在检测一个实时进度，不需要对后面进行追测的数据。

请求和响应码

Coap 使用类似 HTTP 请求的 GET、PUT、POST、DELETE 方法进行通信。

虽大致相同，但也是有一些地方有较大的差异，例如 CoAP 可以支持多播的情况等，本文不展开讲解，如想深入了解可以阅读相关规范。

CoAP 消息格式

CoAP消息以简单的二进制格式编码。消息格式以固定大小的4字节报头开头。其后是可变长度的Token值，该值的长度可以在0到8个字节之间。TOKEN
之后是Type-Length-Value（TLV）格式的一系列零个或多个CoAP选项，Options 的是后面跟有一个有效载荷，占满了数据报的其余部分。

第一行的消息头，其固定长度4个字节。下面讲解其中各个字段意义：

Ver(2 bit unsigned integer) CoAP的版本号。规定为 1（二进制01 ）。
T (2 bit unsigned integer) 该消息的类型。
- 0 可确认
- 1 不可确认
- 2 确认
- 3 重置
TKL （4 bit unsigned integer）可变长度令牌的长度。
Code （8 bit unsigned integer）前3bit代表类型和后5bit表示详细信息。
Message ID (16 bit unsigned integer）用于检测消息重复和消息匹配。

CoAP 的可靠传输

既然CoAP 是基于UDP 的。那么它是如何做到可靠传输的呢？

通过在CoAP标头中将消息标记为“可确认”来启动消息的可靠传输。其主要规则如下：

可确认消息 ( CON ) 始终带有请求或响应（除非它仅用于引发复位消息，在这种情况下为空）。

收件人必须用确认消息 ( ACK ) 确认一条确认消息 ( CON )，如果收件人缺乏上下文来正确处理该消息，包括该消息为空的情况，则拒绝该消息。

如果消息格式错误。通过发送匹配的“重置”消息 ( RST )并忽略它。

确认消息 ( ACK ) 与重置消息( RST ) 必须回显可确认消息的消息ID( Message ID )，并且必须携带响应或为空。

拒绝确认或重置消息（包括确认携带带有保留类的请求或代码，或者重置消息不为空的情况）是通过无视其忽略来实现的。