受限应用协议（COAP）（只是翻译，每日更新）

摘要

COAP是一个专门应用于受限节点和受限网络的协议。受限节点通常都是包括少量的ROM和RAM的8位的微控制器（像低能耗的无线个人局域网之上的IPv6这样的）受限网络，它们通常都有很高的丢包率和典型的只有10kb/s的吞吐量。COAP协议即是为像智能能源和智能建筑这样的M2M（machine-to-machine）应用设计的。
COAP为不同的终端应用提供了一个请求/响应的模型，支持内建的资源服务发现，还包括了诸如URIs和网络媒体此类的核心概念。COAP的设计是用来完成和HTTP的轻松对接，这样，当遇到诸如多播支持、超低能耗、或者单纯的受限环境等特殊需求的时候，可以和Web整合起来。

文件状态

这是个互联网标准跟踪文档。
本文档是IETF的产品之一。代表着IETF的共识。它被公众所熟知，得到了IESG的支持来发表出来。进一步的了解可以移步 Section 2 of RFC 5741。
进一步的了解本文档，和勘误，或者需要回馈可以点击下面的链接：
http://www.rfc-editor.org/info/rfc7252.

正文

1.介绍

网络服务的应用无处不在，很多的应用都是基于基本的网络架构-REST。
本研究致力于实现REST架构在多数的受限节点（比如：带有有限的RAM和ROM的微控制器和受限网络）上的可适应应用形式。像6LoWPAN这样的受限网络支持将IPv6的数据包分成更小的链路层帧，然而，这会大大增加传书中的丢包率。COAP协议的一个重要设计目的就是控制传输中的信息尽可能的小，从而降低分帧的需求。
另一个设计COAP协议的主要目的是来为受限环境的一些特殊需求设计一个一般的web协议，尤其是像能耗、智能建筑、M2M应用。虽然COAP协议可以将HTTP重做为一个更小的协议，但更重要的是，它同时可以为M2M应用提供服务，如内嵌发现、多播支持和异步消息转化。
本文档详细介绍了COAP协议，当遇到诸如多播支持、短报文、单纯的受限环境等特殊的需求时，它可以轻易地转化为HTTP来和已有的web整合起来。

1.1 特点

COAP有如下几个主要特征：

• Web协议满足M2M在受限环境中的需求。
• UDP和可选的可靠的支持单播和多播请求绑定在一起。
• 异步消息转化。
• 短报文和低匹配复杂度。
• 支持URI和内容类型。
• 简单代理和缓存能力。
• 无状态HTTP，允许代理以标准的HTTP方式或者COAP实现HTTP接口的形式接入COAP资源。
• 安全绑定DTLS。

1.2 术语

• 端点
  COAP协议中的实体。用一般话来说，就是一个端点住在一个“节点”里面，虽然“主人”和互联网标准使用更加符合，端点将会被传输层多路复用信息进一步定义，将会包括一个UDP端口号和一个安全性联系。
• 发送者
  一段报文的原始端点。当关注点在特殊的发送者时，也叫它“源端点”。
• 接受者
  报文的目的地，当关注点在特殊的接收者时，也叫它“目的端点”。
• 客户端
  一个请求的原始端点，回复的目的地。
• 服务方
  请求的目的地，回应的原始端点。
• 原始服务方
  一个在其上有一个给定的资源，或者即将创建一个给定的资源的服务端。
• 中介
  一种COAP端点，即可以做为服务端，也可以作为一个指向服务端的客户端。一个一般的中介的形式是代理；之后的章节将会介绍几类这种代理。
• 代理
  一种和推送请求和转发回应有关的中介，可能用于高速缓存、命名空间翻译或者继承中的协议的翻译。和一般意义上的中介不同，代理通常不会应用他专门的应用语义。基于在请求传送的所有结构的位置，将一般的代理分为两类：转发代理和反向代理。在某种情况下，根据请求的特征，某个端点转换表现，来作为原始服务方、转发代理、反向代理。
• 转发代理
  被客户端选中的端点，通常应用本地配置规则，来代表客户端传输请求，完成必要的翻译。有些翻译是很少的，比如针对COAP的URIs的中介请求，其他请求可能需要处理来自或者发往完全不同的应用层协议的翻译请求。
• 反向代理
  一中在一个或者多个server之间的端点，它代表server来满足请求，做出必要的翻译。不同于转发代理，client可能不知道它正在和一个反向代理进行交互；反向代理就像作为目标资源的原始server那样接收请求。
• COAP-to-COAP代理
  一种COAP请求之间互相匹配的请求，COAP协议既被用于服务侧还有客户侧。和交叉代理作为对比。
• 交叉代理
  交叉协议代理，或者交叉代理，是在不同协议之间进行翻译，比如COAP-HTTP代理和HTTP-COAP代理。尽管这个说明指出了非常明确地COAP-COAP代理需求，交叉代理有更加多的可能性。
• 可确定报文
  有些报文需要确认消息。这些报文被称作“可确认的”。如果没有丢包，每个确认报文都要精确的标明一个确认格式或者重置格式的返回报文。
• 无确认报文
  一些其他的报文不需要确认。对于一些应应用需求经常重复的报文来说，比如从传感器重复读取数据。
• 确认报文
  一个确认报文用来确认一个特定的可确认的报文被接收了。就自身而言，确认报文不代表着封装在确认报文里的请求成功或者失败了，但是，确认报文也包含一个回执响应（往下看）。
• 重置报文
  重置报文表示一个特定的报文（可确认的或者无确认的）被接收了，但是由于一些其他的内容缺失了而不能成功进行下去。这种情况通常是由于接收节点被重启了，从而忘记了翻译报文所需要的状态。对于检验端点的活跃与否来说，触发重置报文是一个相对来说方便又简洁的方式。
• 背负式反应
  一个背负式响应包含在CoAP的发往确认报文接收方的用于响应请求的确认报文中。
• 分裂响应
  当一个携带一个请求的确认响应被确认为空消息时，一个分裂响应将会被放在分裂报文交换中发送。
• 空消息
  Code是0.00的报文；既不是请求也不是响应。一个空报文只包含4字节的头部。
• 关键选项
  一个需要最终受到报文的端点理解以正确执行报文的扩展项。表示关键选项的应用是，当名为“选项”被应用时，通常的选择：不支持关键选项会导致错误的响应或者报文的摘要拒绝。
• 可选项
  一个可能由于不能被解析而被断端点忽略的可选项。即使跳过解析而直接执行报文也是可接受的。
• 不安全的可选项
  一个需要代理按序接收来理解的选项。不是每个关键选项都是不安全的。
• 转发安全选项
  一个当被并不理解的中介转发时需要是安全的的选项。跳过这个选项转发报文也是可以接受的。
• 资源发现
  CoAP客户端通过服务端查询主机的资源列表的过程。
• 内容格式
  一种互联网媒体综合类型，可能有给定的特殊参数和内容编码，被一个自CoAP 内容格式注册表定义的数字识别器识别，当关注点多在资源代表特点的结合而不是数字识别器上时，它也被称作“代表格式”。

更多关于受限节点和受限节点网络的术语可以查阅[RFC7228]。

2.受限应用协议

CoAP协议的互相作用模型和HTTP协议的客户/服务器模型很像。然而，CoAP应用中典型的机器-to-机器互相作用即在客户端也在服务器作用。CoAP协议的请求和HTTP的一模一样，都是由客户端发出一个请求（通过方法码），指向客户端上的资源。请求的回应包括了一个资源的代表。
和HTTP不同，对于异步交换，CoAP协议通过一个正如UDP这样的面向数据报的传输来处理。 逻辑上，这是通过应用支持可选信任项的报文来完成的。CoAP定义了4种类型的报文：可确认的、不可确认的、承认的、重置的。包含在这些报文中的方法代码和回应代码让他们携带请求或者回应。这四种报文的基本交换在某种意义上和请求/回应交互是正交的；请求可以被放在可确认的和无确认的报文里，回应既可以放在上述两个中也可以搭载在确认报文里。
有人可能会认为CoAP协议逻辑上使用两层的设计，在过去，一个CoAP报文通常用来处理UDP和异步的交互，请求/回应交互则使用方法和回应代码。然而，CoAP是一种独立的协议，它只把报文和请求/回应当作CoAP协议的头部的组成。

2.1 报文模型

CoAP报文模型是基于端点之间UDP之上的报文交换。
CoAP协议使用了一种固定长度的字节头（4字节），当然其后也可能会跟着紧凑的字节选项或者负载。这种报文格式通用于请求和回应。每个报文都包含一个用来检查重复和可选的可靠性检测的报文ID。（报文ID是紧凑的；它16位的大小允许在端点之间通过默认的协议参数，每秒最多250个报文传输）
可靠性是通过把一个报文标记为可确认的来实现的。一个可确认的报文是被这样转播的：在转播之间使用一个默认的时延和指数的回退，直到相关的端点即接收方使用了同一个报文ID发送了一个确认信息；当不是所有的接收方都可以识别可确认的报文的时候，它将回应一个重置报文（RST）而不是确认报文（ACK）。

一个不需要可靠传输的报文可以作为一个无确认报文来被发送出去。尽管不被承认，但它仍然包含一个用来查重的报文ID。当接收方不能解析无确认报文时，它将返回重置报文。
查看第4部分来详细了解CoAP的报文。

那么既然CoAP运行在UDP之上，那么它也支持多播的IP地址，支持多播CoAP请求。第八部分讨论了带有多播地址的CoAP报文的正确用法。

几个安全方式在第九部分被定义，从无安全到基于证书的安全；本文档详细说明了和DTLS之间的关联来保证协议的安全性；IPsec的使用在[IPsec-CoAP]中讨论。

2.2 请求/回应模型

CoAP的请求和回应语义包含在CoAP报文里，CoAP报文相应的包括了一个方法代码或者一个回应代码。可选请求和回应信息（比如URI负载媒体类型被包含在CoAP可选项中。一个来自所以来的报文的记号被独立的应用在匹配请求和回应中）。
一个请求被携带在一个可确认/无确认的报文中，如果立即可用的话，可确认报文中的对请求的回应被携带在结果确认报文中，这被称作携带回应。两个基本的带有携带回应的GET请求的例子如下图所示，一个成功了，一个导致了404回应。
如果服务器不能立刻回复携带确认报文的请求，那么他将只是简单地回应一个空的确认报文，这样的话客户端便不会再继续转发请求。当回应准备好的时候，服务方在一个新的可确认的报文中发送它。这个过程叫做“分离的回应”，正如下表所示，详细信息参看5.2.2
如果一个请求是通过无确认报文发送的，那么回应信息就通过一个新的无确认报文发送，虽然有时服务器还是会通过一个可确认报文发送。交换的类型如下图所示：
CoAP协议使用和HTTP相似的方式来应用GET，PUT，POST和DELETE，语义将在5.8部分详细说明。（CoAP的方法是“几乎是，但不完全是不一样”对比HTTP：自HTTP的经验就直觉而言应用的很成功，但是有足够的不同使得读一读现在的介绍足够必要。）
在基本的四个方法之上的方法可以被分别加入CoAP的介绍中，新的方法不一定必须成对的使用请求、回应。甚至对于已有的方法而言，一个单独的请求就足够应对多种回应。
服务器里的URI支持被简化为了客户端已经匹配了URI然后又被解析为host，端口，路径，和查询组成，为了效率而使用默认的值。和HTTP状态码的小子集相关的回应代码被编码，加入一些CoAP独特的代码，正如5.9定义的那样。

2.3 中介和高速缓存

协议支持回应的缓存来搞笑的满足请求。简单的缓存支持使用刷新和CoAP回应携带的正确信息。缓存可以放在端点或者中介中。缓存的作用过程在5.6部分详细介绍。
代理之所以在受限网络很好用有几个原因，包括限制网络交通，优化表现，来获取休眠的设备的资源，或者以为安全原因。协议中支持对代表着另一个CoAP端点的请求的代理。使用代理时，被请求的资源的URI包含在请求中，而目的IP地址被设置在代理的地址中。查看5.7部分来了解更详细的代理作用原理。
CoAP是根据REST架构设计的，功能的作用和HTTP协议的作用方式是一致的，可以直接在CoAP和HTTP之间进行寻址。这样的关联可能是用来通过CoAP实现HTTP的REST接口或者在HTTP和CoAP之间转化。这个对话可以携带在“跨协议代理”上，这类代理将方法或者回应代码，媒体类型，和可选项转化为相应的HTTP组成。

2.4 资源发现

对于机器交互来说，资源发现是很重要的。资源发现通过CoRE Link Format被支持。这将在第七部分被讨论。

3.报文格式

CoAP协议是基于默认情况下通过UDP传输的报文的交换。CoAP也可以被用在DTLS（数据包传输层安全）。也可以在各种其他协议之上应用比如SMS，TCP，或者SCTP。
CoAP报文以一种简单的字节格式被封装。报文以一个固定大小的4字节的报文头作为开始。之后跟着一个可变长度的代码值，可以是0~8字节长。
跟着代码值的是一串的0或者更多的TLV格式的CoAP选项，然后可选择的跟着剩下的数据报负载部分。

报文头里的区域如下定义：

• Version：2位的无符号整数。代表了CoAP的版本号。当前应用了协议的必须把此区域设置成1，其他的值设置成保留至将来其他版本用。没有版本号的报文必须被无视。
• Type：2位的无符号整数。表示报文是属于哪种类型：可确认的，无确认的，确认报文，或者重置类型。
• Token Length（TKL）：4位的无符号整数。代表可变长度的代号区域的长度。9~15位被保留的话，禁止被传输，兵应该被断定为格式错误。
• Code：8位的无符号整数。分开为3位 的类部分和5位的细节部分。
• MessageID：16位的无符号整数。被用来检测重复和在确认/重置报文和可确认/无确认报文之间进行匹配。

紧随头部的是代号值，他可能是0~8字节的长度，正如区域给定的那样。这个值永爱链接请求和回应。
接着是0或者其他的可选项。可选项之后是报文的末尾或者另一个可选项再或者负载标记或者负载。
再紧接着的是，如果存在的话，可选的负载。如果存在，且不是长度为0，那么负载将会加上一个固定的一个字节的负载标记前缀，代表了可选项的结束和负载的开始。负载的数据从标记开始直到UDP报文的结束。负载长度才能够数据包大小计算出来。如果没有标记位，代表着0位的负载字段。一旦出现了负载标记，那么如果跟随着一个0位 的负载，数据必须被解析为格式错误。

3.1 可选项格式

CoAP定义了一系列的可以包含在报文里的可选项。每个可选项例子都表明包含的可选项的个数，可选项的长度和可选项自己本身。
不能直接说明可选项个数，例子必须必须按他们的可选项序号出现，在他们之间运用了delta编码：每个可选项标号是通过将本身的delta值和前一个可选项序号相加计算的。对于第一个可选项，则设置为默认的0。

在可选项中的区域如下定义：

• Option Delta：4位的无符号整数。0~12之间的整数，代表了delta。三个保留数字用作特殊构造：
• 13：8位的无符号整数跟随着原始的字节，代表delta -13
• 14：16位的无符号整数以网络字节顺序跟随出事的字节代表delta -269
• 15：为负载标志保留。如果区域被设置成15而整个字节不是负载标志，那么这个报文必须被标记为格式错误。
  最后的delta选项被用来区分。简单的把本delta值和之前的所有delta值相加，把结果赋给可选序号。
• Option Length：4位的无符号整数。0~12的一个值，代表着可选值的长度。三个特殊值被保留做有特殊用途：
• 13：8位的无符号整数，代表 -13
• 14：16位的无符号整数以网络字节顺序跟随出事的字节代表delta -269
• 15：为负载标志保留。如果区域被设置成15而整个字节不是负载标志，那么这个报文必须被标记为格式错误。
• Value：一串确定的可选长度字节。

3.2 可选值格式

文中定义的可选项遵循以下几种格式：

• 空：0长度的字节。
• 不透明的：不透明的一串字节。
• uint：非负整数。
• 字符串：Unicode串，使用UTF-8编码。

4. 消息传递

CoAP消息在端与端之间的交换是异步的。消息承载了CoAP的请求和响应，请求和响应的语义在第5章中定义。
由于CoAP运行在如UDP这种非可靠的传输协议上，因此CoAP消息也许是乱序到达的，或是重复的，甚至被丢失。出于这个原因，CoAP中实现了一个轻量级的可靠性机制，这个机制并不是试图重新实现TCP的所有特性。它有以下特性：

• 简单的停等(stop-and-wait)重传机制，对于需要应答的消息，每次的重传等待时间会指数级增长。
• 对于CON和NON类型的消息，都进行重复检测。

4.1 消息和端

一个CoAP端可能是CoAP消息的源端或者目的端。端具体的定义（即标识）由CoAP所使用的传输协议来决定。对于本文档所指定的传输层协议，端的标识取决于所使用的安全模式（参见第9章）：对于无安全的模式，端由一个IP地址和一个UDP端口号来标识。对于其它安全模式，端的标识由具体的安全模式来定义。

CoAP协议有许多不同的消息类型，由CoAP头部的Type字段标识。

消息为请求、响应还是为空，这和请求/响应模型相关，是由头部的请求/响应码字段（code段）定义的。这个字段允许的值在CoAP代码表中定义（见12.1节）。

空消息的code段被设为0.00。它的TKL字段必须设为0，且Message ID字段后必须没有数据，否则应当做消息格式错误处理。

4.2 可靠的消息传输

如果CoAP协议头部中T字段标识为CON类型，则说明其采用可靠传输。CON类型的消息一般携带请求或响应，除非它是想要发送空消息以引发RST。接收端接收到CON类型消息后，必须是以下两种情况之一：

• 通过返回一个ACK消息确认已收到。回复的ACK必须带有和CON消息相同的Message ID，并且必须携带有响应（附带响应格式）或者为空消息（单独响应格式）。
• 如果是因为该消息缺少上下文而无法被正确处理（例如消息为空、使用了保留的Code类别(1，6或7)，或者消息格式错误），拒绝这个消息。通过回复对应的RST消息，或者直接忽略，接收端可以拒绝CON类型的消息。回复RST消息必须带有和CON消息相同的Message ID，并且必须为空消息。参看5.2.1节和5.2.2节。
  如果接收端想要拒绝一个ACK消息或者RST消息（例如ACK消息携带有请求或者有保留的code类别，RST消息不为空消息等），只需要忽略即可。一般的，ACK和RST消息的接收端必须不应答ACK或RST消息。

注意：发送端重传消息的间隔以指数增长，直到它收到一个ACK或者RST消息，或者达到最大重传次数。

重传由超时时间和重传计数控制。对于每一个CON类型的消息，发送端必须一直维护超时时间和重传计数,直到收到对应的ACK或者RST。对于一个新的CON消息，初始的超时时间被设置为介于ACK_TIMEOUT和ACK_TIMEOUT*ACK_RANDOM_FACTOR)之间（参见4.8节）的随机值（通常不是整数秒），重传计数被设置为0。当超时发生，且重传计数的值小于MAX_RETRANSMIT，消息被重传，重传计数增加，超时时间变为原来的两倍。如果在超时发生的时候重传计数达到了MAX_RETRANSMIT，或者收到了一个RST消息，那么就会放弃消息的传输，由应用程序来处理这个传输失败；如果在超时之前收到了ACK，那么传输就被认为成功了。

这一机制并不强制要求精准的时钟来实现上述指数回退算法。具体的说，某个端可能由于它周期性的休眠而没有赶上某一个重传时间点，但它却赶上了下一个。然而，两次重传之间的最小时间间隔是ACK_TIMEOUT，并且整个传输和重传的过程必须在MAX_TRANSMIT_SPAN（见4.8.2节）之内，尽管这意味着发送者有可能会错过传输的机会。

发送CON消息的端有可能在重传计数到达MAX_RETRANSMIT之前就放弃重传。例如，应用程序取消了这一请求，因为它已经不再需要响应；或者有其它证据表明消息已经到达，比如该请求消息导致接收端产生了单独响应，这种情况下就很明显，丢失的仅仅是请求消息的ACK而已，重传这个请求消息毫无意义。然而，响应端必须不能依赖请求端这种跨层的行为，它必须维护状态，为这个（可能重复的）请求回复ACK。如果需要的话，即使源请求端确认了CON响应（单独响应的第2步），接收端也应该回复（源请求端重传的请求）ACK。

另一个放弃重传的原因可能是收到了ICMP错误。如果希望处理ICMP错误以减轻潜在的ICMP欺骗攻击的影响，那么在实现上，应该仔细检查产生ICMP消息的原始数据，包括端口号和CoAP头部信息，如Message type, code, Message ID和Token；如果由于UDP提供的接口API的限制而无法检查，那么就应该忽略ICMP错误。如果遵循了第4.6节中的“实现注意”，那么正常情况下不应该发生数据包过大错误(IPv4的"fragmentation neede and DF set" [RFC0792])RFC4443]，因此应该被忽略。如果没有遵循，那么就应该进入一个路径MTU计算算法[RFC4821]。Source Quench和Time Exceeded类型的ICMP错误应该被忽略。主机，网络，端口或协议不可达错误和参数错误有可能经过适当的审查后用于通知应用程序，消息发送失败。

###4.3, 没有可靠性保障的消息传输 有的消息不需要应答。尤其是周期性的重复的消息，例如对传感器的数据的重复读取，并不需要每次都成功。

在没有可靠性保障的情况下传输，可以把消息标记为NON类型，作为更加轻量级的选择。NON消息总是承载着一个不为空的请求或者响应。接收端必须不应答NON消息。如果缺少必要的上下文而无法正确的处理（包括消息是空的，使用了保留类别的code(1,6或7)，或者消息格式错误）那么接收端必须丢弃这个NON消息。同时服务端有可能会忽略该消息或者响应一个对应的RST消息。

在CoAP层，发送者没有任何办法得知NON类型的消息是否被接收端收到。发送者可能在MAX_TRANSMIT_SPAN(在第4.7节的条款所限制，特别是PROBING_RATE，如果没有收到响应)之内发送多个副本，网络传输也有可能导致消息出现重复。为了使接收端能够只处理一次，NON消息也带有Message ID(和CON消息的Message ID共用数字池)。

总结第4.2和4.3节，四种类型的消息的使用如表1所示。“*”代表的是正常情况下不会这么使用这个组合，除非为了引起一个RST消息(也就是“CoAP ping”)。

4.4 消息相互关系

一个确认或者重置报文可以通过端点的报文ID和扩展地址信息来和可确认或者无确认报文关联起来。报文ID是一个由报文的发送方生成的16位的无符号整数，它包含在CoAP报文头部。报文ID必须包含在接收方的确认或者重置报文里。
在EXCHANGE_LIFETIME时间范围内，同样的报文ID不可以重复使用（4.8.2部分）
应用笔记：几种应用策略可以用来生成报文ID。在同一种情况下，一个CoAP端点通过保持一个单独的报文ID变量来生成报文ID，每次发送了一个新的可确认或者无确认报文之后，这个变量都要改变，无论目的地址和端口是多少。处理很多事务的端点可以保留多种I变量，比如，每个前缀或者一个目的地址。强烈推荐变量的初始值是随机的，为了尽可能防止偏离路径攻击。
对于一个来匹配可确认或者无确认的确认或者重置报文而言，确认报文和重置报文的报文ID和源端点必须和匹配报文ID和可确认或者无确认报文的目的端点。

4.5 重复报文

接收方可能会在EXCHANGE_LIFETIME中收到两个一样的报文，例如，当它发送的确认报文丢失了，或者在时限之前没有到达原始发送方。接收方必须使用相同的确认报文回复每一个可确认报文，但是只能执行请求/回应一次。这条规则在某种情况下是可以放松一点，比如这个可确认报文传输了一个幂等的请求，或者这个请求可以用幂等的方式处理。几个例子：

• 当回应所有的需要相同的回应的幂等请求的重传时服务器需要放宽这个规则，这样它就不需要修改报文ID的状态。例如，如果重复处理的代价不如追踪之前的回应高时，一个应用可能要把一个重复的重传，比如一个GET、PUT或者DELETE请求当作分开的请求来处理。
• 一个受限服务器甚至可能会对特定的无幂等的请求放宽松这个规则。例如，如果一个POST请求的结果只是服务器里面的一些短生命周期的产物，那么，不管之前的重传是否进行了，这个的处理都会比追踪重传耗费的精力要少。
  一个接收方可能会在NON_LIFETIME内多次接收到同样的无确认报文。作为一个常规的基于报文语义而放宽松的规则，接收方必须默默地忽略任何重复的无确认报文，必须只能执行一次。

4.5 报文大小

虽然具体的的链路层让它变得有利的，来使得CoAP报文足够小来适应它的链路层包，这是一个涉及应用质量的问题。CoAP协议说明本身只是提供了一个报文大小的最大上限。比IP包还要大的报文将会导致不被希望的报文分片。一个被完美封装的报文，应该可以放入一个IP包，显然也应该是和一个IP数据报。如果对于目的地来说，路径MTU是不可知的，那么一个128字节的IP MTU将被装上；如果对报头的大小一无所知，那么，报文大小上限1152字节，负载大小上限1024字节。
应用日志：CoAP的选择数据报参数和IPv6以及大多数的IPv4都配合的很好。（然鹅，对于IPv4来说，很难保证没有IP分片。如果支持不寻常的网络是一个考虑的话，应用将会想要限制自身更加严格的复合IPv4的数据报大小，比如576字节；绝对的IPv4协议的IP MTU最小值低于68字节，这样的话，只给UDP负载留下了40字节的日常安全开支，极其专注于这个问题的应用也可能会设置IPv4DF位，并进行一些路径MTU发现；虽然，这一点在实际应用中会渐渐变得不必要。）一个在受限网络中更为重要的分页是在适配层；
对于受限节点来说，报文大小同样重要。许多应用需要为即将到来的报文分配出一个缓存。如果应用过于受限，不支持分配上面提到的上限，那么它可以那么它可以为没有应用DTLS的把数据报应用以下策略：应用接受的编程缓存的太小的通常都是可以判断后面的部分是否被丢弃了和追溯之前的部分。所以，至少CoAP的报头和可选项，如果不是所有的负载，和缓冲是匹配的。一个服务器就可以完整的翻译一个请求兵回复一个回复代码如果负载被压缩。客户端发送一个幂等的请求并接受一个回应，可以重复请求给区块部分赋一个合适的值。

4.7 拥塞控制

基本的CoAP拥塞控制在4.2部分被越来越快的支撑设备提供。
为了避免拥塞，客户端（包括代理）必须严格限制所维护的和给定服务器并发交互的数量。一个独立的交互或者是CON（这时还没收到ACK但是还是被期待的）或者是一个请求（既没有收到回应也没有收到确认报文但是仍然被期待），默认的NSTART特定值是1。
更加先进的拥塞控制选择在未来可能会有好的发展，比如可能会提供自动的CoAP传输参数初始化，这点在4.8中被定义。
经过了EXCHANGE_LIFETIME之后，客户端会期待一个回应，回应一个确认请求，通过这个来确认没有收到确认报文。
特定的算法还未被定义，被客户端用来停下来“期待着”对一个可确认或者无确认请求的回应。除非这个被另外的拥塞控制修改，他必须被用这种方式选择，端点在发送给另一个端点但是没有收到回应之前，不会超出平均数据几率的PROBING_RATE。
NOTE：CoAP只管客户端的拥塞控制。然而，客户端有可能出现故障或者称为攻击者，比如，实施放大攻击。为了减少损失，服务器必须实施流量限制。当在针对表现不佳端点时这一点尤为有效。