1. Introduction

Internet 上 Web 服务 (web APIs) 的使用已经在大多数应用中变得无处不在, 并依赖于 Web 的基本表述性状态转移 (Representational State Transfer, REST) 架构 [REST].

受限 RESTful 环境 (Constrained RESTful Environments, CoRE) 的工作目标, 是以适合最受限节点 (constrained nodes, 例如 RAM 和 ROM 有限的 8 位微控制器) 与网络 (例如 6LoWPAN, [RFC4944]) 的形式实现 REST 架构. 6LoWPAN 等受限网络支持将 IPv6 packet 分片成较小的链路层帧; 但这会显著降低 packet 递送概率. CoAP 的一个设计目标是保持 message 开销较小, 从而限制对分片的需求.

CoAP 的主要目标之一, 是为这种受限环境的特殊需求设计一种通用 Web 协议, 尤其面向能源, 楼宇自动化以及其他机器到机器 (M2M) 应用. CoAP 的目标不是盲目压缩 HTTP [RFC2616], 而是实现与 HTTP 共有的 REST 子集, 并针对 M2M 应用进行优化. 虽然 CoAP 可用于将简单 HTTP 接口改造为更紧凑的协议, 但更重要的是, 它还提供了适合 M2M 的特性, 如内建发现, 多播支持和异步 message 交换.

本文档规定受限应用协议 (Constrained Application Protocol, CoAP). CoAP 易于转换到 HTTP, 以便与现有 Web 集成, 同时满足多播支持, 极低开销以及受限环境和 M2M 应用所需的简单性等专门需求.

1.1. Features

CoAP 具有以下主要特性:

o 在受限环境中满足 M2M 需求的 Web 协议.

o UDP [RFC0768] 绑定, 带可选可靠性, 支持单播和多播 request.

o 异步 message 交换.

o 较低的 header 开销和解析复杂度.

o 支持 URI 和 Content-type.

o 简单的代理和缓存能力.

o 无状态 HTTP 映射, 使 proxy 能以统一方式通过 HTTP 提供对 CoAP resource 的访问, 或者使简单 HTTP 接口也能通过 CoAP 实现.

o 到数据报传输层安全 (Datagram Transport Layer Security, DTLS) [RFC6347] 的安全绑定.

1.2. Terminology

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 在以全大写出现时, 应按 [RFC2119] 中的描述解释. 这些词也可能以小写形式出现在本文档中, 此时不具有规范性含义.

本规范要求读者熟悉 [RFC2616] 中讨论的所有术语和概念, 包括 "resource", "representation", "cache" 和 "fresh". (由于本规范在更新后的 HTTP RFC 集, 即 RFC 7230 到 RFC 7235 可用之前已经完成, 因此本规范专门引用其前身版本 -- RFC 2616.) 此外, 本规范定义以下术语:

Endpoint : 参与 CoAP 协议的实体. 口语上, endpoint 位于一个 "Node" 上, 虽然 "Host" 更符合 Internet 标准用法; endpoint 还通过传输层复用信息进一步标识, 这些信息可包括 UDP port number 和 security association (Section 4.1).

Sender : message 的发起 endpoint. 当关注具体 sender 的标识时, 也称为 "source endpoint".

Recipient : message 的目的 endpoint. 当关注具体 recipient 的标识时, 也称为 "destination endpoint".

Client : request 的发起 endpoint; response 的目的 endpoint.

Server : request 的目的 endpoint; response 的发起 endpoint.

Origin Server : 给定 resource 所在或将被创建于其上的 server.

Intermediary : 一个 CoAP endpoint, 既作为 server, 又作为面向 origin server 的 client (可能经过更多 intermediary). intermediary 的常见形式是 proxy; 本规范讨论了若干类这样的 proxy.

Proxy : 主要负责转发 request 并中继 response 的 intermediary, 在此过程中可能执行缓存, 命名空间转换或协议转换. 与一般意义上的 intermediary 不同, proxy 通常不实现特定应用语义. 根据其在整体 request 转发结构中的位置, proxy 有两种常见形式: forward-proxy 和 reverse-proxy. 在某些情况下, 单个 endpoint 可能根据每个 request 的性质, 在 origin server, forward-proxy 或 reverse-proxy 行为之间切换.

Forward-Proxy : client 选择的 endpoint, 通常通过本地配置规则选择, 用来代表 client 执行 request 并进行必要转换. 一些转换很小, 例如针对 "coap" URI 的 proxy request; 其他 request 可能需要在完全不同的应用层协议之间转换.

Reverse-Proxy : 代表一个或多个其他 server 并代其满足 request 的 endpoint, 同时执行必要转换. 与 forward-proxy 不同, client 可能不知道自己正在与 reverse-proxy 通信; reverse-proxy 像目标 resource 的 origin server 一样接收 request.

CoAP-to-CoAP Proxy : 将 CoAP request 映射为 CoAP request 的 proxy, 即在 server 侧和 client 侧都使用 CoAP 协议. 与 cross-proxy 相对.

Cross-Proxy : 跨协议 proxy, 简称 "cross-proxy", 是在不同协议之间转换的 proxy, 例如 CoAP-to-HTTP proxy 或 HTTP-to-CoAP proxy. 虽然本规范对 CoAP-to-CoAP proxy 提出非常具体的要求, cross-proxy 则允许更多变化.

Confirmable Message : 一些 message 需要 acknowledgement. 这些 message 称为 "Confirmable". 在没有 packet 丢失时, 每个 Confirmable message 恰好引出一个类型为 Acknowledgement 或 Reset 的返回 message.

Non-confirmable Message : 另一些 message 不需要 acknowledgement. 这尤其适用于因应用需求而定期重复的 message, 例如来自 sensor 的重复读数.

Acknowledgement Message : Acknowledgement message 确认某个具体 Confirmable message 已到达. Acknowledgement message 本身不表示 Confirmable message 中封装的任何 request 成功或失败, 但 Acknowledgement message 也可携带 Piggybacked Response (见下文).

Reset Message : Reset message 表示已收到某个具体 message (Confirmable 或 Non-confirmable), 但缺少用于正确处理它的某些上下文. 这种情况通常发生在接收节点重启并忘记了解释该 message 所需的某些状态时. 触发 Reset message (例如发送 Empty Confirmable message) 也可作为低成本检查 endpoint 存活性的方式 ("CoAP ping").

Piggybacked Response : piggybacked Response 直接包含在 CoAP Acknowledgement (ACK) message 中, 该 ACK message 用于确认接收到此 Response 对应的 Request (Section 5.2.1).

Separate Response : 当携带 request 的 Confirmable message 用 Empty message 确认 (例如因为 server 不能立即给出答案) 时, Separate Response 会在单独的 message 交换中发送 (Section 5.2.2).

Empty Message : Code 为 0.00 的 message; 既不是 request 也不是 response. Empty message 仅包含 4 字节 header.

Critical Option : 为了正确处理 message, 最终接收该 message 的 endpoint 需要理解的 option (Section 5.4.1). 注意, 如 "Option" 这个名称所暗示, critical option 的实现通常仍是可选的: 不支持的 critical option 会导致 error response 或对 message 的直接拒绝.

Elective Option : 旨在由不理解它的 endpoint 忽略的 option. 即使不理解该 option, 处理该 message 也是可接受的 (Section 5.4.1).

Unsafe Option : proxy 为了安全转发 message 而需要理解的 option (Section 5.4.2). 并非每个 critical option 都是 unsafe option.

Safe-to-Forward Option : 旨在可由不理解它的 proxy 安全转发的 option. 即使不理解该 option, 转发该 message 也是可接受的 (Section 5.4.2).

Resource Discovery : CoAP client 向 server 查询其托管 resource 列表的过程 (即 Section 7 中定义的 link).

Content-Format : Internet media type (可能带有特定参数) 与 content-coding (通常是 identity content-coding) 的组合, 由 "CoAP Content-Formats" registry 中定义的数字标识符标识. 当关注点不是数字标识符, 而是 resource representation 的这些特征组合时, 也称为 "representation format".

关于 constrained node 和 constrained-node network 的其他术语见 [RFC7228].

在本规范中, 术语 "byte" 按当前惯用意义使用, 作为 "octet" 的同义词.

本协议中的所有多字节整数均按 network byte order 解释.

凡使用算术之处, 本规范采用读者熟悉的 C 编程语言记法, 但运算符 "**" 表示乘方.