RPC series protocol--rfc7252--The Constrained Application Protocol (CoAP)

1. Summary

Constrained Application Program Protocol (CoAP) is a special web transfer protocol used for constraint nodes and constraints (for example, constraint nodes and constraint nodes). For example, low-power, lossy networks. Nodes usually have 8-bit microcontrollers and a small amount of ROM and RAM, and restricted networks, such as IPv6, often have high packet error rates and typical 10-second kbit/s throughput in low-power wireless personal area networks (6LoWPANs). The protocol is designed for machine-to-machine (M2M) applications, such as smart energy and building automation.
CoAP provides a request/response interaction model between application endpoints, supports built-in service and resource discovery, and contains key concepts of the Web, such as URI and Internet media types. The design goal of CoAP is to conveniently interface with HTTP to integrate with the Web, while meeting some special requirements such as multicast support, very low overhead, and simplicity for restricted environments.

2. Introduction

One of the design goals of CoAP is to keep message overhead small, thus limiting the need for fragmentation. One of the main goals of CoAP is to design a universal web protocol for the special needs of this restricted environment, especially considering energy, building automation and other machine-to-machine (M2M) applications. The goal of CoAP is not to blindly compress HTTP [RFC2616], but to implement a subset of REST that uses HTTP but is optimized for M2M applications. Although CoAP can be used to redesign the simple HTTP interface into a more compact protocol, more importantly, it also provides features such as built-in discovery, multicast support, and asynchronous message exchange for M2M.
This article specifies the Constrained Application Protocol (CoAP), which can be easily converted to HTTP to integrate with the existing Web while meeting specific requirements such as multicast support, very low overhead, and simplicity for constrained environments and M2M applications Sex.

2.1 Features

CoAP has the following main features:
a. Web protocol that meets M2M requirements in a restricted environment.
b. UDP binding optional reliability supports unicast and multicast requests.
c. Asynchronous message exchange.
d. Low head overhead and analysis complexity.
e. URI and content type support.
f. Simple proxy and cache functions.
g. Stateless HTTP mapping, allowing the construction of a proxy to access CoAP resources through HTTP in a unified way, or alternatively implement simple HTTP interfaces through CoAP.
h. Security binding with datagram transport layer security

2.2 Terminology

abbreviation	Full name
Endpoint	Entities participating in the CoAP protocol. Orally, an endpoint lives on a "node", although the "host" will be more in line with the use of Internet standards, and further multiplexed information by the transport layer, which can include UDP port numbers and security associations
Sender	The original endpoint of the message. When the focus is on the identification aspect of a particular sender, it is also the "source endpoint".
Recipient	The destination endpoint of the message. When the aspect that identifies a particular recipient is the focus, it is also called the "destination endpoint."
Client	The original endpoint of the request; the target endpoint of the response.
Server	The target endpoint of the request; the original endpoint of the response.
Origin Server	The server where a given resource resides or will be created.
Intermediary	The CoAP endpoint of the client as the server and the origin server (possibly through further intermediaries).
Proxy	It is mainly responsible for forwarding requests and forwarding responses, and may perform caching, name space conversion, or protocol conversion during processing. Unlike intermediaries in the general sense, agents usually do not implement specific application semantics. According to the position of request forwarding in the overall structure, there are usually two proxy forms: forward proxy and reverse proxy. In some cases, depending on the nature of each request, a single endpoint may act as an origin server, forward proxy, or reverse proxy switching behavior.
Forward-Proxy	The client usually executes the request on behalf of the client through the endpoint selected by the local configuration rules, and performs any necessary transformations. Some conversions are minimal, such as proxy requests for "coap" uri, while other requests may need to be converted between completely different application layer protocols.
Reverse-Proxy	An endpoint, which replaces one or more other servers, satisfies the request on behalf of these servers, and performs any necessary transformations. Unlike the forward proxy, the client may not know that it is communicating with the reverse proxy; the reverse proxy receives the request as if it were the source server of the target resource.
CoAP-to-CoAP Proxy	A proxy that maps a CoAP request to a CoAP request.
Cross-Proxy	Cross-protocol proxy, or "cross-proxy" for short, is a proxy that converts between different protocols, such as CoAP-to-HTTP proxy or httpto-coap proxy. Although this specification puts forward very specific requirements for coap-to-coap agents, there may be more changes in cross-agents.
Confirmable Message	Some messages require confirmation. These messages are called "confirmable." When no data packets are lost, each acknowledgable message will lead to a type confirmation or type reset return message.
Non-confirmable Message	Some other messages do not require confirmation. This is especially true for messages that are periodically repeated due to application requirements, such as repeated readings from sensors.
Acknowledgement Message	The confirmation message confirms the arrival of a specific confirmable message. The confirmation message itself does not indicate the success or failure of any request encapsulated in the confirmable message, but the confirmation message can also carry an accompanying response.
Reset Message	The reset message means that a specific message (confirmable or unconfirmable) was received, but some context is missing to handle it correctly. This usually happens when the receiving node restarts and forgets some state required to interpret the message. Triggering a reset message (for example, by sending an empty confirmable message) is also useful as an inexpensive endpoint liveness check ("CoAP ping").
Piggybacked Response	The accompanying response is included in the CoAP Acknowledgement (ACK) message, which is sent to confirm receipt of this response request.
Separate Response	When a confirmable message with a request is confirmed as an empty message (for example, because the server cannot get the answer right away), a separate response will be sent in a separate message exchange.
Empty Message	Message with code 0.00; neither request nor response. The empty message only contains a 4-byte header.
Critical Option	The end point that ultimately receives the message needs to understand the options in order to process the message correctly. Please note that the implementation of key options, as the name suggests, is usually optional: unsupported key options will result in an error response or a summary rejection of the message.
Elective Option	An option ignored by endpoints that do not understand it. It is acceptable to process the message without understanding the options
Unsafe Option	An option that the receiving agent needs to understand in order to safely forward the message (Section 5.4.2). Not every key option is unsafe.
Safe-to-Forward Option	An option, a proxy designed to forward securely, doesn't understand it. It is acceptable to forward messages without understanding the options (Section 5.4.2).
Resource Discovery	The process in which the CoAP client queries the server for its managed resource list.
Content-Format	The combination of Internet media type (may have given specific parameters) and content encoding (usually identifying content encoding) is identified by a digital identifier defined by the "CoAP Content Format" registry. If the focus of attention is not the number identifier, but the combination of these characteristics represented by the resource, this is also called the "representation format."

3. Restricted application protocol

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)进行回复。

由于CoAP在UDP上运行，它还支持使用多播IP目的地地址，支持多播CoAP请求。

3.2 Request/Response模型

CoAP消息中包含CoAP请求和响应语义，分别包含方法代码和响应代码。可选(或默认)请求和响应信息，如URI和有效负载媒体类型，作为CoAP选项携带。
请求在可确认消息(CON)或不可确认消息(NON)中携带，如果立即可用，则在结果确认消息(ACK)中携带对可确认消息中携带的请求的响应。这称为附带响应。

如果服务器不能立即响应带有可确认消息的请求，那么它只响应一条空的确认消息，这样客户端就可以停止重新发送请求。当响应就绪时，服务器将以新的可确认消息的形式发送它(然后需要客户机确认)。这被称为“单独响应”。

如果在不可确认消息中发送请求，则使用新的不可确认消息发送响应，尽管服务器可以发送可确认消息。

CoAP以与HTTP类似的方式使用GET、PUT、POST和DELETE方法。超过这四种基本方法的方法可以在单独的规范中添加到CoAP。新方法不一定要成对地使用请求和响应。即使对于现有的方法，一个单一的请求也可能产生多个响应。服务器中的URI支持被简化了，因为客户端已经解析了URI并将其分解为主机、端口、路径和查询组件，从而利用缺省值提高效率。响应代码涉及HTTP状态代码的一个小子集，添加了一些特定于coap的代码。

3.3 仲裁者和缓存

协议支持缓存响应以有效地满足请求。通过使用CoAP响应中携带的新鲜度和有效性信息，可以实现简单的缓存。缓存可以位于端点或中间。代理在受限网络中是有用的，有几个原因，包括限制网络流量，提高性能，访问休眠设备的资源，以及出于安全原因。协议中支持代表另一个CoAP端点的请求代理。当使用代理时，要请求的资源的URI包含在请求中，而目标IP地址设置为代理的地址。
由于CoAP是根据REST架构[REST]设计的，因此其功能类似于HTTP协议，因此从CoAP映射到HTTP以及从HTTP映射到CoAP非常简单。这样的映射可以用于使用CoAP实现HTTP REST接口，或者用于在HTTP和CoAP之间进行转换。这种转换可以由跨协议代理(“跨代理”)执行，该代理将方法或响应代码、媒体类型和选项转换为相应的HTTP特性。

3.4 资源发现

资源发现对于机器对机器的交互很重要。

4.信息格式

CoAP基于紧凑消息的交换，默认情况下，这些消息通过UDP(即每个CoAP消息占据一个UDP数据报的数据部分)。CoAP也可以用于数据报传输层安全(DTLS)。它还可以用于其他传输，如SMS、TCP或SCTP。CoAP消息以简单的二进制格式编码。消息格式从固定大小的4字节头开始。后面跟着一个可变长度标记值，长度可以在0到8字节之间。在标记值之后是一个0个或多个类型-长度-值(TLV)格式的CoAP选项序列，可选地，后面跟着一个占用数据报其余部分的有效负载。

定义	说明
Version (Ver)	指示CoAP版本号，该规范的实现必须将该字段设置为1(01二进制)。其他值为将来的版本保留。未知版本号的消息必须被静默地忽略。
Type (T)	指示此消息的类型是否为可确认(0)、不可确认(1)、确认(2)或重置(3)。
Token Length (TKL)	指示可变长度标记字段的长度(0-8字节)。长度9-15是保留的，不能发送，必须作为消息格式错误处理。
Code	分为3位类(最有效位)和5位细节类(最低有效位)，记录为“c”。其中，“c”是3位子字段的0到7的数字，“dd”是5位子字段的00到31的两位数。类可以指示请求(0)、成功响应(2)、客户端错误响应(4)或服务器错误响应(5)(其他所有类值保留)。作为特例，代码0.00表示一条空消息。在请求的情况下，代码字段指示请求方法;如果是响应，则为响应代码。
Message ID	网络字节顺序中的16位无符号整数。用于检测消息重复，并将类型确认/重置的消息匹配为可确认/不可确认的消息。

4.1 选项格式

CoAP定义了许多可以包含在消息中的选项。消息中的每个选项实例指定定义的CoAP选项的选项号、选项值的长度和选项值本身。

Option Delta	Option Length	Option Delta(extended)	Option Length(extended)	Option Value

4.2 选项值

参数	定义
empty	一个零长度的字节序列。
opaque	不透明的字节序列。
uint	一种非负整数，使用选项长度字段给出的字节数以网络字节顺序表示。
string	使用UTF-8 [RFC3629]以Net-Unicode格式[RFC5198]编码的Unicode字符串。

5.消息传输

CoAP消息在CoAP端点之间异步交换。它们用于传输CoAP请求和响应，其语义在第5节中定义。由于CoAP绑定到不可靠的传输(如UDP)， CoAP消息可能无序到达、出现重复或丢失而没有通知。因此，CoAP实现了一种轻量级可靠性机制，而不尝试重新创建传输协议(如TCP)的完整特性集。具有以下特点:
a.简单的停止-等待重传可靠性指数回退可确认的消息。
b.可确认消息和不可确认消息的重复检测。

5.1 消息和端点

CoAP端点是CoAP消息的源或目的地。端点的特定定义取决于用于CoAP的传输。对于本规范中定义的传输，端点将根据所使用的安全模式来标识:如果没有安全性，则仅通过IP地址和UDP端口号标识端点。对于其他安全模式，端点由安全模式定义。
有不同类型的消息。消息的类型由CoAP报头的类型字段指定。与消息类型分开，消息可以携带请求、响应或为空。这是由CoAP报头中的请求/响应代码字段发出的信号，并且与请求/响应模型相关。字段的可能值在CoAP代码注册表中维护(第12.1节)。
空消息的代码字段设置为0.00。Token Length字段必须设置为0，并且Message ID字段之后不能出现字节数据。如果存在字节，则必须将其作为消息格式错误处理。

5.2 信息传输可靠

消息的可靠传输是通过在CoAP报头中将消息标记为可确认来启动的。可确认消息总是携带请求或响应，除非它仅用于引出重置消息，在这种情况下，它是空的。收件人必须(A)承认可证实的消息和一个确认消息或(b)拒绝消息如果接受者缺乏上下文正确地处理消息,包括消息为空的情况下,使用一个代码保留类(1、6或7),或一个消息格式错误。拒绝可确认的消息是通过发送匹配的重置消息和忽略它来实现的。确认消息必须回应可确认消息的消息ID，必须带有响应或为空(见第5.2.1和5.2.2节)。重置消息必须回显可确认消息的消息ID，并且必须为空。拒绝确认或重置消息(包括确认携带请求或带有保留类的代码，或者重置消息不是空的情况)可以通过静默忽略它来实现。更一般地，确认和重置消息的接收者不能用确认或重置消息进行响应。
发送方以指数增长的间隔重新发送可确认的信息，直到收到确认信息(或重置信息)或尝试失败为止。在等待确认(或重置)时，CoAP端点必须跟踪其发送的每个可确认消息的两件事:一个超时和一个重传计数器。对于新的可确认消息，初始超时设置为ACK_TIMEOUT和(ACK_TIMEOUT * ACK_RANDOM_FACTOR)之间的一个随机持续时间(通常不是整数秒)(见第4.8节)，并且重传计数器设置为0。

5.3 没有可靠性的信息传输

有些消息不需要确认。对于那些因应用程序需求而定期重复的消息尤其如此，比如来自传感器的重复读数，而最终的成功已经足够了。作为一种更轻量级的替代方案，可以通过将消息标记为不可确认来降低消息的可靠度。不可确认的消息总是携带请求或响应，并且不能为空。不可确认的邮件不能被收件人确认。如果缺少适当处理消息的上下文，包括消息为空、使用带有保留类的代码或消息格式错误，则接收方必须拒绝该消息。拒绝不可确认的消息可能需要发送匹配的重置消息，除了重置消息之外，被拒绝的消息必须被静默忽略。

5.4 消息相关性

确认或重置消息通过消息ID以及相应端点的附加地址信息与可确认消息或不可确认消息相关。消息ID是一个16位无符号整数，由可确认消息或不可确认消息的发送者生成，包含在CoAP报头中。接收方必须在确认或重置消息中回显消息ID。

5.5 消息重复数据删除

接收者可能会多次收到相同的可确认消息(由消息ID和源端点指示)，例如，当它的确认丢失或在第一次超时前没有到达原始发送方时。接收方应该使用相同的确认或重置消息确认可确认消息的每个副本，但应该只处理消息中的任何请求或响应一次。如果可确认消息传输幂等的请求(见5.1节)，或者可以用幂等的方式处理，则可放宽此规则。

5.6 消息大小

虽然特定的链路层有利于保持CoAP消息足够小，以适合它们的链路层数据包，但这是实现质量的问题。CoAP规范本身只提供了消息大小的上限。大于IP包的消息会导致不必要的包碎片。一个CoAP消息，适当地封装，应该适合在一个单独的IP包(即避免IP碎片)和(通过适应一个UDP有效负载)显然需要适应一个IP数据报。如果路径MTU不知道一个目的地，IP MTU的1280字节应该被假定;如果不知道消息头的大小，好的上限是消息大小的1152字节，有效负载大小的1024字节。

5.7 拥塞控制

CoAP的基本拥塞控制由指数回退机制提供。为了不造成拥塞，客户端(包括代理)必须严格限制在NSTART上的给定服务器(包括代理)上同时维护的未完成交互的数量。

5.8 传输参数

消息传输由以下参数控制:

名字	默认值
ACK_TIMEOUT	2 seconds
ACK_RANDOM_FACTOR	1.5
MAX_RETRANSMIT	4
NSTART	1
DEFAULT_LEISURE	5 seconds
PROBING_RATE	1 byte/second

5.8.1 变化的参数

ACK_TIMEOUT、ACK_RANDOM_FACTOR、MAX_RETRANSMIT、NSTART、DEFAULT_LEISURE(8.2节)和PROBING_RATE的值可以配置为特定于应用程序环境的值(包括动态调整的值);但是，配置方法超出了本文的范围。

5.8.2 从传输参数得到的时间值

ACK_TIMEOUT、ACK_RANDOM_FACTOR和MAX_RETRANSMIT的组合影响重传输的时间，而重传输的时间又影响实现需要保留某些信息项的时间。为了能够明确地引用这些派生的时间值，我们给它们命名如下:

name	default value
MAX_TRANSMIT_SPAN	45 s
MAX_TRANSMIT_WAIT	93 s
MAX_LATENCY	100 s
PROCESSING_DELAY	2 s
MAX_RTT	202 s
EXCHANGE_LIFETIME	247 s
NON_LIFETIME	145 s

6.请求/响应语义

CoAP在与HTTP类似的请求/响应模型下运行:扮演“客户端”角色的CoAP端点向“服务器”发送一个或多个CoAP请求，“服务器”通过发送CoAP响应来服务请求。与HTTP不同，请求和响应不是通过先前建立的连接发送的，而是通过CoAP消息异步交换的。

6.1 请求

CoAP请求由应用于资源的方法、资源的标识符、有效负载和Internet媒体类型(如果有的话)以及关于请求的可选元数据组成。CoAP支持基本的GET、POST、PUT和DELETE方法，这些方法很容易映射到HTTP。它们具有与HTTP相同的安全(仅检索)和幂等(您可以多次调用它，产生相同的效果)属性(参见[RFC2616]的9.1节)。GET方法是安全的;因此，除了检索之外，它不能对资源采取任何其他操作。GET、PUT和DELETE方法必须以幂等的方式执行。POST不是幂等的，因为它的效果由源服务器决定，并依赖于目标资源;它通常会导致创建新资源或更新目标资源。通过将可确认消息或不可确认消息的CoAP标头中的代码字段设置为方法代码并包括请求信息来发起请求。

6.2 响应

在接收和解释请求之后，服务器响应一个CoAP响应，该CoAP响应通过客户端生成的令牌与请求相匹配(第5.3节);注意，这与将可确认消息匹配到其确认的消息ID不同。响应由设置为响应代码的CoAP报头中的代码字段标识。与HTTP状态代码类似，CoAP响应代码表示试图理解和满足请求的结果。

6.2.1 附带

在最基本的情况下，响应直接在确认请求的确认消息中携带(这要求在可确认的消息中携带请求)。这被称为“附带反应”。响应在确认消息中返回，与响应指示成功或失败无关。实际上，响应依附于确认消息，不需要单独的消息来返回响应。

6.2.2 单独的

在所有情况下都返回一个附带响应。例如，服务器可能需要更长的时间来获取所请求资源的表示，而不是等待发送回确认消息，这样客户端就不会有重复转发请求消息的风险。对于带有不可确认消息的请求的响应总是单独发送的(因为没有确认消息)。

6.2.3 非确认

如果请求消息不可确认，则响应也应该以不可确认消息的形式返回。但是，端点必须准备好接收一个不可确认的响应(之前或之后是一个空的确认消息)来响应一个不可确认的请求，或者一个不可确认的响应来响应一个不可确认的请求。

6.3 请求/响应匹配

无论响应是如何发送的，都将通过客户机在请求中包含的令牌以及相应端点的附加地址信息与请求进行匹配。

6.3.1 Token

令牌用于将响应与请求匹配。标记值是一个0到8字节的序列。(注意，每条消息都带有一个令牌，即使它的长度为零。)每个请求都携带一个客户机生成的令牌，服务器必须在任何结果响应中回显(不修改)该令牌。令牌用作区分并发请求的客户端本地标识符;它可以被称为“请求ID”。客户端生成令牌的方式应该是给定源/目标端点对当前使用的令牌是唯一的。

6.3.2 请求/响应匹配规则

响应与请求匹配的确切规则如下:
1.响应的源端点必须与原始请求的目标端点相同。
2.在附带响应中，可确认请求的消息ID和确认信息必须匹配，并且响应和原始请求的令牌必须匹配。在单独的响应中，只有响应的令牌和原始请求的令牌必须匹配。

6.4 选项

请求和响应都可能包含一个或多个选项的列表。例如，请求中的URI以几个选项传输，HTTP中的HTTP头中携带的元数据也作为选项提供。

6.5 有效载荷和表现

请求和响应可能分别包括有效负载，具体取决于方法或响应代码。如果方法或响应代码没有定义为具有有效负载，则发送方必须不包含有效负载，而接收方必须忽略它。

6.6 缓存

CoAP端点可以缓存响应，以减少未来等效请求的响应时间和网络带宽消耗。在CoAP中缓存的目标是重用先前的响应消息来满足当前请求。在某些情况下，可以在不需要网络请求的情况下重用存储的响应，从而减少延迟和网络往返;为此使用了“新鲜度”机制。即使需要新的请求，也常常可以重用先前响应的有效负载来满足该请求，从而减少网络带宽的使用;为此使用了“验证”机制。

6.7 代理

代理是一个CoAP端点，可以由CoAP客户机委托它代表它们执行请求。这可能是有用的，例如，当请求可能不发出，或服务的响应从缓存，以减少响应时间和网络带宽或能源消耗。

6.8 方法定义

在本节中，将定义每个方法及其行为。带有未识别或不支持的方法代码的请求必须生成一个4.05(方法不允许)附带的响应。有GET/POST/PUT/DELETE函数。

温馨提示：
以上文章描述如有不清晰之处，欢迎在评论区评论，如有时间，会第一时间回复，谢谢！