标准规范下载简介

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

GB/Z 41294-2022《物联网应用协议 受限应用协议（CoAP）技术要求》是中国推荐性国家标准，它详细规定了物联网中受限应用协议（Constrained Application Protocol, 简称CoAP）在物联网应用场景中的技术要求和规范。CoAP是一种轻量级的互联网协议，专为资源受限的物联网设备设计，如嵌入式设备、传感器等。

以下是GB/Z 41294-2022中关于CoAP技术要求的简介：

1. 协议架构：CoAP基于UDP协议运行，采用RESTful（Representational State Transfer，表述性状态转移）风格，具有简单、轻量、无状态、无连接的特性。

2. 资源管理：CoAP支持对设备上的资源进行发现、获取、修改和删除（CRUD）操作，适合在物联网环境下进行设备管理。

3. 安全性：虽然CoAP是无状态的，但该标准要求实现安全机制，如基于SSL/TLS的加密传输，以保证数据安全。

4. 数据格式：CoAP使用JSON格式的数据，易于解析和处理，适合小型设备处理。

5. 效率与可靠性：由于资源受限，CoAP优化了数据包大小和处理，提供简洁的错误处理机制，以保证通信效率和可靠性。

6. 多路复用：支持批量操作（如GET和POST），提高数据传输的效率。

7. 可扩展性：CoAP协议设计时考虑了未来可能的扩展，如支持WebSocket、MQTT等协议。

这份标准对CoAP在物联网中的应用提供了明确的技术指导，旨在促进物联网设备间的高效、安全通信。

GB／Z 41294-2022 物联网应用协议 受限应用协议(CoAP)技术要求.pdf部分内容预览：

8.7.3验证模型（ValidationModel)

8.8.2代理操作（ProxyOperation）

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

GB/Z41294—2022

GB/Z412942022

种资源，这些资源就像它本身的资源一样。反向代理免费建立了标识这些资源的URI命名空间。反向 代理也可以建立一个命名空间以给客户端提供监控请求去向的能力，如在所提供的资源的URI路径中 嵌人主机标识和端口号。 在处理响应时，反向代理要谨慎处理不同来源的ETag选项值，在提供给客户端的同一资源上不要 弄混淆。在许多情况下，ETag可以不做改变而转发。如果从一个反向代理服务器提供的资源到众多 原始服务器提供的资源的映射是不唯一的，反向代理可能需要生成一个新的ETag，确保能够正确地保 存这个选项的语义

GET方法根据当前由请求URI所标识的相应资源的信息去获取资源的表征。如果请求中包含 Accept选项，则表示响应的优先文本格式。如果请求中包含一个ETag选项，GET方法将要求ETag 进行验证，并且只有当验证失败时GET请求的表征才会被发送。如果GET成功的话，响应中应包含 一个2.05(Content)或2.03(Valid）响应码。

8.9.4 DELETE

DELETE方法请求删除URI所标识的资源。 当成功删除或者在收到请求之前资源已经不 寸，需要使用响应码2.02(Deleted）。 DELETE不是安全的，但是是幂等的。

8.10.1成功2.xx

这类状态代码表示客户端的请求被成功接收、理解和接受

类似HTTP204“没有内容”，但是只在导致资源不能再被使用的请求的响应中使用，比如D LETE和某些情况下的POST。与响应一起返回的负载（如果有的适）是相应动作的结果 表征。 这个响应是不可缓存的。然而,缓存应将删除的资源的任何存储响应标记为非新。

8.10.2客户端错误4. xx

由于一个或多个无法识别或畸形选项，该请求无法被服务器理解。客户端如果不做任何修改， 则不能重复发送请求。 d)4.03禁止 类似HTTP403"禁止”。 e）4.04未找到 类似HTTP404“未找到”。 f)）4.05方法不允许 类似HTTP405“方法不允许”，但是没有相对应的“允许”头部字段。 g 4.06不可接受 类似HTTP406不可接受”，但是没有响应实体。 h）4.12先决条件失败 类似HTTP412“先决条件失败”。 i）4.13请求实体太大 类似HTTP413“请求实体太大”。 响应应包括Size1选项（8.11.11)，Sizel选项用以指示请求实体的服务器能够并且愿意处理的 最大尺寸，除非服务器不能提供这些信息的状态。 4.15不受支持的内容格式 类似HTTP415“不受支持的媒体类型”

8.10.3服务器错误5.xx

8.10.4响应代码列表

当前定义的响应代码如表4所示。

8.11.1可选项概述

GB/Z41294—2022

8.11.5Accept

ETag as a Request Opti

二个端点之前如果从资源中获得过1个或多个表征，并且通过这些表征获取了ETag响应选项，可 以在一个GET请求中指明1个或多个缓存响应的ETag选项。 如果给出的ETag之中有一个是当前表征获得的实体标签，即是有效的，那么服务器可以发送一条 2.03有效响应来代替2.05内容响应；这个2.03有效响应将在返回的响应选项中返回这个特定的ETag。 实际上，客户端可以决定任意存储的表征是否是当前的而无需再次传输。 在一个请求中ETag选项可能出现零次，一次或多次，

8.11.10ConditionalRequestOptions

ConditionalRequestOptions使客户端能够请求服务器当前仅当选项指定的某个条件被满足 请求进行处理。

GB/Z 412942022

8.11.11Size1 Option

9.1CoAPURI概速

9.2CoAPURI方案

9.3coapsURI方案

9.4规范化和比对规则

9.5将URI分解成可选项

9.6将可选项组合成URI

10.2.2“ct属性

GB/Z41294—2022

[11.1 组播的意义

CoAP支持把请求发送到一个IP组播组。这是由一系列增量到单播CoAP定义的。 CoAP终端，为它们想要其他终端能够找到并使用组播服务发现提供服务，他们加入一个或多个合 适的全CoAP节点组播地址，并监听CoAP默认端口。需要注意的是一个终端可能会收到其他组播地 止的组播请求，包括全节点的IPv6地址（或通过IPv4的广播地址）；因此终端应准备好接收这样的信 息，但如果组播服务发现并不是期望的，也可以忽略他们

[11.3请求/响应层

当一台服务器意识到请求通过组播到达时，服务器可能总是忽略这个请求，尤其是当它没有任何有 效的响应时（例如，如果它只有一个空负载或错误响应）。这样的决定可能依赖于应用程序。 如果一台服务器确实决定响应组播请求，它不应立即响应。相反，它应挑选一个它打算响应的持续 时间段。为了阐述，我们称这个时间的长度为空闲期（Leisure）。空闲期的具体值可以取决于具体的应 用，或如下文所述导出。服务器应在选择的空闲期内挑选一个随机的时间点发回单播响应给组播请求。 如果接下来的响应需要在同一个组播地址的成员中发送，新的空闲期可以在前一个完成后最早启动。 为了计算空闲期的值，服务器应有一个群体规模估值G，一个目标数据传输速率R（这两者都应谨 慎选择）和一个估计的响应大小S，粗略的空闲期的下限值可以这样计算：

IbLeisure=S*G/R

GB/Z41294—2022

供协议原语进行认证或授权；当需要进行认证时，它可以是由通信的安全提供（即IPsec或DTLS)或是 由对象安全提供（在负载中）。需要授权的特定操作设备需要这两种形式的安全模式之一。必要地，如 果涉及中间中介，只有当中间中介是信任关系时，通信安全才会生效；COAP没有提供一种转发不同的 授权级别的方式，客户端有该权限与中间中介到更深一层中间中介或者原始服务器进行通信。因此，可 能需要在第一个中间中介执行所有授权。

12.2.1DTLS的使用方式

就像HTTP协议基于TCP协议使用传输层安全（TLS)保证安全，COAP基于UDP协议使用Da mTLS(DTLS)(IETFRFC6347)保证安全（见图10）。本节定义CoAP绑定DTLS，同时，定义 于受限环境的最小的托管实现配置。绑定是由单播COAP的一系列增量定义的。实际上，DTI LS与其处理UDP传输中的不可靠性的附加功能组成的

图10响应代码的结构

端点可作为CoAP客户端，也可作为DTLS的客户端。它应当向服务器适当的端口 DTLS握手完成后，客户端可以初始化第一个COAP请求。所有COAP信息应被作为DTLS“应用程 序数据”发送。 下面的规则用于映射一个ACK或RST到CON消息或者一个RST到NON消息，DTLS会话应 相同，且epoch应相同。 当消息在同一个DTLS会话和epoch中发送时，它们是相同的，有着同样的消息ID。

TLS握手完成后，客户端可以初始化第一个COAP请求。所有COAP信息应被作为DTLS“应用程 宇数据”发送。 下面的规则用于映射一个ACK或RST到CON消息或者一个RST到NON消息，DTLS会话应 目同，且epoch应相同。 当消息在同一个DTLS会话和epoch中发送时，它们是相同的，有着同样的消息ID。

GB/Z412942022

注：当一个可确认消息被重发，每一次尝试重发都会使用一个新的DTLS序列号，即使CoAP消息ID保持不变。 因此，接收端不得不如5.5所述执行重复数据删除。重传不能跨过epoch执行。 在RawPublicKey和证书模式下的DTLS连接设置成使用互相认证，使它们能够在将来任何一个 方向的消息交换中能够保持并重用。当设备需要恢复资源的时候，它们可以断开DTLS连接，但是通 常来说，设备应尽可能长的保持连接状态。在每个CoAP消息交换后断开DTLS连接是非常低效的。

12.2.3请求/响应层

下面的规则用来响应一个请求。DLTS会话应相同，且epoch应相同。 这意味着对于DTLS安全请求的响应，应总是DLTS安全的，即使用相同的安全会话和epoch。任 何试图向DTLS请求做出NoSec响应的尝试都被简单地认为请求不匹配（除非它确实匹配一个无关的 NoSec请求）因此应被拒绝

12.2.4.1端点命名

设备应支持服务器名称指示（SNI)来表示，如IETFRFC6066中第4章定义的它们在SNI主 段中的认证名。这是必要的，这样当一台主机作为多个认证方的虚拟服务器接收新的DTLS 寸，它知道哪些密钥用于DTLS会话。

12.2.4.2预共享密销

2021.5.28-万科施工现场品质管理制度（土建部分），117页PDF下载！.pdf12.2.4.3原始公钥证书

12.2.4.3.1概述

12.2.4.4X.509证书

GB/Z412942022

13CoAP与HTTP协议转换代理

13.1转换代理的意义

PUT方法要求代理更新或创建HTTP资源，该资源由请求URI来封闭表示。 如果请求URI创建了新资源，应向客户端返回响应代码2.01的响应。如果已存在的资源调整， 复成功完成的响应，

13.2.4 DELETE

DELETE方法要求代理删 务器的请求URI辨别。 如果执行成功或者该资源在请求时 应回复响应代码2.02的响应JG∕T 28-1999 升运式铲运机 铲斗容量标定，