标准规范下载简介
GB／Z 41294-2022 物联网应用协议 受限应用协议(CoAP)技术要求.pdfCoAP请求包括：应用到资源的方法、资源的标 于该请求的可选的元数据。 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)
8.8.2代理操作（ProxyOperation）
基于代理接收到的请求，它通常 目的地址的请求的潜在请求参数。这 钟方式为转发代理做了详细说明，但可能依赖于反向代理的具体配置。特别是，反向代理的客户端通常 并不为目的地址指示一个定位器，迫使反向代理需要有某种形式的名称空间翻译。然而，代理服务器
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预共享密销
12.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的响应，
POST方法要求代理代表封闭在HTTP源服务器上执行的请求。POST方法执行的实际功能 务器辨别并取决于由请求URI辨别的资源。 如果POST方法执行的动作并不影响资源，则应回复响应代码2.04的响应。如果资源在源服务 建，则应回复响应代码2.01的响应
如果HTTP请求的请求行包含“coap”或者“coaps”URI，则要求接收HTTP端点执行由CoAP资 源请求的方法定义的操作，并向客户端返回结果。 本条定义了对于任何HTTP请求GB50328-2019建设工程文件归档规范(1).pdf，代理都应给予HTTP响应。除非其他规范规定，所有语句都是 推荐行为；一些高度受限的实现可能需要使用捷径。如何满足请求的需要是实现细节，最理想的是代理 翻译并向CoAP源服务器前传请求。在13.1中介绍了在CoAP资源上执行单个CoAP方法的意义。 如果代理不能或不想处理CoAPURI的请求，可以向客户端回复响应代码为505的响应。如果代 理需要第三方处理响应，且无法在合理时间片内得到结果，可以向客户端回复响应代码为504的响应； 得到结果但无法识别，则回复响应代码为502的响应
13.3.2QPTION和TRACE
因为CoAP协议不支持OPTION和 户端回复501的错误响应。 .3GET GET方法要求代理代办CoAP资源回复消息
GET方法要求代理代办CoAP资源回复消息
PUT方法要求代理更新或创建CoAP资源，该资源由请求URI来封闭表示。 如果请求行创建了新的资源，需向客户端回复201的响应。如果已存在的资源修改，则需要 00或者204的响应，指出请求已成功。
13.3.7DELETE
13.3.8CONNECT
208米超高层综合楼施工组织设计(争创鲁班奖)GB/Z41294—2022
GB/Z41294—2022