3 消息格式
CoAP的消息格式是很紧凑的，默认运行在UDP上（每个CoAP消息都是UDP数据包中的数据部分）。CoAP也可以运行在DTLS协议上（见9.1节）和其它传输协议上，例如SMS，TCP或SCTP，这些不属于本文档的范畴（CoAP不支持UDP-lite[RFC3828]和UDP zero checksum[RFC6936]）。
CoAP消息用二进制格式进行编码。这个消息格式以一个固定4个字节的头部开始。此后是一个长度在0到8字节之间的Token。Token值之后是0个或多个Type-Length-Value(TLV)格式的选项(Option)。之后到整个数据报的结尾都是payload部分，payload可以为空。
头部字段定义如下：
版本号(Ver)：2-bit无符号整型，代表CoAP版本号。本文档的实现必须设置这个字段为0b01。其它的值为今后其它版本保留。对于带有未知版本号的消息，必须忽略。
类型(T)：2-bit无符号整型。代表这个消息的类型是：CON(0), NON(1), ACK(2),或RST(3)。这些消息类型的语义在第4章进行定义。
Token长度(TKL)：4-bit无符号整型。表示变长的Token字段(0-8字节）的长度。长度9-15是保留的，不能设置长度为9-15。如果设置了长度为9-15，必须被当作消息格式错误来处理。
代码(Code)：8-bit无符号整型。拆分为3-bit的分类信息和5-bit详细信息。写作”c.dd”。c是3-bit长，可以是一个从0到7的数字，dd是5-bit长，它一个两位的数字，从00到31。分类信息c可以代表是一个请求（0），一个成功的响应（2），一个客户端错误响应（4），或者一个服务端错误响应（5）。所有其它的值都是保留的。代码0.00是一个特殊的情况，表示一个空的消息。当消息是一个请求时，Code字段表示请求方法。当响应时，Code字段代表响应代码。Code字段所有可取的值都在CoAP代码表（12.1节）中定义了。请求和响应的语义定义在第5章。
消息ID(Message ID)：16-bit无符号整型，网络字节序。用于检测消息重复以及匹配ACK/RST类型的消息和CON/NON类型的消息。生成消息ID和匹配消息的规则在第4章中讲述。
头部之后是Token值，可以有0到8个字节，由Token长度字段指定。这个Token值用于将某个请求和对应的响应关联。生成Token和关联请求与响应的规则在5.3.1节讲述。
头部和Token之后，是0个或多个选项（见3.1节）。一个选项之后，有可能是消息结束，也可能是另一个选项，也可能是payload标识符和payload部分。
在头部、token和选项之后，是payload部分（可以没有payload）。如果有payload，并且长度不为0，那么payload之前有一个固定长度为一个字节的payload标识符（0xFF），它标志着选项部分的结束和payload部分的开始。payload部分从标识符之后开始，一直到这个UDP数据报结束，也就是说，payload部分的长度可以根据UDP数据报的长度计算出来。如果没有payload标识符，那么就代表这是一个0长度的payload。如果存在payload标识符但其后跟随的是0长度的payload，那么必须当作消息格式错误处理。
实现注意：0xFF这个值有可能出现在一个选项的长度或选项的值中，所以简单的扫描0xFF来寻找payload标识符是不可行的。作为payload标识符的0xFF只可能出现在一个选项结束之后下一个选项有可能开始的地方。
最后更新于
这有帮助吗？