跳到主要内容

2. Constrained Application Protocol

CoAP 的交互模型类似 HTTP 的 client/server 模型. 但是, 机器到机器交互通常会使一个 CoAP 实现同时扮演 client 和 server 角色. CoAP request 等价于 HTTP request, 由 client 发送, 用于请求在 server 上的某个 resource (由 URI 标识) 执行一个动作 (使用 Method Code). 随后 server 发送带有 Response Code 的 response; 该 response 可包含 resource representation.

与 HTTP 不同, CoAP 在面向 datagram 的传输 (如 UDP) 上异步处理这些交换. 在逻辑上, 这是通过一个支持可选可靠性 (带指数退避) 的 message 层完成的. CoAP 定义四种 message 类型: Confirmable, Non-confirmable, Acknowledgement, Reset. 某些 message 中包含的 Method Code 和 Response Code 使它们携带 request 或 response. 四种 message 类型的基本交换与 request/response 交互在一定程度上正交; request 可由 Confirmable 和 Non-confirmable message 携带, response 也可由这些 message 携带, 还可 piggyback 在 Acknowledgement message 中.

从逻辑上看, 可以把 CoAP 想成两层方法: 一个 CoAP messaging layer 用来处理 UDP 和交互的异步性质, 另一个 request/response 交互使用 Method 和 Response Code (见 Figure 1). 但 CoAP 仍是单一协议, messaging 和 request/response 只是 CoAP header 的特性.

                    +----------------------+
                    |      Application     |
                    +----------------------+
                    +----------------------+  \
                    |  Requests/Responses  |  |
                    |----------------------|  | CoAP
                    |       Messages       |  |
                    +----------------------+  /
                    +----------------------+
                    |          UDP         |
                    +----------------------+

                Figure 1: Abstract Layering of CoAP

2.1. Messaging Model​

CoAP messaging model 基于 endpoint 之间通过 UDP 交换 message.

CoAP 使用较短的固定长度二进制 header (4 字节), 其后可跟随紧凑的二进制 option 和 payload. 这种 message format 由 request 和 response 共享. CoAP message format 在 Section 3 中规定. 每个 message 都包含一个 Message ID, 用于检测重复并提供可选可靠性. (Message ID 很紧凑; 其 16-bit 大小在默认协议参数下支持一个 endpoint 向另一个 endpoint 每秒最多约 250 个 message.)

可靠性通过将 message 标记为 Confirmable (CON) 提供. Confirmable message 使用默认 timeout 和 retransmission 之间的指数退避进行重传, 直到 recipient 从对应 endpoint 发送带有相同 Message ID (本例中为 0x7d34) 的 Acknowledgement message (ACK); 见 Figure 2. 当 recipient 完全不能处理 Confirmable message (即甚至不能提供合适的 error response) 时, 它以 Reset message (RST) 而不是 Acknowledgement (ACK) 回复.

                    Client              Server
                       |                  |
                       |   CON [0x7d34]   |
                       +----------------->|
                       |                  |
                       |   ACK [0x7d34]   |
                       |<-----------------+
                       |                  |

              Figure 2: Reliable Message Transmission

不需要可靠传输的 message (例如 sensor 数据流中的每个单独测量值) 可作为 Non-confirmable message (NON) 发送. 这些 message 不被确认, 但仍带有用于重复检测的 Message ID (本例中为 0x01a0); 见 Figure 3. 当 recipient 不能处理 Non-confirmable message 时, 它可以回复 Reset message (RST).

                    Client              Server
                       |                  |
                       |   NON [0x01a0]   |
                       +----------------->|
                       |                  |

             Figure 3: Unreliable Message Transmission

CoAP message 的细节见 Section 4.

由于 CoAP 运行在 UDP 上, 它还支持使用 multicast IP destination address, 从而支持 multicast CoAP request. Section 8 讨论了带 multicast address 的 CoAP message 的正确使用方式, 以及避免 response 拥塞的注意事项.

Section 9 为 CoAP 定义了若干安全模式, 范围从无安全性到基于 certificate 的安全性. 本文档规定了用于保护该协议的 DTLS 绑定; CoAP 与 IPsec 的使用在 [IPsec-CoAP] 中讨论.

2.2. Request/Response Model​

CoAP request 和 response 语义由 CoAP message 携带, message 分别包含 Method Code 或 Response Code. 可选 (或默认) request 和 response 信息, 如 URI 和 payload media type, 作为 CoAP option 携带. Token 用于独立于底层 message 将 response 与 request 匹配 (Section 5.3). (注意, Token 是不同于 Message ID 的概念.)

request 由 Confirmable (CON) 或 Non-confirmable (NON) message 携带. 如果 response 可立即获得, 则对 Confirmable message 中所携带 request 的 response 会由随后的 Acknowledgement (ACK) message 携带. 这称为 piggybacked response, 详见 Section 5.2.1. (无需单独确认 piggybacked response, 因为如果携带 piggybacked response 的 Acknowledgement message 丢失, client 会重传 request.) Figure 4 展示了两个带 piggybacked response 的基本 GET request 示例, 一个成功, 一个产生 4.04 (Not Found) response.

    Client              Server       Client              Server
       |                  |             |                  |
       |   CON [0xbc90]   |             |   CON [0xbc91]   |
       | GET /temperature |             | GET /temperature |
       |   (Token 0x71)   |             |   (Token 0x72)   |
       +----------------->|             +----------------->|
       |                  |             |                  |
       |   ACK [0xbc90]   |             |   ACK [0xbc91]   |
       |   2.05 Content   |             |  4.04 Not Found  |
       |   (Token 0x71)   |             |   (Token 0x72)   |
       |     "22.5 C"     |             |   "Not found"    |
       |<-----------------+             |<-----------------+
       |                  |             |                  |

       Figure 4: Two GET Requests with Piggybacked Responses

如果 server 不能立即响应 Confirmable message 中携带的 request, 它只需用 Empty Acknowledgement message 响应, 使 client 停止重传 request. response 准备好后, server 在新的 Confirmable message 中发送它 (该 message 随后也需要由 client 确认). 这称为 "separate response", 如 Figure 5 所示, 并在 Section 5.2.2 中更详细描述.

                    Client              Server
                       |                  |
                       |   CON [0x7a10]   |
                       | GET /temperature |
                       |   (Token 0x73)   |
                       +----------------->|
                       |                  |
                       |   ACK [0x7a10]   |
                       |<-----------------+
                       |                  |
                       ... Time Passes  ...
                       |                  |
                       |   CON [0x23bb]   |
                       |   2.05 Content   |
                       |   (Token 0x73)   |
                       |     "22.5 C"     |
                       |<-----------------+
                       |                  |
                       |   ACK [0x23bb]   |
                       +----------------->|
                       |                  |

         Figure 5: A GET Request with a Separate Response

如果 request 在 Non-confirmable message 中发送, 则 response 使用新的 Non-confirmable message 发送, 但 server 也可以改为发送 Confirmable message. Figure 6 展示了这种交换.

                    Client              Server
                       |                  |
                       |   NON [0x7a11]   |
                       | GET /temperature |
                       |   (Token 0x74)   |
                       +----------------->|
                       |                  |
                       |   NON [0x23bc]   |
                       |   2.05 Content   |
                       |   (Token 0x74)   |
                       |     "22.5 C"     |
                       |<-----------------+
                       |                  |

   Figure 6: A Request and a Response Carried in Non-confirmable
                             Messages

CoAP 以类似 HTTP 的方式使用 GET, PUT, POST 和 DELETE method, 其语义在 Section 5.8 中规定. (注意, CoAP method 的详细语义与 HTTP method "almost, but not entirely unlike" [HHGTTG]: 来自 HTTP 经验的直觉通常适用, 但差异也足以使实际阅读本规范很有价值.)

基本四种 method 之外的 method 可由单独规范加入 CoAP. 新 method 不一定必须成对使用 request 和 response. 即便对现有 method, 单个 request 也可能产生多个 response, 例如 multicast request (Section 8) 或使用 Observe option [OBSERVE] 时.

server 中的 URI 支持被简化, 因为 client 已经解析 URI 并将其拆分为 host, port, path 和 query 组件, 同时为效率使用默认值. Response Code 对应 HTTP status code 的一个小子集, 并增加了少量 CoAP-specific code, 如 Section 5.9 所定义.

2.3. Intermediaries and Caching​

该协议支持缓存 response, 以便高效满足 request. 简单缓存通过 CoAP response 携带的新鲜度和有效性信息启用. cache 可以位于 endpoint 或 intermediary 中. 缓存功能在 Section 5.6 中规定.

proxying 在受限网络中有多种用途, 包括限制网络流量, 提高性能, 访问休眠设备的 resource, 以及满足安全原因. 协议支持代表另一个 CoAP endpoint 进行 request proxying. 使用 proxy 时, 待请求 resource 的 URI 包含在 request 中, 而 destination IP address 被设置为 proxy 的地址. 关于 proxy 功能的更多信息见 Section 5.7.

由于 CoAP 按 REST 架构 [REST] 设计, 因而表现出类似 HTTP 协议的功能, 从 CoAP 映射到 HTTP 以及从 HTTP 映射到 CoAP 都相当直接. 这种映射可用于使用 CoAP 实现 HTTP REST 接口, 或在 HTTP 与 CoAP 之间转换. 这种转换可由跨协议 proxy ("cross-proxy") 执行, 它将 Method 或 Response Code, media type 和 option 转换为对应的 HTTP 功能. Section 10 提供有关 HTTP 映射的更多细节.

2.4. Resource Discovery​

Resource discovery 对机器到机器交互很重要, 并使用 CoRE Link Format [RFC6690] 提供支持, 如 Section 7 所讨论.

最后于 更新