RPC系列协议--rfc7252--The Constrained Application Protocol (CoAP)

1.摘要

约束应用程序协议(CoAP)是一种专门的web传输协议，用于约束节点和约束(例如约束节点和约束节点)。例如低功率、损耗的网络。节点通常有8位微控制器与少量ROM和RAM，而受限网络，如IPv6在低功率无线个人区域网络(6LoWPANs)经常有高包错误率和典型的10秒kbit/s吞吐量。该协议是为机器对机器(M2M)应用而设计的，如智能能源和建筑自动化。
CoAP提供应用程序端点之间的请求/响应交互模型，支持内建的服务和资源发现，并包含Web的关键概念，如URI和Internet媒体类型。CoAP的设计目的是方便地与HTTP进行接口，以便与Web集成，同时满足一些特殊需求，如多播支持、非常低的开销以及对受限环境的简单性。

2.介绍

CoAP的一个设计目标是保持消息开销小，因此限制了对碎片的需求。CoAP的主要目标之一是为这种受限环境的特殊需求设计一个通用的web协议，特别是考虑到能源、建筑自动化和其他机器对机器(M2M)应用。CoAP的目标不是盲目压缩HTTP[RFC2616]，而是实现一个REST的子集，该子集使用HTTP，但针对M2M应用程序进行了优化。尽管CoAP可用于将简单的HTTP接口重新设计为更紧凑的协议，但更重要的是，它还为M2M提供了诸如内置发现、多播支持和异步消息交换等特性。
本文指定了约束应用程序协议(CoAP)，它可以轻松地转换为HTTP，以便与现有Web集成，同时满足特定需求，如多播支持、非常低的开销以及对约束环境和M2M应用程序的简单性。

2.1 特性

CoAP具有以下主要特点:
a.在受限环境下满足M2M要求的Web协议。
b.UDP绑定可选可靠性支持单播和多播请求。
c.异步消息交换。
d.低头开销和解析复杂性。
e.URI和内容类型支持。
f.简单的代理和缓存功能。
g.无状态HTTP映射，允许构建代理，以统一的方式通过HTTP访问CoAP资源，或者通过CoAP交替实现HTTP简单接口。
h.与数据报传输层安全性的安全绑定

2.2 术语

缩写	全称
Endpoint	参与CoAP协议的实体。口头上，一个端点生活在一个“节点”，虽然“主机”将更符合互联网标准的使用，并进一步由传输层多路复用信息，可以包括UDP端口号和安全协会
Sender	消息的原始端点。当关注的是特定发送方的标识方面时，也是“源端点”。
Recipient	消息的目标端点。当识别特定接收者的方面是焦点时，也称为“目的端点”。
Client	请求的原始端点;响应的目标端点。
Server	请求的目标端点;响应的原始端点。
Origin Server	给定资源驻留或将要创建的服务器。
Intermediary	作为服务器和原始服务器(可能通过进一步的中介)的客户机的CoAP端点。
Proxy	主要负责转发请求和转发响应，可能在处理过程中执行缓存、名称空间转换或协议转换。与一般意义上的中介体不同，代理通常不实现特定的应用程序语义。根据请求转发在整体结构中的位置，通常有两种代理形式:前向代理和反向代理。在某些情况下，根据每个请求的性质，单个端点可能充当原始服务器、前向代理或反向代理切换行为。
Forward-Proxy	客户端通常通过本地配置规则选择的端点，代表客户端执行请求，进行任何必要的转换。有些转换是最小的，比如对于“coap”uri的代理请求，而其他请求可能需要在完全不同的应用层协议之间进行转换。
Reverse-Proxy	一个端点，它代替一个或多个其他服务器，代表这些服务器满足请求，进行任何必要的转换。与前向代理不同，客户端可能不知道它正在与反向代理通信;反向代理接收请求，就像它是目标资源的源服务器一样。
CoAP-to-CoAP Proxy	从一个CoAP请求映射到一个CoAP请求的代理。
Cross-Proxy	跨协议代理，或简称为“跨代理”，是在不同协议之间转换的代理，如CoAP-to-HTTP代理或httpto - coap代理。虽然这个规范对coap到coap代理提出了非常具体的要求，但是在交叉代理中可能有更多的变化。
Confirmable Message	有些消息需要确认。这些消息被称为“可确认的”。当没有数据包丢失时，每个可确认的消息都会引出一个类型确认或类型重置的返回消息。
Non-confirmable Message	其他一些消息不需要确认。对于因应用程序需求而定期重复的消息，如来自传感器的重复读数，尤其如此。
Acknowledgement Message	确认消息确认到达了一个特定的可确认消息。确认消息本身并不指示封装在可确认消息中的任何请求的成功或失败，但是确认消息也可以携带一个附带响应。
Reset Message	重置消息表示收到了特定消息(可确认或不可确认)，但缺少一些上下文来正确处理它。当接收节点重新启动并忘记了解释消息所需的某些状态时，通常会出现这种情况。触发一个重置消息(例如，通过发送一个空的可确认消息)作为一个廉价的端点活性检查也是有用的(“CoAP ping”)。
Piggybacked Response	附带响应包含在CoAP确认(ACK)消息中，发送该消息以确认收到此响应的请求。
Separate Response	当一个带有请求的可确认消息被确认为空消息时(例如，因为服务器不能马上得到答案)，一个单独的响应将在单独的消息交换中发送。
Empty Message	代码为0.00的消息;既不是请求也不是响应。空消息只包含4字节的标题。
Critical Option	最终接收消息的端点需要理解的选项，以便正确处理消息。请注意，关键选项的实现，顾名思义，通常是可选的:不受支持的关键选项会导致错误响应或消息的摘要拒绝。
Elective Option	一个被不理解它的端点忽略的选项。在不理解选项的情况下处理消息是可以接受的
Unsafe Option	接收消息的代理需要理解的一个选项，以便安全转发消息(章节5.4.2)。并不是每个关键选项都是不安全的。
Safe-to-Forward Option	一个选项，旨在安全转发的代理，不理解它。在不理解选项的情况下转发消息是可以接受的(章节5.4.2)。
Resource Discovery	CoAP客户端向服务器查询其托管资源列表的过程。
Content-Format	Internet媒体类型(可能具有给定的特定参数)和内容编码(通常是标识内容编码)的组合，由“CoAP内容格式”注册中心定义的数字标识符标识。如果关注的焦点不是数字标识符，而是资源表示的这些特征的组合，这也称为“表示格式”。

3.受限的应用协议

CoAP的交互模型类似于HTTP的客户机/服务器模型。但是，机器对机器的交互通常会导致同时扮演客户端和服务器角色的CoAP实现。CoAP请求相当于HTTP请求，由客户机发送，以请求服务器上资源(由URI标识)上的操作(使用方法代码)。然后，服务器发送带有响应码的响应;此响应可能包括资源表示形式。
与HTTP不同，CoAP通过面向数据的传输(如UDP)异步处理这些交换。这是使用支持可选可靠性(指数回退)的消息层在逻辑上完成的。CoAP定义了四种类型的消息:Confirmable, Non-confirmable, Acknowledgement, Reset。这些消息中包含的方法代码和响应代码使它们携带请求或响应。这四种类型消息的基本交换与请求/响应交互有些正交;请求可以在可确认和不可确认消息中携带，响应可以在这些消息中携带，也可以在确认消息中附带。
可以认为CoAP逻辑上使用一个两层的方法,CoAP消息传递层用于处理UDP和异步交互的本质,和请求/响应交互使用方法和响应代码(参见图1)。然而CoAP是一个协议,与消息传递和请求/响应CoAP头的特点。

Application	Requests/Responses	Messages	UDP

3.1 消息传递模型

CoAP消息传递模型基于端点之间通过UDP交换消息。CoAP使用一个短的固定长度的二进制头(4字节)，它后面可能跟着一个紧凑的二进制选项和一个有效负载。此消息格式由请求和响应共享。CoAP消息格式在第3节中指定。每个消息都包含一个消息ID，用于检测副本和可选的可靠性。(消息ID很紧凑;它的16位大小允许在默认协议参数下每秒从一个端点到另一个端点发送250条消息。)
可靠性是通过将消息标记为可确认(CON)来提供的。使用默认的超时和重新传输之间的指数后退重新传输可确认的消息，直到接收方从相应的端点发送一个具有相同消息ID的确认消息(ACK)(在本例中为0x7d34);参见图2。当收件人根本无法处理可确认的邮件时(即，甚至不能提供合适的错误响应)，它使用重置消息(RST)而不是确认消息(ACK)进行响应。

不需要可靠传输的消息(例如，传感器数据流中的每一个测量值)可以作为不可确认消息(NON)发送。这些没有被确认，但是仍然有一个用于重复检测的消息ID。当收件人无法处理不可确认的消息时，它可以使用重置消息(RST)进行回复。