物联网协议漫谈 07

前段时间，写完 CoAP 协议分享文章的上半部分之后，一直没来得及写下半部分，今天就来补完。主要内容是关于CoAP 协议具体内容。

1CoAP 协议具体内容

1.1 CoAP 的消息类型

CoAP 采用与 HTTP 协议相同的请求响应工作模式。CoAP 协议共有 4 中不同的消息类型。

（1）CON：需要被确认的请求，如果 CON 请求被发送，那么对方必须做出响应。

（2）NON：不需要被确认的请求，如果 NON 请求被发送，那么对方不必做出回应。

（3）ACK：应答消息，接受到 CON 消息的响应。

（4）RST：复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。

1.2 CoAP 消息结构

一个 CoAP 消息最小为 4 个字节，以下是 CoAP 协议消息结构描述：

（1）Ver：即版本 Version，类似于IPv6和IPv6，仅仅是一个版本号。

（2）T：即消息类型 Message Type，包括 CON，NON，ACK，RST 这四种。

（3）TKL：即标记长度Token Length。

（4）Code：即方法码，例如请求中的四种方法 ——GET，POST，PUT 和 DELETE。Code 在 CoAP 请求报文和响应报文中具有不同的表现形式，Code 占一个字节，它被分成了两部分，前 3 位一部分，后 5 位是另一部分。

（5）Message ID：即消息 ID，每个 CoAP 消息都有一个 ID，在一次会话中 ID 总是保持不变。但在这个会话之后该 ID 会被回收利用。

（6）Token：即标记，这是消息 ID 的另一种表现。

（7）Options：即选项，CoAP 选项类似于 HTTP 的请求头，它包括 CoAP 消息本身，例如 CoAP 端口号，CoAP 主机和 CoA P查询字符串等。

（8）Payload：即负载，这是真正有用的被交互的数据。负载前面的1111 1111 Byte 是 CoAP 报文和具体负载之间的分隔符。

1.3 CoAPRequest/Response 请求与响应

1.3.1Request请求

在 CoAP 请求中，Code 被定义为 CoAP 请求方法，CoAP 协议支持的基础方法是：GET，POST，PUT 和 DELETE。

（1）GET：获取 Server 上的资源。Server 可能回 2.05 (Content) 或者 2.03 (Valid) Response Code。

（2）POST：通常用来创建新的资源或者更新资源。

— 如果资源已经被创建，Server 回 2.01 (Created) Response Code；

— 如果 POST 成功，但是 Server 没有创建资源，Server 回 2.04 (Changed) Response Code；

— 如果 POST 成功导致目标资源删除，Server 回 2.02 (Deleted) Response Code。

（3）PUT：更新 Server 上的资源。

— 如果资源存在，回 2.04(Changed) Response Code；

— 如果资源不存在，则 Server 可能会创建资源，回 2.01 (Created) Response Code。

— 如果资源不能被创建或修改，则回 Error Response。

（4）DELETE：删除 Server 上的资源。回 2.02 (Deleted) Response Code。

1.3.2 Response 响应

响应包括 Piggybacked Response, Separate Response, Non-confirmable Response 这三种类型。

（1）Piggybacked Response：这是最常用的类型，Reponse 内容直接放在 acknowledges 中。

（2）Separate Response：Server 暂时没办法直接回（可能需要更多的时间准备），直接回 Empty Acknowledgement。当 Server 准备好了，给 Client 发 Confirmable message（也可以是Non-confirmable message），最后 Client 回 Acknowledgement 。如果 Server 在回复 Clinet 之前又收到 Client 的重传，那么也回 Empty Acknowledgement。

（3）Non-confirmable Response：Client 发出 Non-confirmable message，Server 一般也回 Non-confirmable message。Spec 也提到了 Server 也可以发 Confirmable message。

当 Server 回 Separate Response 的时候，Token 和 Client 的 Request 时的 Token 是一致的，但是 Message ID 已经变掉了。

在响应中， Code 被定义为如下响应码：

（1）2.01Created

（2）2.02Deleted

（3）2.03Valid

（4）2.04Changed

（5）2.05Content。类似于 HTTP 200 OK

（6）4.00Bad Request 请求错误，服务器无法处理。类似于 HTTP 400。

（7）4.01Unauthorized 没有范围权限。类似于 HTTP 401。

（8）4.02Bad Option 请求中包含错误选项。

（9）4.03Forbidden 服务器拒绝请求。类似于 HTTP 403。

（10）4.04Not Found 服务器找不到资源。类似于 HTTP 404。

（11）4.05Method Not Allowed 非法请求方法。类似于 HTTP 405。

（12）4.06Not Acceptable 请求选项和服务器生成内容选项不一致。类似于 HTTP 406。

（13）4.12Precondition Failed 请求参数不足。类似于 HTTP 412。

（14）4.15Unsuppor Conten-Type 请求中的媒体类型不被支持。类似于 HTTP 415。

（15）5.00Internal Server Error 服务器内部错误。类似于 HTTP 500。

（16）5.01Not Implemented 服务器无法支持请求内容。类似于 HTTP 501。

（17）5.02Bad Gateway 服务器作为网关时，收到了一个错误的响应。类似于 HTTP 502。

（18）5.03Service Unavailable 服务器过载或者维护停机。类似于 HTTP 503。

（19）5.04Gateway Timeout 服务器作为网关时，执行请求时发生超时错误。类似于 HTTP 504。

（20）5.05Proxying Not Supported 服务器不支持代理功能。

1.4Option 部分详解

1.4.1 Option 定义

CoAP 支持多个 Option，CoAP的Option的表示方法比较特殊，采用增量的方式描述，如下图所示：

一般情况下 Option 部分包含 Option Delta、Option Length 和 Option Value 这三部分。

（1）Option Delta：表示 Option 的增量，当前的 Option 的具体编号等于之前所有 Option Delta 的总和。

（2）Option Length：表示 Option Value 的具体长度。

（3）Option Value：表示 Option 具体内容。

1.4.2 Option 编号内容

CoAP 中所有的 Option 都采用编号的方式，这些 Option 及编号的定义如下图所示：

在这些 option 中，Uri-Host、Uri-Port、Uri-Path 和 Uri-Query 等和资源“位置”，以及参数有关。其中：

【7】Uri-Port：CoAP 端口号，默认为 5683

【11】Uri-Path：资源路由或路径，例如 \temperature。资源路径采用 UTF8 字符串形式，长度不计第一个"\"。

【15】Uri-Query：访问资源参数，例如 ?value1 = 1&value2 = 2，参数与参数之间使用“&”分隔， Uri-Query 和 Uri-Path 之间采用“?”分隔。

在这些 option 中，Content-Format 和 Accept 用于表示 CoAP 负载的媒体格式。

【12】Content-Format：指定 CoAP 复杂媒体类型，媒体类型采用整数描述，例如 application/json 对应整数 50，application/octet-stream 对应整数 40。

【17】Accept：指定 CoAP 响应复杂中的媒体类型，媒体类型的定义和 Content-Format 相同。

CoAP 协议中支持多个 Option，例如：

（1）第一个 Option Delta = 11，表示该 Option 表示 Uri-Path(11)

（2）第二个 Option Delta = 1，表示该 Option = 1+11，表示 Content-Format(12)

（3）第三个 Option Delta = 3，表示该 Option = 3+1+11，表示 Uri-Query(15)

CoAP 采用这样的方式表示多个 Option，而每种 Option 都可以在 HTTP 协议中找到对应项。

2.6 CoAP应用举例

在实际应用中，如果需要去监控某个传感器例如温度或湿度等。在这种情况下，CoAP Client 客户端并不需要不停的查询 CoAP 服务器端的数据变化情况。CoAPClient客户端可以发送一个观察请求 request 到 Server 服务器端。

从该时间点开始计算，Server 服务器便会记住 Client 客户端的连接信息，一旦温度发生变化，Server 服务器将会把新结果发送给 Client 客户端。如果 Client 客户端不在希望获得温度检测结果，那么 Client 客户端将会发送一个 RST 复位请求，此时 Server 服务器便会清除与 Client 客户端的连接信息。

如下图所示：

CoAP 客户端通过 GET 方法从 Server 端获得温度传感器数据，CoAP URI 为：

coap://www.server.com/temperautre

例子中 CoAP 的请求响应具体格式如下：

CoAP 请求采用 CON 报文，Server 接收到 CON 报文必须返回一个 ACK 报文。CoAP 请求采用 0.01 GET 方法，若操作成功 CoAP Server 返回 2.05 Content，相当于 HTTP 200 OK。请求和响应的 Message ID 必须完全相同，此处为 0x7d34。请求响应中的 Token 域为空。CoAP 请求中包含 Option，该 Option的类型为 Uri-Path，那么 Option Delta 的值为 0+11=11，Option Value 的值为字符串形式的“temperature”。CoAP 返回中包含温度数据，使用字符串形式描述，具体值为"22.3"。

通常来说，我们学习一种新的技术，最基础的手段就是把这种技术的协议找来看，一旦熟悉了协议的格式，那么再学习这种协议的应用就会轻松许多。

那么，今天我们就聊到这里，明天咱们继续，也请大家继续关注！

图片授权基于：CC0协议