1. Introduction (简介)
Web服务 (Web APIs) 在互联网上的应用已经变得无处不在, 并且依赖于Web的基础表述性状态转移 [REST] 架构.
受限RESTful环境 (CoRE, Constrained RESTful Environments) 的工作旨在以适合最受限节点 (例如, 具有有限RAM和ROM的8位微控制器) 和网络 (例如, IPv6 over Low-Power Wireless Personal Area Networks, 6LoWPAN [RFC4944]) 的形式实现REST架构. 受限网络 (例如6LoWPAN) 支持将IPv6数据包分片成小的链路层帧; 然而, 这会导致数据包传递概率显著降低. CoAP的一个设计目标是保持消息开销较小, 从而限制对分片的需求.
CoAP的主要目标之一是为这种受限环境的特殊要求设计一个通用的Web协议, 特别是考虑到能源, 楼宇自动化和其他机器对机器 (M2M, Machine-to-Machine) 应用. CoAP的目标不是盲目地压缩HTTP [RFC2616], 而是实现HTTP的REST子集, 但针对M2M应用进行了优化. 虽然CoAP可以用于将简单的HTTP接口重新设计为更紧凑的协议, 但更重要的是, 它还为M2M提供了诸如内置发现, 组播支持和异步消息交换等特性.
本文档规定了受限应用协议 (CoAP, Constrained Application Protocol), 它可以轻松地转换为HTTP以与现有Web集成, 同时满足特定要求, 例如组播支持, 极低的开销, 以及受限环境和M2M应用的简单性.
1.1. Features (特性)
CoAP具有以下主要特性:
-
Web协议, 满足受限环境中的M2M要求
-
UDP [RFC0768] 绑定, 具有可选的可靠性, 支持单播和组播请求
-
异步消息交换 (Asynchronous message exchanges)
-
低头部开销和解析复杂度 (Low header overhead and parsing complexity)
-
URI和内容类型支持 (URI and Content-type support)
-
简单的代理和缓存能力 (Simple proxy and caching capabilities)
-
无状态HTTP映射 (Stateless HTTP mapping), 允许构建代理以统一的方式通过HTTP提供对CoAP资源的访问, 或者通过CoAP实现HTTP简单接口的替代方案
-
安全绑定到数据报传输层安全 (DTLS, Datagram Transport Layer Security) [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协议的实体. 通俗地说, 端点存在于一个"节点 (Node)"上, 尽管"主机 (Host)"与互联网标准的用法更一致, 并且通过传输层复用信息进一步标识, 这些信息可以包括UDP端口号和安全关联 (第4.1节).
Sender (发送者) : 消息的发起端点. 当特定发送者的识别方面成为焦点时, 也称为"源端点 (source endpoint)".
Recipient (接收者) : 消息的目的端点. 当特定接收者的识别方面成为焦点时, 也称为"目的端点 (destination endpoint)".
Client (客户端) : 请求的发起端点; 响应的目的端点.
Server (服务器) : 请求的目的端点; 响应的发起端点.
Origin Server (源服务器) : 给定资源所在或将要创建的服务器.
Intermediary (中介) : 一个CoAP端点, 它既作为服务器又作为客户端朝向源服务器 (可能通过更多的中介). 中介的一种常见形式是代理 (proxy); 本规范中讨论了此类代理的几个类别.
Proxy (代理) : 主要关注转发请求和中继响应的中介, 在此过程中可能执行缓存, 命名空间转换或协议转换. 与一般意义上的中介相反, 代理通常不实现特定的应用语义. 基于请求转发整体结构中的位置, 有两种常见的代理形式: 正向代理 (forward-proxy) 和反向代理 (reverse-proxy). 在某些情况下, 单个端点可能充当源服务器, 正向代理或反向代理, 根据每个请求的性质切换行为.
Forward-Proxy (正向代理) : 由客户端选择的端点 (通常通过本地配置规则), 代表客户端执行请求, 执行任何必要的转换. 一些转换是最小的, 例如对"coap" URI的代理请求, 而其他请求可能需要与完全不同的应用层协议之间进行转换.
Reverse-Proxy (反向代理) : 代表一个或多个其他服务器并满足其请求的端点, 执行任何必要的转换. 与正向代理不同, 客户端可能不知道它正在与反向代理通信; 反向代理接收请求, 就好像它是目标资源的源服务器一样.
CoAP-to-CoAP Proxy (CoAP到CoAP代理) : 从CoAP请求映射到CoAP请求的代理, 即在服务器端和客户端都使用CoAP协议. 与跨协议代理形成对比.
Cross-Proxy (跨协议代理) : 跨协议代理或简称"跨代理", 是在不同协议之间进行转换的代理, 例如CoAP到HTTP代理或HTTP到CoAP代理. 虽然本规范对CoAP到CoAP代理提出了非常具体的要求, 但跨代理可能有更多的变化.
Confirmable Message (可确认消息) : 某些消息需要确认. 这些消息称为"可确认 (Confirmable)". 当没有数据包丢失时, 每个可确认消息恰好引出一条确认 (Acknowledgement) 类型或重置 (Reset) 类型的返回消息.
Non-confirmable Message (不可确认消息) : 其他一些消息不需要确认. 对于出于应用要求而定期重复的消息尤其如此, 例如来自传感器的重复读数.
Acknowledgement Message (确认消息) : 确认消息确认已收到特定的可确认消息. 确认消息本身并不表示可确认消息中封装的任何请求的成功或失败, 但确认消息也可以携带捎带响应 (Piggybacked Response) (见下文).
Reset Message (重置消息) : 重置消息表示已收到特定消息 (可确认或不可确认), 但缺少某些上下文以正确处理它. 这种情况通常是由接收节点重新启动并忘记了解释消息所需的某些状态引起的. 引发重置消息 (例如, 通过发送空的可确认消息) 也可用作端点活性的低成本检查 ("CoAP ping").
Piggybacked Response (捎带响应) : 捎带响应直接包含在CoAP确认 (ACK) 消息中, 该消息被发送以确认收到此响应的请求 (第5.2.1节).
Separate Response (分离响应) : 当携带请求的可确认消息用空消息确认时 (例如, 因为服务器没有立即得到答案), 分离响应在单独的消息交换中发送 (第5.2.2节).
Empty Message (空消息) : 代码为0.00的消息; 既不是请求也不是响应. 空消息仅包含4字节头部.
Critical Option (关键选项) : 最终接收消息的端点需要理解的选项, 以便正确处理消息 (第5.4.1节). 请注意, 如选项名称"Option"所示, 关键选项的实现通常是可选的: 不支持的关键选项会导致错误响应或摘要拒绝消息.
Elective Option (可选选项) : 旨在被不理解它的端点忽略的选项. 即使不理解选项也可以接受处理消息 (第5.4.1节).
Unsafe Option (不安全选项) : 接收消息的代理需要理解的选项, 以便安全地转发消息 (第5.4.2节). 并非每个关键选项都是不安全选项.
Safe-to-Forward Option (安全转发选项) : 旨在对不理解它的代理转发是安全的选项. 即使不理解选项也可以接受转发消息 (第5.4.2节).
Resource Discovery (资源发现) : CoAP客户端查询服务器以获取其托管资源列表 (即, 第7节中定义的链接) 的过程.
Content-Format (内容格式) : 互联网媒体类型 (可能具有特定参数) 和内容编码 (通常是身份内容编码) 的组合, 由"CoAP内容格式 (CoAP Content-Formats)"注册表定义的数字标识符标识. 当焦点不太关注数字标识符而更关注资源表示的这些特征的组合时, 这也称为"表示格式 (representation format)".
有关受限节点和受限节点网络的其他术语可以在 [RFC7228] 中找到.
在本规范中, 术语"byte (字节)"以其现在惯用的意义用作"octet (八位字节)"的同义词.
本协议中的所有多字节整数都以网络字节顺序解释.