GB／Z  41294-2022  物联网应用协议 受限应用协议(CoAP)技术要求

是以不需确认消息的形式发出的，其响应消息也要以不需确认消息来发送。流程如

如果请求消息是以不需确认消息的形式发出的，其响应消息也要以不需确认消息来发送。 图5所示。

GB/Z41294—2022

图5不需确认消息的请求与响应

CoAP使用GET,PUT，POST和DELETE方法，其语义定义见8.9。 在这四种基础方法上建立的其他方法可以添加到CoAP协议当中。新的方法不需要以请求、响应 对的形式出现。单一的请求消息也可能有多个响应消息，比如组播请求。 URI支持在服务器中简化，因为客户端已经解析了URI并且将其分解为主机、端口、路径以及查询 组件饲养标准，利用默认值来提高效率。响应代码由HTTP响应代码的子集和CoAP定义的响应代码组成，其 定义见8.10。

协议支持响应缓存以满足请求的效率要求。简单缓存使CoAP响应中携带的信息新鲜、有效。缓 存可以在端点中，也可以在中介当中。缓存功能见8.7。 代理在受限网络当中有很重要的意义，包括网络流量限制、性能增强、接人休眠设备等。协议支持 由代理代表其他CoAP端点发送请求。当使用代理时，请求中包含请求资源的URI，目的地址填写代 理的地址。代理功能的详细描述见8.8。 CoAP协议使用REST风格设计，因此其外在功能与HTTP相似，所以CoAP和HTTP的互相映 射具有天然优势。这种映射可以用基于CoAP的HTTPREST接口实现，或者在HTTP与CoAP之 间转换。这种转换可以利用协议转换代理实现，其功能是转换方法和响应代码，媒体类型及其他可选项 到相应的HTTP特征。HTTP映射详见第13章

在M2M应用中，资源发现是很重要的功能，详见第10章

GB/Z41294—2022

a）版本：2bit无符号整数。指出了CoAP的版本号。如果执行本标准，该参数应为1。其他值为 保留值。该字段不正确时，消息直接予以抛弃。 b 类型：2bit无符号整数。消息如果为需确认消息该值为0，如果为不需确认消息该值为1， ACK消息该值为2，RST消息该值为3。消息类型的语义见第8章。 令牌长度（TKL）：4bit无符号整数。指出了可变长令牌的长度。其中9位～15位为保留字 段，不可发送，如果接收到按消息格式错误处理。 C 编码：8bit无符号整数，前3位为类型，后5位为内容。如记录人c.dd时，c为前3位代表的 0～7之中的一个，dd为后5位代表的00～31中的一个。类型中，0代表请求，1代表成功响 应，4代表客户端失败响应，5为服务器失败响应，其他值为保留值。特殊情况，0.00为空消 息。消息为请求消息时，其内容值请求方法；消息为响应消息时，其值为响应代码。所有可能 的值详见CoAP代码注册表。请求、响应的语义见第8章。 d）MessageID：16bit无符号整数，以网络顺序排序。用于检测消息是否重复，同时用来匹配需 确认消息的ack和不需确认消息的rst消息。产生与匹配规则详见第7章。 消息头之后跟的是令牌值，0字节～8字节长，由令牌长度字段定义。令牌值用来匹配请求、响应消 产生于匹配方式见8.4。 消息头、令牌之后可以为全0或者其他可选项。可选项之后可以为消息结尾或者一个负载标记及 戴。 消息头、令牌、可选项之后就是可选项负载。如果存在非零负载，其由一个固定前缀标记，1字节的 或标记(OxFF），意味着可选项的结束和负载的开始。负载数据从标记开始直到UDP报文结尾。无 我标记意味差负载长度为0。有负截标记而无负载应按照格式错误消息执行。

CoAP定义了一些可以被包含在消息当中的可选项。消息中的每个可选实例都指定了CoAP可选 项中定义的可选项数量，可选项长度和可选项本身。 与直接定义可选项数不同，实例应以可选项数十增量的形式顺序出现：可选项数的计算方法是增量 加上消息运行的实例的可选项数。消息中的第一个实例，其计算可选项数时增量为0。用增量为0的 方式同一个可选项可以包含多个实例。可选项的格式见图7。 可选项数保存在CoAP可选项数注册表当中。8.5当中定义了其语义。

可选项字段定义如下，

a）增量：4bit无符号整数。其值为0～12。其中三个值保留为特殊构造字段。 13：8bit无符号整数。初始字节之后的8bit无符号整数，其增量减去13。 14：16bit无符号整数。初始字节之后的按网络字节顺序的16bit无符号整数，其增量减269。 15：为负载标识保留。如果该值已设置但是非负载标识，应按照格式错误处理。 结果增量是本可选项的可选项数与之前可选项的不同之处，可选项数是前一个可选项数加上 增量计算得来的。 b）可选项长度：4bit无符号整数。可选项值的长度（字节），其值为0～12。其中三个值保留为特 殊构造字段。 13：8bit无符号整数。在可选项值之前，表示其可选项长度减去13。 14：16bit无符号整数。在可选项值之前按网络顺序排列，表示其可选项长度减去269。 15：保留位。如果该值已设置，应按照格式错误处理。 1 值：完全的可选项长度（字节)序列。可选项值的长度和格式取决于可选项本身，可以是不同的 长度值。本标准应用格式见6.3。其他规范定义的可选项可以用作其他可选项值格式。

CoAP消息在CoAP端点间异步交互。用第8童中定义的请求和响应消息进行传输

CoAP端点是CoAP消息的起点或终点。端点的具体定义取决于CoAP使用的传输方式。本文件 中使用的传输方式下，端点的身份由安全模式判断，详见第12章，没有安全措施情况下，端点通过ip地 址和UDP端口来判断。在其他安全模式下，身份由安全模式判断。 消息类型由CoAP消息头中的类型字段判断。 与消息类型相区别，消息可以承载请求、响应或者空消息。其通过消息头中的请求/响应码字段来 发送信号，并与请求/响应模型有关。其可能的取值见CoAPCode注册表。 空消息的Code字段为0.00。令牌长度应设置为0并且Messageid之后不可以有数据。如果有，则 按照消息格式错误处理。

在妥善检查之后也可以用来通知应用报错。

与源端点一致），作为一般规则这种消息可以被忽略，其请求或响应消息只应被执行一次。

消息传递的控制主要由表2所示的参数完成。

表2CoAP协议参数

GB/Z41294—2022

表2CoAP协议参数（续）

7.9.3参数传递中的时间值提取

CoAP操作是一个类似HTTP操作的请求/响应模型：作为“客户端”的CoAP端点向“服 点发送一个或者多个CoAP请求，“服务器”端点通过发送CoAP响应的方式对CoAP请求提 与HTTP请求不同，请求和响应不是通过先前建立的连接发送的，而是通过CoAP消息异步交

CoAP请求包括：应用到资源的方法、资源的标 于该请求的可选的元数据。 CoAP支持基本的方法：GET、POST、PUT和DELETE,这些方法很容易映射到HTTP。CoA

和HTTP（见IETFRFC2616中12.2)有相同的安全属性（仅检索）和幂等（多次调用得到的效果相同）。 GET方法是安全的，因此不必对资源采取检索以外的操作。GET、PUT和DELETE方法应以幂等的 方式执行。POST方法不是幂等的，因为它的效果由原始服务器决定并且依赖于目标资源，它通常会导 致一个新的资源被创建或者目标资源被更新。 请求是通过设置可确认(CON)或不可确认（NON)信息的CoAP报头中的代码域和包含请求信息 来进行初始化的。 请求中所使用的方法详细描述见8.9

8.3.1响应代码格式

接收到请求并且进行解释之后，服务器返回一个CoAP响应消息，该响应消息通过客户端发送的请 求中的令牌进行匹配（见8.4，注意，这不同于用于可确认消息与其确认消息之间进行匹配的消息ID）。 响应是通过CoAP报头中的代码域来确认的，该代码域将被设置为响应代码。类似于HTTP状态 代码，CoAP响应代码表明服务器试图理解并且满足请求。这些代码的定义详见8.10。CoAP报头中 的代码域所设置的响应代码值将由CoAP响应代码注册表进行维护。 图8所示的8位响应代码中，高3位用于定义响应的分类，低5位不用于分类，而是针对整体分类 给出更多的细节内容（见图8）

在最基本的情况下，响应直接通过回复请求的确认消息携带（这要求请求是可确认的消息类型 CON)，称为“挡带”响应。 通过确认消息携带响应的过程不依赖于该响应标识的是成功或失败。因此，响应通过回复请求的 确认消息携带，不需要单独的消息来返回响应。 注：具体实现过程中，协议将是否采用捐带方式返回响应（即是否发送单独的响应消息）留给服务器做决定。客户

GB/Z41294—2022

端应做好接收的准备。为了保证实现的质量，服务器宜尽可能实现捐带功能的代码，以节省网络资源和客户端 以及服务器的资源，

8.3.3分离消息（Separate）

如果请求消息是不可确认的，响应也应该以一个不可确认消息的形式返回。然而，端点（endpoint） 应准备接收用于回复可确认请求的不可确认响应（在一个空确认消息之前或之后）或者回复不可确认请 求的可确认响应

8.4.1令牌（Token）

不管如何发送响应，响应是通过客户端在请求中包含的令牌和附加的通信端点的地址信息来匹配 响应的。 令牌用来匹配响应和请求。令牌值是0个～8个字节的序列。（注意，每条消息携带一个令牌，即 使其长度为0。）每个请求携带一个由客户端生成的令牌，服务器在发送响应的时候不准许对令牌做任 何修改。 令牌的目的是用于客户端在本地区分并发的请求（见8.3）；令牌也可称作“请求ID”。 客户端生成令牌时应保证在当前使用的令牌对于一个给定的源/目标端点对是独一无二的。（注 意，如果客户端每次请求使用不同的端点，例如，不同的源端口号，客户端实现可以使用同样的令牌。)空 令牌值在如下情况是合适的，如：一个目的地址没有其他的令牌在使用，或者针对每个目的地址按串行

的方式发送请求和接收“挡带”应答。然而完成这个目标存在多种可能的实现策略。 客户端不使用传输层安全协议（见第12章）发送请求时应使用一个复杂的、随机的令牌来防止欺骗 的响应。令牌之所以能起保护性作用是因为它允许达到8字节的大小。令牌采用的实际大小取决于客 户的安全需求和欺骗的响应造成的威胁程度。连接通用互联网的客户端至少应使用32位的随机数；请 记住，如果不直接连接到互联网，客户端不一定非要能够防范欺骗。（注意，消息ID在安全方面的作用 很小，因为它通常是按顺序分配的，即可推测的，可以通过欺骗单独的响应绕过消息ID。）客户端如果希 望优化令牌长度，则需要进一步检测正在进行的攻击的等级（例如，通过分析最近到达的消息中的令牌 不匹配的情况）和适当地向上调整令牌的长度。IETFRFC4086讨论了安全的随机性需求。 端点如果接收到不是其产生的令牌，因此应把它视为不透明的，并目不解析其内容或结构

.2请求/响应匹配规则（Request/ResponseMatc

准确的请求/响应匹配规则如下： 1）响应的源端点应与原始请求的目标端点相同。 2 在“捐带”响应中，可确认请求的消息ID和确认的消息ID、响应的令牌和原始请求的令牌应匹 配。在采用单独方式发送的响应中，只要求响应的令牌和原始请求的令牌应匹配。 假设消息携带的响应不是客户端期待的（通过地址所识别的端点不是客户端所期待的，或者响应没 有给定的令牌），响应将被拒绝（见7.2、7.3）。 具体实现需要注意的事项： 在CON消息中接收到响应的客户端可能需要在发送ACK之后清理其消息状态。如果ACK消息 丢失并且服务器重新发送CON消息，客户端可能不再有任何状态与这个响应有关联，并且将重传的消 息作为异常消息处理；客户端将发送一个“Reset”消息，因此它不会接收更多的重传消息。这种行为是 正常的且并不是一个错误的信号。（如果客户端不去积极优化内存，其内存中则仍然具有消息状态，因 此客户端将会将第二次发送的CON消息作为重传消息。如果客户端期待服务器发送的更多的消息， 其将一直保持这种状态。）

8.5.1可选项的定义

8.5.2关键的和可选的（Critical/Elective）

所有选项可分为两类：“关键的”和“可选的”。这些选项之间的不同点是当这些选项未被端点识别 时该如何处理。 a） 接收时，未被识别的“可选的”选项应被静默忽略。 出现在可确认请求的未被识别的“关键的”选项应引起4.02(BadOption)响应的返回。这个响 应应包括一个诊断负载以描述未识别的选项（见8.6.3）。 C 出现在可确认响应或者确认的“带”消息中的未被识别的“关键的”选项应引发响应被拒绝 （见7.2）。 d）出现在不可确认消息中的未被识别的“关键的”选项一定会引发消息被拒绝。 注：无论是“关键的”还是“可选的”选项，选项都不是应的（选项始终是可选的)：这些规则的定义目的是使得实现在 不理解选项或者没有实现选项的时候能够停止对相应选项的处理。 关键的/可选的规则应用在没有代理的端点上。基于非安全/安全转发类的代理进程选项在8.7中 定义

除了将选项分为关键的或可选的两类以外，选项也可以根据代理是如何处理选项的方式进行分类。 为此，该选项可以被视为非安全转发（Unsafe被设置），也可以被视为安全转发（Unsafe被清除）。 另外，对于一个被标记为安全转发的选项，在请求中的选项数值表明它是否要成为缓存密钥 (CacheKey）的一部分（见8.7）。如果无缓存密钥（NoCacheKey）的部分比特为0，则选项是缓存密钥的 部分；如果无缓存密钥的所有比特均为1，则选项不是缓存密钥的一部分。 注：缓存密钥只与没有将给定的选项实现为请求选项、反而只依赖于非安全/安全转发的代理相关。举例来说，对 ETag，实际上将请求选项作为缓存密钥的一部分是非常效率低下的，但如果代理没有实现ETag，其是能选择的 最好方法，因为响应将根据请求的选项的不同而有所不同。如果代理实现了ETag请求选项，将不使用ETag 作为缓存密钥的一部分。 NoCacheKey用3bits表示，因此8个代码（codepoints）中的1个可以用于标识NoCacheKey，假设 这是不太可能的情况。 关于这些分类的代理行为定义见8.8。

选项值被定义成一个特定的长度，通常采用上界和下界的形式。如果请求的选项值的长度超出定 义的范围，该选项应被当作一个无法识别的选项（见8.5.1）。

选项可以定义为缺省值。如果该选项的值定义为缺省值，选项不应包含在消息中。如果选项不 则应假定缺省值。

息中的选项缺失可通过两种方式处理：一 关键选项进行实现；另一种是对这个选项的缺失解释为该选项的缺省值。

8.5.6可重复的选项

一些选项的定义详细说明了这些选项是可重复的。一个可重复的选项可能在一个消息中包含一次 或多次。一个不可重复的选项在一个消息中只能包含不超过一次。 如果消息包含一个比定义的选项出现次数的选项，每个额外选项出现，随后出现在消息中应被当作 一个无法识别的选项（见8.5.1）。

8.5.7选项号码（OptionNumbers）

选项是通过号码辨别的，选项号码还提供了一些额外的语义信息。例如，偶数表示的是可选的选 项，而奇数则表示关键性选项。请注意，这不仅仅是一个惯例，它是一个协议的特点，选项是可选性的或 关键性的完全由其选项号码是奇数还是偶数决定。 一般来说，选项号码使用1个比特掩码来表示选项是关键性的/可选的、非安全/安全转发以及在安 全转发情况下的缓存密钥，如图9所示。接下来，比特掩码位可表示为一个单一字节，该字节适用于选 项号码的最低有效字节，该有效字节以无符号整数的形式表示。当第7位（最低有效位)是1时，选项是 关键的（同样，为0时是可选的）。当第6位是1时，选项是不安全的（同样，为0时是安全转发）。当第6 位是0时，选项是Unsafe，当且仅当3位～5位都被置为1时，它不是一个缓存密钥（NoCacheKey）；所 有其他的位组合则意味着它是1个缓存密钥。选项的这些分类将在下一节中解释。 端点可使用等价的C代码来导出选项号码“onum”的特性，

Critical=(onum&.1); UnSafe=(onum&2); NoCacheKey=((onum & 0xle)==0xlc)

选项号码掩码（最低有效

请求和响应分别根据不同的方法或响应代码都可能包括有效负载。如果一个方法或响应代码 定义负载，发送者不能包括负载，接收者应忽略它

译表征（SelectedRepreser

并非所有的响应都携带有效负载，用于表示请求所需要的资源表征。然而，它有时是有用，以使能 够引用这样一个与响应相关的表征，而不依赖于其是否实际上是封闭的。 如果相应的请求是使用了GET方法，并排除任何条件请求选项，我们使用术语“选择表征”来指代 在一个成功的响应中被选中的目标资源的当前表征。 某些响应选项提供选择表征的元数据，这可能与包含在一些状态改变方法的响应消息中的表征不 同。这个规范中定义的响应选项中，只有ETag响应（8.11.7)选项被定义为已选择的表达元数据

住宅标准规范范本8.6.5内容协商（ContentNegotiation）

服务器可能在多种表示格式之一提供一个资源的表征。如果没有来自客户端的详细信息，它将以 它喜欢的格式提供表征。 使用请求的接收选项（见8.10.4），客户端可以用于表示它愿意接受的内容格式

在CoAP中进行缓存的目标是重新使用之前的应答消息来满足当前的请求。在某些情况下，一个 已储存的响应可以在不需要网络请求的情况下被重新使用，从而减少了等待时间和网络来回传输；为 此，“更新”机制可用于实现该目的（见8.7.1）。甚至当一个新请求被需要时，经常可以重新使用之前的 应答的有效载荷来满足请求，从而减少网络带宽使用；为此，“验证”机制可用于实现该目的（见8.7.2）。 不像HTTP，CoAP响应的可缓存性不依赖于请求模式，而是响应码。每个响应码的可缓存性由 8.10中的响应码定义所定义。每一个显示成功但是未被端点识别的响应码不会被缓存。 对于提出的请求，一个CoAP端点不能使用已储存的响应，除非。 a）提出的请求的方法和用来获得已储存的响应相匹配。 b）提出的请求的选择和用来获得储存响应的这些请求的选项相匹配（包括请求的URI），除非选 项被标记为NoCacheKey(见7.4)或被认为是缓存而按照缓存的行为进行解析，则不需要匹配 （比如ETag选项，8.11.7，同样见8.4.2）。 已储存的响应是新的或者被成功验证的，如以下定义。被用于匹配缓存人口请求选项的设置 也同样被归类为“缓存密钥”。对于URI方案而不是coap和coaps，这些组成请求URI的选项 的匹配可能在URI方案特定的规则下执行。

8.7.2新鲜度模型（FreshnessModel)

8.7.3验证模型（ValidationModel)

代理服务器可以用来代替COAP客户端执行请求。这种方法在某些情况下比较有效，例如，请求 可能无法进行，或者为了减少响应时间和网络带宽或能量的消耗用缓存中的响应对请求进行回复。 在一个基于受限的RESTful环境的整体架构中，代理服务器可以为完全不同的用途提供服务。代 理可以被客户端明确地选择，我们称之为“转发代理”。代理也可以代替源服务器，我们称之为“反向代 理”。和这种分类相对应，一个代理可以将COAP的请求映射到一个COAP请求（COAP到COAP代 理)或实现CoAP协议和其他协议的翻译“交叉代理”）。在第3章中提供了这些术语的完整定义。 注：在本文件的术语与在更广泛使用的Web应用环境中使用的术语是兼容的，虽然不一定每一个细节都匹配（这可 能与受限的RESTful环境没有关系）。没有太多的语义和这些术语的组成有关（如“前进”反向”或“交叉”)。 HTTP代理，除了可作为HTTP代理，其还通常提供传输协议的代理功能（“CONNECT”），以通 过代理实现终端到终端的传输层安全性。本说明书中，没有定义COAP到COAP代理的功能，因为在 受限的RESTful环境下，UDP数据包的转发不具有太多价值。见13.3.7的交叉代理案例。 客户端使用代理发送采用一种安全的URI方案（例如，coaps或https）的请求时，发送到代理的请 求应使用DTLS安全协议，除非客户端与代理之间采用了等价的底层安全协议

公差标准8.8.2代理操作（ProxyOperation）

基于代理接收到的请求，它通常 目的地址的请求的潜在请求参数。这 钟方式为转发代理做了详细说明，但可能依赖于反向代理的具体配置。特别是，反向代理的客户端通常 并不为目的地址指示一个定位器，迫使反向代理需要有某种形式的名称空间翻译。然而，代理服务器