ICS33.040 CCS M32 中华人民共和国国家标准化指导性技术文件 GB/Z41294—2022 物联网应用协议 受限应用协议（CoAP)技术要求 Internet of thing (IoT) application protocol- Technical requirements of the constrained application protocol (CoAP) 2022-10-01实施 2022-03-09发布 国家市场监督管理总局 发布 国家标准化管理委员会 GB/Z41294—2022 目 次 前言 1 范围 2 规范性引用文件 3 术语和定义 缩略语 业务特征 5 5.1 概述 5.2 消息模型 5.3 请求/响应模型 5.4 中介与缓存 5.5 资源发现 消息格式 6.1 基本格式 6.2 可选项格式 6.3 可选项值格式 7 消息传送方式 7.1 基本方式 7.2 消息与端点 7.3 消息可靠传送 7.4 消息不可靠传送 7.5 消息相关性 7.6 数据重复 7.7 消息大小· 7.8 拥塞控制 10 7.9 传送参数 10 8 请求/响应语义 12 8.1 概述 8.2 请求 12 8.3 响应 13 8.4 请求/响应匹配 14 8.5 可选项 15 8.6 负载与表示 17 8.7 缓存 18 8.8 代理 19 8.9 方法定义 21 8.10 响应代码定义 21 GB/Z41294—2022 8.11 可选项定义 25 9 CoAPURI 28 9.1 CoAPURI概述 28 9.2 CoAPURI方案... 9.3 coapsURI方案 29 9.4 规范化和比对规则 29 9.5 将URI分解成可选项 9.6 将可选项组合成URI 30 10 发现 31 10.1 服务发现 31 10.2 资源发现 31 11 组播 32 11.1 组播的意义 32 11.2 消息层 32 11.3 请求/响应层 32 12 安全 33 12.1 安全概述 33 12.2 DTLS-secured CoAP 34 13CoAP与HTTP协议转换代理 37 13.1转换代理的意义 37 13.2CoAP-HTTP代理 37 13.3HTTP-CoAP代理 参考文献 40 II GB/Z41294—2022 前言 本文件按照GB/T1.1一2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定 起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任， 本文件由中华人民共和国工业和信息化部提出， 本文件由全国通信标准化技术委员会（SAC/TC485）归口。 本文件起草单位：中国信息通信研究院、北京邮电大学。 本文件主要起草人：付国强、罗松、黄小红。 GB/Z41294—2022 物联网应用协议 受限应用协议（CoAP）技术要求 1范围 本文件规定了受限应用协议技术要求，主要内容包括：受限应用协议概述和业务特征、受限应用协 议的消息格式、受限应用协议的消息传送方式等。 本文件适用于受限应用协议的设备。 2规范性引用文件 2 本文件没有规范性引用文件 术语和定义 3 下列术语和定义适用于本文件。 3.1 端点 endpoint CoAP中的参与实体。 3.2 令牌token 用于匹配单一申请与其响应的字段。 3.3 发送者 sender 消息的源端点。 3.4 接收者 recipient 消息的目的端点。 3.5 客户端 client 请求消息的源端点，响应消息的目的端点。 3.6 服务器 server 请求消息的目的端点，响应消息的源端点。 3.7 源服务器 originserver 存储或者创建给定资源的服务器。 3.8 中介 intermediary 既作为服务器又作为源服务器（或远端中介）的客户端的实体 1 GB/Z41294—2022 3.9 转发代理 里forward-proxy 客户端无法直接请求服务器的情况下，为了实现在客户端和服务器间请求和响应的转发，而设置的 中间转发节点。 3.10 反转代理 reverse-proxy 为了代理一个或多个其他服务器接收并满足客户端请求，而设置的中间节点。 注：区别于转发代理，客户端可能感知不到反转代理的存在。 3.11 CoAP-to-CoAP代理 CoAP-to-CoAPproxy 映射CoAP请求到CoAP请求的代理。 3.12 协议转换代理 cross-proxy 为使系统中不同协议之间能够互联互通，提供多个协议之间转换的代理。 3.13 带响应 piggy-backedresponse 为了减少简单响应的复杂程度，而在CoAPACK消息当中增加响应内容的方式 3.14 资源发现 resource discovery 资源请求者获取资源拥有者地址列表的过程。 4缩略语 下列缩略语适用于本文件。 CoAP：受限应用协议（ConstrainedApplicationProtocol) CON：需确认消息（Confirmablemessage) DTLS：数据报传输层安全协议（DatagramTransportLayerSecurity） IETF：互联网工程任务组（InternetEngineeringTaskForce） IPv4：互联网协议第4版本（InternetProtocolVersion4） ITU：国际电信联盟（InternationalTelecommunicationsUnion） NON：不需确认消息（Non-confirmablemessage) REST：表征性状态转移（RepresentationalStateTransfer） TCP：传输控制协议（TransmissionControlProtocol) TLS：安全传输层协议（TransportLayerSecurity） UDP：用户数据包协议（UserDatagramProtocol） XMPP：可扩展消息和出席信息协议（TheExtensibleMessagingandPresenceProtocol) 5 业务特征 5.1概述 CoAP协议是一种满足受限环境特殊要求的通用web协议，其应用领域集中在能源、建筑和其他 M2M应用。CoAP协议并不是对HTTP协议的简单压缩，而是符合REST要求的HTTP协议的子 集，该子集适用于M2M应用。尽管CoAP协议是简化了的HTTP协议，但其更重要的作用是提供 2 GB/Z41294—2022 M2M需要的内置发现、组播支持和异步通信的功能 合，该协议满足M2M对组播、低负载和精简的要求。 CoAP的交互模型类似于HTTP协议的客户端/服务器模型。而M2M交互要求CoAP实体扮演 用于请求一个动作（方法编号）或者资源（URI）。服务器返回响应码，该响应可能包括资源状态转移。 CoAP在处理异步交互时使用诸如UDP协议的面向数据报的传输方式。这种消息一般是依靠支 持可靠传递（可选）的消息层来实现。CoAP协议定义了四种消息：需确认消息（Confirmable），不需确 认消息（Non-confirmable），ACK消息（Acknowledgement），重置消息（Reset）；方法码和响应码包含在 上述消息当中，携带请求或响应消息。这四种类型消息的基础交互与请求/响应交互正交，请求消息可 以在需确认消息和不需确认消息中携带，而响应消息可以在ACK消息中挡带。 5.2消息模型 CoAP消息模型建立在端点之间基于UDP消息传递的基础上。 CoAP协议使用定长二进制头（4字节），之后可以增加精简二进制可选项和负载。CoAP消息格式 在第6章中定义。每个消息都包含消息ID用于消息重复检测和可靠性选项。 可靠性保证是通过将消息标记为需确认消息来实现的（CON）。需确认消息在收到ACK消息之前 按默认定时器重传，重传时使用相同的Messageid。其流程如图1所示。 Client Server CON ACK 图1可靠消息传递 ACK消息。 当消息不需要可靠传递时，虽然不需要ACK消息，但是Messageid仍是必不可少的。其流程如 图2所示。当接收方无法处理该消息时，则回复一个RST消息。 Client Server NON 图2不可靠消息传递 3 GB/Z41294—2022 CoAP协议基于UDP协议，所以其支持组播。在第1O章当中具体介绍具体的组播处理。 第11章中定义了安全模型，范围从无安全保护到基于信用的安全保护。 5.3请求/响应模型 CoAP消息携带请求和响应消息语义，或者是方法代码及响应代码，其中可选的请求或响应信息， 如URI和负载媒体类型都被看作是可选项。在底层消息中，单个请求消息与其响应很难做到一一对 应，这时就通过引入令牌（Token）从底层消息中匹配请求和响应。令牌与Messageid不同，Messageid 是消息的唯一标识，而令牌则用于匹配请求与响应 请求消息由需确认消息或者不需确认消息承载，对应的响应消息由结果ACK消息承载。这种形 式称之为挡带消息，详见8.3.2。（不需要独立的ACK消息来传递挡带消息，因为如果ACK消息丢失， 客户端会重新发起一次请求。）以下是两个Get请求，以及挡带消息响应，流程如图3所示。 Client Server Clicent Server CON CON GET Content GETContent ACK ACK 2.05Content 4.04NotFound 图3需确认消息中的挡带响应 如果服务器不能及时响应一个需确认消息请求，其只需要回