YD/T 3241-2017
基本信息
标准号： YD/T 3241-2017
中文名称：受限应用协议(CoAP)技术要求
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：4771664
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 3241-2017.Technical requirements for constrained application protocol (CoAP).
1范围
YD/T 3241规定了受限应用协议技术要求，主要内容包括:受限应用协议概述和业务特征、受限应用协议的消息格式、受限应用协议的消息传送方式、请求响应语义和组播问题等。
YD/T 3241适用于使用受限应用协议的设备。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC 3986统一资 源标识符:通用语法(Uniform Resource Identifier: Generic Syntax )
IETF RFC 4492椭圆 曲线密码体制传输层安全加密套件(Elliptic Curve Cryptography Cipher Suites for Transport Layer Security)
IETF RFC 5246传 输层安全协议(The Transport Layer Security Protocol)
IETF RFC 6690受限 RESTful环境链接格式(Constrained RESTful Environments Link Format)
3缩略语、 术语和定义
3.1 缩略语
下列缩略语适用于本文件:
CoAP 受限应用协议 Constrained Application Protocol
CON 需确认消息 Confirmable message
DTLS 数据包传输层安全协议 Datagram Transport Layer Security
ECDSA 椭圆曲线数字签名算法 Elliptic Curve Digital Signature Algorithm
1范围
YD/T 3241规定了受限应用协议技术要求，主要内容包括:受限应用协议概述和业务特征、受限应用协议的消息格式、受限应用协议的消息传送方式、请求响应语义和组播问题等。
YD/T 3241适用于使用受限应用协议的设备。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC 3986统一资 源标识符:通用语法(Uniform Resource Identifier: Generic Syntax )
IETF RFC 4492椭圆 曲线密码体制传输层安全加密套件(Elliptic Curve Cryptography Cipher Suites for Transport Layer Security)
IETF RFC 5246传 输层安全协议(The Transport Layer Security Protocol)
IETF RFC 6690受限 RESTful环境链接格式(Constrained RESTful Environments Link Format)
3缩略语、 术语和定义
3.1 缩略语
下列缩略语适用于本文件:
CoAP 受限应用协议 Constrained Application Protocol
CON 需确认消息 Confirmable message
DTLS 数据包传输层安全协议 Datagram Transport Layer Security
ECDSA 椭圆曲线数字签名算法 Elliptic Curve Digital Signature Algorithm
标准图片预览
标准内容
ICS33.040
中华人民共和国通信行业标准
YD/T3241—2017
受限应用协议（CoAP）技术要求Technical requirements for constrained application protocol (CoAP)2017-04-12发布
中华人民共和国工业和信息化部2017-07-01实施
2规范性引用文件
3缩略语、术语和定义
3.1缩略语
3.2术语和定义
业务特征..
消息模型
请求/响应模型
中介与缓存
资源发现.
5消息格式.
5.1基本格式...
可选项格式..
可选项值格式，
消息传送方式.
基本方式.
消息与端点，
消息可靠传送.
消息不可靠传送
消息相关性
数据重复，
消息大小．
拥塞控制.
传送参数，
请求/响应语义
请求/响应匹配
可选项，
负载与表示
..........
YD/T3241—2017
YD/T3241—2017
7.7缓存.
7.8代理.
7.9方法定义
7.10响应代码定义
7.11可选项定义
CoAPURI
8.1CoAPURI概述，
8.2CoAPURI方案.
coapsURI方案．
规范化和比对规则
8.5将URI分解成可选项。
8.6将可选项组合成URI.
服务发现，
9.2资源发现.
10组播.
组播的意义。
消息层
10.3请求/响应层
11安全．
11.1安全概述．
11.2DTLS-securedCoAP
12CoAP与HTTP协议转换代理
12.1转换代理的意义
12.2CoAP-HTTP代理..
12.3HTTP-CoAP代理..
本标准是受限应用协议系列标准之一，该系列标准的名称及结构如下：一《受限应用协议（CoAP）技术要求》一《受限应用协议（CoAP）测试方法》本标准按照GB/T1.1一2009给出的规则起草。YD/T3241—2017
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中国信息通信研究院、北京邮电大学。本标准主要起草人：付国强、罗松、黄小红。III
1范围
受限应用协议（CoAP）技术要求YD/T3241—2017
本标准规定了受限应用协议技术要求，主要内容包括：受限应用协议概述和业务特征、受限应用协议的消息格式、受限应用协议的消息传送方式、请求响应语义和组播问题等。本标准适用于使用受限应用协议的设备。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC3986统一资源标识符：通用语法（UniformResourceIdentifier：GenericSyntax）IETFRFC4492椭圆曲线密码体制传输层安全加密套件（EllipticCurveCryptographyCipherSuitesforTransportLayerSecurity)IETFRFC5246传输层安全协议（TheTransportLayerSecurityProtocol）IETFRFC6690受限RESTful环境链接格式（ConstrainedRESTfulEnvironmentsLinkFormat）3缩略语、术语和定义
3.1缩略语
下列缩略语适用于本文件：
受限应用协议
需确认消息
数据包传输层安全协议
椭圆曲线数字签名算法
超文本传输协议
因特网控制报文协议
互联网工程任务组
因特网协议
互联网协议第4版本
Constrained Application ProtocolConfirmable message
Datagram Transport Layer SecurityEllipticCurveDigitalSignatureAlgorithmHyperText Transfer Protocol
Internet Control Message ProtocolIdentification
Internet Engineering TaskForceInternet Protocol
Internet Protocol Version 4
YD/T3241—2017
3.2术语和定义
国际电信联盟
机器与机器
最大传输单元
不需确认消息
表征性状态转移
流控制传输协议
短信息服务
服务器名称指示
传输控制协议
安全传输层协议
用户数据包协议
统一资源标识符
可扩展消息和出席信息协议
下列术语和定义适用于本文件：3.2.1
端点endpoint
CoAP中的参与实体。
令牌token
用于匹配单一申请与其响应的字段。3.2.3
发送者sender
消息的源端点。
接收者recipient
消息的目的端点。
客户端client
请求消息的源端点，响应消息的目的端点。2
International Telecommunications UnionMachine to Machine
Maximum Transmission Unit
Non-confirmable message
Representational StateTransferStreamControlTransmissionProtocolShort Message Service
Server Name Indication
Transmission Control ProtocolTransport Layer Security
User Datagram Protocol
UniformResource Identifier
The Extensible Messaging and Presence Protocol3.2.6
服务器server
请求消息的目的端点，响应消息的源端点。3.2.7
源服务器 originserver
给定资源所在或产生的服务器。3.2.8
中介intermediary
主要用于转发请求和中继响应，可能有缓存、名字空间转换、协议转换的功能、3.2.9
代理proxy
YD/T3241—2017
不实现特定的应用语义。根据代理在消息转发结构中的位置，一般有两种形式的代理：转发代理和反转代理。
转发代理forward-proxy
由客户端选取的端点，用来代表客户端执行请求，做相应的转换工作。3.2.11
反转代理reverse-proxy
个或多个服务器之间的端点，满足这些服务器的请求执行要求。与转发代理不同，客户端可能不知道反转代理的存在。
CoAP-to-CoAP代理coAP-to-CoAPproxy从CoAP请求映射到CoAP请求的代理。3.2.13
协议转换代理cross-proxy
在多个协议之间进行转换的代理。3.2.14
挡带响应piggy-backedresponse包含在CoAPACK消息当中。
YD/T3241—2017
资源发现resourcediscovery
客户端向服务器请求其拥有的资源的过程。4业务特征
4.1概述
CoAP协议是一种满足受限环境特殊要求的通用web协议，其应用领域集中在能源、建筑和其他M2M应用。CoAP协议并不是对HTTP协议的简单压缩，而是符合REST要求的HTTP协议的子集，该子集适用于M2M应用。尽管CoAP协议是简化了的HTTP协议，但其更重要的作用是提供M2M需要的内置发现、组播支持和异步通信的功能。本标准定义了受限应用协议（CoAP），该协议可以直接转换为HTTP协议从而方便与现有web进行整合，该协议满足M2M对组播、低负载和精简的要求。CoAP的交互模型类似于HTTP协议的客户端/服务器模型。而M2M交互要求CoAP实体扮演客户端和服务器两种角色。CoAP请求相当于HTTP请求，是由客户端发送给服务器的消息，该消息用于请求一个动作（方法编号）或者资源（URI）。服务器返回响应码，该响应可能包括资源状态转移。CoAP在处理异步交互时使用诸如UDP协议这类的面向数据包的传输方式。这种消息一般是依靠支持可靠传递（可选）的消息层来实现。CoAP协议定义了四种消息：需确认消息（Confirmable），不需确认消息（Non-confirmable），ACK消息（Acknowledgement），重置消息（Reset）：方法码和响应码包含在上述消息当中，携带请求或响应消息。这四种类型消息的基础交互与请求/响应交互正交，请求消息可以在需确认消息和不需确认消息中携带，而响应消息可以在ACK消息中挡带。4.2消息模型
CoAP消息模型建立在端点之间基于UDP的消息传递的基础上。CoAP协议使用定长二进制头（4字节），之后可以增加精简二进制可选项和负载。CoAP消息格式在第五章中定义。每个消息都包含消息ID，用于消息重复检测和可靠性选项。可靠性保证是通过将消息标记为需确认消息（CON）来实现的。需确认消息在收到ACK消息之前按默认定时器重传，重传时使用相同的MessageID。其流程如图1所示。客户端
服务器
图1可靠消息传递
YD/T3241—2017
如果接收方无法处理需确认消息（甚至不能回复错误的ACK消息），则回复一个RST消息替代ACK消息。
当消息不需要可靠传递时，虽然不需要ACK消息，但是MessageID仍是必不可少的。其流程如图2所示。当接收方无法处理该消息时，则回复一个RST消息。客户端
服务器
图2不可靠消息传递
CoAP协议基于UDP协议，所以其支持组播。在第10O章当中介绍具体的组播处理。第11章当中定义了安全模型，范围从无安全保护到基于信用的安全保护。4.3请求/响应模型
CoAP消息携带请求和响应消息语义，或者是方法代码或者是响应代码，其中可选的请求或响应信息，如URI和负载媒体类型都被看作是可选项。在底层消息中，单个请求消息与其响应很难做到一一对应，这时就引入了令牌（Token），令牌的作用是从底层消息中匹配请求和响应。令牌与MessageID不同，MessageID是消息的唯一标识，而令牌则用于匹配请求与响应。请求消息由需确认消息或者不需确认消息承载，对应的响应消息由结果ACK消息承载。这种形式称之为挡带消息，详见7.3。（不需要独立的ACK消息来传递带消息，因为如果ACK消息丢失，客户端会重新发起一次请求。）以下是两个Get请求，以及挡带消息响应，流程如图3所示。客户端
服务器
客户端
GETConten
04 Not Enung
图3需确认消息中的挡带响应
服务器
如果服务器不能及时响应一个需确认消息请求，其只需要回复一个空的ACK消息，通过这种方式客户端可以停止发送该请求。响应消息处理完成之后，服务器会发起一个新的需确认消息（这时需要客户端回ACK消息）。一般称呼这种情况为分离消息（separateresponse），其流程如图4所示。详见7.3。
YD/T3241—2017
客户端
CON(token)
GETContent
CON(token
2.05Content
服务器
图4需确认消息中的分离消息
如果请求消息是以不需确认消息的形式发出的，其响应消息也要以不需确认消息来发送。流程如图5所示。
客户端
NeNCoren
NON(token)
2.05Canten
服务器
图5不需确认消息的请求与响应
CoAP使用GET，PUT，POST和DELETE方法，其语义定义见7.9在这四种基础方法上建立的其他方法可以添加到CoAP协议当中。新的方法不需要以请求、响应对的形式出现。单一的请求消息也可能有多个响应消息，比如组播请求。URI支持在服务器中简化，因为客户端已经解析了URI并且将其分解为主机、端口、路径以及查询组件，利用默认值来提高效率。响应代码由HTTP响应代码的子集和CoAP定义的响应代码组成，其定义见7.10。
4.4中介与缓存
协议支持响应缓存以满足请求的效率要求。简单缓存使CoAP响应中携带的信息新鲜，有效。缓存可以在端点中，也可以在中介当中。缓存功能见7.7。代理在受限网络当中有很重要的意义，包括网络流量限制、性能增强、接入休眠设备等方面。协议支持由代理代表其他CoAP端点发送请求。当使用代理时，请求中包含请求资源的URI，目的地址填写代理的地址。7.8中有代理功能的详细描述。CoAP协议使用REST风格设计，因此其外在功能与HTTP相似，所以CoAP和HTTP的互相映射具有天然优势。这种映射可以用基于CoAP的HTTPREST接口实现，或者在HTTP与CoAP之间转换。这种转换可以利用协议转换代理实现，其功能是转换方法、响应代码、媒体类型及其他可选项到相应的HTTP特征。第12章介绍了HTTP映射。4.5资源发现
在M2M应用中，资源发现是很重要的功能。第9章中讨论这个问题。6
5消息格式
5.1基本格式
YD/T3241—2017
CoAP协议是建立在基于UDP的压缩消息交互基础上的。CoAP应用了数据包传输层安全协议（DTLS）。CoAP也可以使用SMS，TCP或者SCTP来作为传输协议，但这些应用超出了本文的范围。CoAP消息以简单二进制形式编码。其消息格式以定长4字节消息头开始。之后是0~8字节的可变长的令牌值。之后是一排O或者可选的类型、长度、值格式（TLV，Type-Length-Value），如有负载，负载将占据数据包的其他部分。消息格式如图6所示。MaTKL
Token（有条件可选）
Option（有条件可选
MessagelID
负载标记负载（有条件可选）
图6消息格式
图6所示的消息头定义如下：
版本（V)：2bit无符号整数。指出了CoAP的版本号。如果执行本标准，该参数应为1。其他值为保留值。该字段不正确时，消息直接予以抛弃。类型（T)：2bit无符号整数。消息如果为需确认消息该值为0，如果为不需确认消息该值为1，ACK消息该值为2，RST消息该值为3。消息类型的语义见第7章。令牌长度（TKL）：4bit无符号整数。指出了可变长令牌的长度。其中9~15位为保留字段，不可发送，如果接收到按消息格式错误处理。编码（Code）：8bit无符号整数，前三位为类型，后5位为内容。如记录入c.dd时，c为前三位代表的0~7之中的一个，dd为后五位代表的00~31中的一个。类型中，0代表请求，1代表成功响应，4代表客户端失败响应，5为服务器失败响应，其他值为保留值。特殊情况，0.00为空消息。消息为请求消息时，其值为内容请求方法；消息为响应消息时，其值为响应代码。所有可能的值见CoAP代码注册表。请求、响应的语义见第7章。MessageID：16bit无符号整数，以网络顺序排序。用于检测消息是否重复，同时用来匹配需确认消息的ACK和不需确认消息的RST消息。产生与匹配规则见第6章。消息头之后跟的是令牌值，0~8字节长，由令牌长度字段定义。令牌值用来匹配请求，响应消息。产生于匹配方式见7.4。
消息头、令牌之后可以为全0或者其他可选项。可选项之后可以为消息结尾或者一个负载标记及负载。
消息头、令牌、可选项之后就是可选项负载。如果存在非零负载，其由一个固定前缀标记，1字节的负载标记（OxFF），意味着可选项的结束和负载的开始。负载数据从标记开始直到UDP报文结尾。无负载标记意味着负载长度为0。有负载标记而无负载应按照格式错误消息执行。7
YD/T3241—2017bzxz.net
5.2可选项格式
CoAP定义了一些可以被包含在消息当中的可选实例。消息中的每个可选实例都指定了CoAP可选项中定义的可选项数量，可选项长度和可选项本身。与直接定义可选项数不同，实例必须以可选项数+增量的形式顺序出现：可选项数的计算方法是增量加上消息运行的实例的可选项数。消息中的第一个实例，其计算可选项数时增量为0。用增量为0的方式同一个可选项可以包含多个实例。可选项数保存在CoAP可选项数注册表当中。7.5当中定义了其语义。可选项格式如图7所示。Option增量Option长度
Option增量（扩展）
Option长度（扩展）
Option值
I byte
0-2 byte
0-2 byte
O或多byte
图7可选项格式
图7所示的可选项字段定义如下：增量：4bit无符号整数。其值为0~12。其中三个值保留为特殊构造字段：●13：8bit无符号整数。初始字节之后的8bit无符号整数，其增量减去13；●14：16bit无符号整数。初始字节之后的按网络字节顺序的16bit无符号整数，其增量减269：●15：为负载标识保留。如果该值已设置但是非负载标识，应按照格式错误处理。结果增量是本可选项的可选项数与之前可选项的不同之处，可选项数是前一个可选项数加上增量计算得来的。
可选项长度：4bit无符号整数。可选项值的长度（字节），其值为0~12。其中三个值保留为特殊构造字段：
●13：8bit无符号整数。在可选项值之前，表示其可选项长度减去13；●14：16bit无符号整数。在可选项值之前按网络顺序排列，表示其可选项长度减去269；●15：保留位。如果该值已设置，应按照格式错误处理。值：完全的可选项长度（字节）序列。可选项值的长度和格式取决于可选项本身，可以是不同的长度值。本标准应用格式见4.3。其他标准定义的可选项可以用作其他可选项值格式。5.3可选项值格式
本标准中定义的可选项应用以下可选项值格式。空：长度（字节）为0的序列。
不透明：未知长度（字节）的序列。单元：代表用可选项长度学段值排序的非负整数。可选项定义可以定义一组授权字节号码：如果可选，发送方应用尽可能少的字节来表示该号码，如，不带引导的0字节。例如，数字0表示空可选项值，数字1用一个数值为1的字节代表（00000001）。接收方应能够正确执行引导的0字节消息。开发提示：在模板中用固定大小可选项的模板实现（硬件实现）时，会严格限制发送方异常行为。o
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T3241—2017
受限应用协议（CoAP）技术要求Technical requirements for constrained application protocol (CoAP)2017-04-12发布
中华人民共和国工业和信息化部2017-07-01实施
2规范性引用文件
3缩略语、术语和定义
3.1缩略语
3.2术语和定义
业务特征..
消息模型
请求/响应模型
中介与缓存
资源发现.
5消息格式.
5.1基本格式...
可选项格式..
可选项值格式，
消息传送方式.
基本方式.
消息与端点，
消息可靠传送.
消息不可靠传送
消息相关性
数据重复，
消息大小．
拥塞控制.
传送参数，
请求/响应语义
请求/响应匹配
可选项，
负载与表示
..........
YD/T3241—2017
YD/T3241—2017
7.7缓存.
7.8代理.
7.9方法定义
7.10响应代码定义
7.11可选项定义
CoAPURI
8.1CoAPURI概述，
8.2CoAPURI方案.
coapsURI方案．
规范化和比对规则
8.5将URI分解成可选项。
8.6将可选项组合成URI.
服务发现，
9.2资源发现.
10组播.
组播的意义。
消息层
10.3请求/响应层
11安全．
11.1安全概述．
11.2DTLS-securedCoAP
12CoAP与HTTP协议转换代理
12.1转换代理的意义
12.2CoAP-HTTP代理..
12.3HTTP-CoAP代理..
本标准是受限应用协议系列标准之一，该系列标准的名称及结构如下：一《受限应用协议（CoAP）技术要求》一《受限应用协议（CoAP）测试方法》本标准按照GB/T1.1一2009给出的规则起草。YD/T3241—2017
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中国信息通信研究院、北京邮电大学。本标准主要起草人：付国强、罗松、黄小红。III
1范围
受限应用协议（CoAP）技术要求YD/T3241—2017
本标准规定了受限应用协议技术要求，主要内容包括：受限应用协议概述和业务特征、受限应用协议的消息格式、受限应用协议的消息传送方式、请求响应语义和组播问题等。本标准适用于使用受限应用协议的设备。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC3986统一资源标识符：通用语法（UniformResourceIdentifier：GenericSyntax）IETFRFC4492椭圆曲线密码体制传输层安全加密套件（EllipticCurveCryptographyCipherSuitesforTransportLayerSecurity)IETFRFC5246传输层安全协议（TheTransportLayerSecurityProtocol）IETFRFC6690受限RESTful环境链接格式（ConstrainedRESTfulEnvironmentsLinkFormat）3缩略语、术语和定义
3.1缩略语
下列缩略语适用于本文件：
受限应用协议
需确认消息
数据包传输层安全协议
椭圆曲线数字签名算法
超文本传输协议
因特网控制报文协议
互联网工程任务组
因特网协议
互联网协议第4版本
Constrained Application ProtocolConfirmable message
Datagram Transport Layer SecurityEllipticCurveDigitalSignatureAlgorithmHyperText Transfer Protocol
Internet Control Message ProtocolIdentification
Internet Engineering TaskForceInternet Protocol
Internet Protocol Version 4
YD/T3241—2017
3.2术语和定义
国际电信联盟
机器与机器
最大传输单元
不需确认消息
表征性状态转移
流控制传输协议
短信息服务
服务器名称指示
传输控制协议
安全传输层协议
用户数据包协议
统一资源标识符
可扩展消息和出席信息协议
下列术语和定义适用于本文件：3.2.1
端点endpoint
CoAP中的参与实体。
令牌token
用于匹配单一申请与其响应的字段。3.2.3
发送者sender
消息的源端点。
接收者recipient
消息的目的端点。
客户端client
请求消息的源端点，响应消息的目的端点。2
International Telecommunications UnionMachine to Machine
Maximum Transmission Unit
Non-confirmable message
Representational StateTransferStreamControlTransmissionProtocolShort Message Service
Server Name Indication
Transmission Control ProtocolTransport Layer Security
User Datagram Protocol
UniformResource Identifier
The Extensible Messaging and Presence Protocol3.2.6
服务器server
请求消息的目的端点，响应消息的源端点。3.2.7
源服务器 originserver
给定资源所在或产生的服务器。3.2.8
中介intermediary
主要用于转发请求和中继响应，可能有缓存、名字空间转换、协议转换的功能、3.2.9
代理proxy
YD/T3241—2017
不实现特定的应用语义。根据代理在消息转发结构中的位置，一般有两种形式的代理：转发代理和反转代理。
转发代理forward-proxy
由客户端选取的端点，用来代表客户端执行请求，做相应的转换工作。3.2.11
反转代理reverse-proxy
个或多个服务器之间的端点，满足这些服务器的请求执行要求。与转发代理不同，客户端可能不知道反转代理的存在。
CoAP-to-CoAP代理coAP-to-CoAPproxy从CoAP请求映射到CoAP请求的代理。3.2.13
协议转换代理cross-proxy
在多个协议之间进行转换的代理。3.2.14
挡带响应piggy-backedresponse包含在CoAPACK消息当中。
YD/T3241—2017
资源发现resourcediscovery
客户端向服务器请求其拥有的资源的过程。4业务特征
4.1概述
CoAP协议是一种满足受限环境特殊要求的通用web协议，其应用领域集中在能源、建筑和其他M2M应用。CoAP协议并不是对HTTP协议的简单压缩，而是符合REST要求的HTTP协议的子集，该子集适用于M2M应用。尽管CoAP协议是简化了的HTTP协议，但其更重要的作用是提供M2M需要的内置发现、组播支持和异步通信的功能。本标准定义了受限应用协议（CoAP），该协议可以直接转换为HTTP协议从而方便与现有web进行整合，该协议满足M2M对组播、低负载和精简的要求。CoAP的交互模型类似于HTTP协议的客户端/服务器模型。而M2M交互要求CoAP实体扮演客户端和服务器两种角色。CoAP请求相当于HTTP请求，是由客户端发送给服务器的消息，该消息用于请求一个动作（方法编号）或者资源（URI）。服务器返回响应码，该响应可能包括资源状态转移。CoAP在处理异步交互时使用诸如UDP协议这类的面向数据包的传输方式。这种消息一般是依靠支持可靠传递（可选）的消息层来实现。CoAP协议定义了四种消息：需确认消息（Confirmable），不需确认消息（Non-confirmable），ACK消息（Acknowledgement），重置消息（Reset）：方法码和响应码包含在上述消息当中，携带请求或响应消息。这四种类型消息的基础交互与请求/响应交互正交，请求消息可以在需确认消息和不需确认消息中携带，而响应消息可以在ACK消息中挡带。4.2消息模型
CoAP消息模型建立在端点之间基于UDP的消息传递的基础上。CoAP协议使用定长二进制头（4字节），之后可以增加精简二进制可选项和负载。CoAP消息格式在第五章中定义。每个消息都包含消息ID，用于消息重复检测和可靠性选项。可靠性保证是通过将消息标记为需确认消息（CON）来实现的。需确认消息在收到ACK消息之前按默认定时器重传，重传时使用相同的MessageID。其流程如图1所示。客户端
服务器
图1可靠消息传递
YD/T3241—2017
如果接收方无法处理需确认消息（甚至不能回复错误的ACK消息），则回复一个RST消息替代ACK消息。
当消息不需要可靠传递时，虽然不需要ACK消息，但是MessageID仍是必不可少的。其流程如图2所示。当接收方无法处理该消息时，则回复一个RST消息。客户端
服务器
图2不可靠消息传递
CoAP协议基于UDP协议，所以其支持组播。在第10O章当中介绍具体的组播处理。第11章当中定义了安全模型，范围从无安全保护到基于信用的安全保护。4.3请求/响应模型
CoAP消息携带请求和响应消息语义，或者是方法代码或者是响应代码，其中可选的请求或响应信息，如URI和负载媒体类型都被看作是可选项。在底层消息中，单个请求消息与其响应很难做到一一对应，这时就引入了令牌（Token），令牌的作用是从底层消息中匹配请求和响应。令牌与MessageID不同，MessageID是消息的唯一标识，而令牌则用于匹配请求与响应。请求消息由需确认消息或者不需确认消息承载，对应的响应消息由结果ACK消息承载。这种形式称之为挡带消息，详见7.3。（不需要独立的ACK消息来传递带消息，因为如果ACK消息丢失，客户端会重新发起一次请求。）以下是两个Get请求，以及挡带消息响应，流程如图3所示。客户端
服务器
客户端
GETConten
04 Not Enung
图3需确认消息中的挡带响应
服务器
如果服务器不能及时响应一个需确认消息请求，其只需要回复一个空的ACK消息，通过这种方式客户端可以停止发送该请求。响应消息处理完成之后，服务器会发起一个新的需确认消息（这时需要客户端回ACK消息）。一般称呼这种情况为分离消息（separateresponse），其流程如图4所示。详见7.3。
YD/T3241—2017
客户端
CON(token)
GETContent
CON(token
2.05Content
服务器
图4需确认消息中的分离消息
如果请求消息是以不需确认消息的形式发出的，其响应消息也要以不需确认消息来发送。流程如图5所示。
客户端
NeNCoren
NON(token)
2.05Canten
服务器
图5不需确认消息的请求与响应
CoAP使用GET，PUT，POST和DELETE方法，其语义定义见7.9在这四种基础方法上建立的其他方法可以添加到CoAP协议当中。新的方法不需要以请求、响应对的形式出现。单一的请求消息也可能有多个响应消息，比如组播请求。URI支持在服务器中简化，因为客户端已经解析了URI并且将其分解为主机、端口、路径以及查询组件，利用默认值来提高效率。响应代码由HTTP响应代码的子集和CoAP定义的响应代码组成，其定义见7.10。
4.4中介与缓存
协议支持响应缓存以满足请求的效率要求。简单缓存使CoAP响应中携带的信息新鲜，有效。缓存可以在端点中，也可以在中介当中。缓存功能见7.7。代理在受限网络当中有很重要的意义，包括网络流量限制、性能增强、接入休眠设备等方面。协议支持由代理代表其他CoAP端点发送请求。当使用代理时，请求中包含请求资源的URI，目的地址填写代理的地址。7.8中有代理功能的详细描述。CoAP协议使用REST风格设计，因此其外在功能与HTTP相似，所以CoAP和HTTP的互相映射具有天然优势。这种映射可以用基于CoAP的HTTPREST接口实现，或者在HTTP与CoAP之间转换。这种转换可以利用协议转换代理实现，其功能是转换方法、响应代码、媒体类型及其他可选项到相应的HTTP特征。第12章介绍了HTTP映射。4.5资源发现
在M2M应用中，资源发现是很重要的功能。第9章中讨论这个问题。6
5消息格式
5.1基本格式
YD/T3241—2017
CoAP协议是建立在基于UDP的压缩消息交互基础上的。CoAP应用了数据包传输层安全协议（DTLS）。CoAP也可以使用SMS，TCP或者SCTP来作为传输协议，但这些应用超出了本文的范围。CoAP消息以简单二进制形式编码。其消息格式以定长4字节消息头开始。之后是0~8字节的可变长的令牌值。之后是一排O或者可选的类型、长度、值格式（TLV，Type-Length-Value），如有负载，负载将占据数据包的其他部分。消息格式如图6所示。MaTKL
Token（有条件可选）
Option（有条件可选
MessagelID
负载标记负载（有条件可选）
图6消息格式
图6所示的消息头定义如下：
版本（V)：2bit无符号整数。指出了CoAP的版本号。如果执行本标准，该参数应为1。其他值为保留值。该字段不正确时，消息直接予以抛弃。类型（T)：2bit无符号整数。消息如果为需确认消息该值为0，如果为不需确认消息该值为1，ACK消息该值为2，RST消息该值为3。消息类型的语义见第7章。令牌长度（TKL）：4bit无符号整数。指出了可变长令牌的长度。其中9~15位为保留字段，不可发送，如果接收到按消息格式错误处理。编码（Code）：8bit无符号整数，前三位为类型，后5位为内容。如记录入c.dd时，c为前三位代表的0~7之中的一个，dd为后五位代表的00~31中的一个。类型中，0代表请求，1代表成功响应，4代表客户端失败响应，5为服务器失败响应，其他值为保留值。特殊情况，0.00为空消息。消息为请求消息时，其值为内容请求方法；消息为响应消息时，其值为响应代码。所有可能的值见CoAP代码注册表。请求、响应的语义见第7章。MessageID：16bit无符号整数，以网络顺序排序。用于检测消息是否重复，同时用来匹配需确认消息的ACK和不需确认消息的RST消息。产生与匹配规则见第6章。消息头之后跟的是令牌值，0~8字节长，由令牌长度字段定义。令牌值用来匹配请求，响应消息。产生于匹配方式见7.4。
消息头、令牌之后可以为全0或者其他可选项。可选项之后可以为消息结尾或者一个负载标记及负载。
消息头、令牌、可选项之后就是可选项负载。如果存在非零负载，其由一个固定前缀标记，1字节的负载标记（OxFF），意味着可选项的结束和负载的开始。负载数据从标记开始直到UDP报文结尾。无负载标记意味着负载长度为0。有负载标记而无负载应按照格式错误消息执行。7
YD/T3241—2017bzxz.net
5.2可选项格式
CoAP定义了一些可以被包含在消息当中的可选实例。消息中的每个可选实例都指定了CoAP可选项中定义的可选项数量，可选项长度和可选项本身。与直接定义可选项数不同，实例必须以可选项数+增量的形式顺序出现：可选项数的计算方法是增量加上消息运行的实例的可选项数。消息中的第一个实例，其计算可选项数时增量为0。用增量为0的方式同一个可选项可以包含多个实例。可选项数保存在CoAP可选项数注册表当中。7.5当中定义了其语义。可选项格式如图7所示。Option增量Option长度
Option增量（扩展）
Option长度（扩展）
Option值
I byte
0-2 byte
0-2 byte
O或多byte
图7可选项格式
图7所示的可选项字段定义如下：增量：4bit无符号整数。其值为0~12。其中三个值保留为特殊构造字段：●13：8bit无符号整数。初始字节之后的8bit无符号整数，其增量减去13；●14：16bit无符号整数。初始字节之后的按网络字节顺序的16bit无符号整数，其增量减269：●15：为负载标识保留。如果该值已设置但是非负载标识，应按照格式错误处理。结果增量是本可选项的可选项数与之前可选项的不同之处，可选项数是前一个可选项数加上增量计算得来的。
可选项长度：4bit无符号整数。可选项值的长度（字节），其值为0~12。其中三个值保留为特殊构造字段：
●13：8bit无符号整数。在可选项值之前，表示其可选项长度减去13；●14：16bit无符号整数。在可选项值之前按网络顺序排列，表示其可选项长度减去269；●15：保留位。如果该值已设置，应按照格式错误处理。值：完全的可选项长度（字节）序列。可选项值的长度和格式取决于可选项本身，可以是不同的长度值。本标准应用格式见4.3。其他标准定义的可选项可以用作其他可选项值格式。5.3可选项值格式
本标准中定义的可选项应用以下可选项值格式。空：长度（字节）为0的序列。
不透明：未知长度（字节）的序列。单元：代表用可选项长度学段值排序的非负整数。可选项定义可以定义一组授权字节号码：如果可选，发送方应用尽可能少的字节来表示该号码，如，不带引导的0字节。例如，数字0表示空可选项值，数字1用一个数值为1的字节代表（00000001）。接收方应能够正确执行引导的0字节消息。开发提示：在模板中用固定大小可选项的模板实现（硬件实现）时，会严格限制发送方异常行为。o
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。