coap是比较常用的物联网传输协议，基于udp协议之上的应用层协议。
下面基于rfc7252对coap报文进行分析。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Message Format
rfc7252对coap的报文头定义如上，8位表示一个字节，可以看到coap协议字节还是比较节省的。
第一个字节的8位，2位表示协议版本号（每个协议都有协议版本号，为了兼容性考虑），在这里rfc7252规定这里必须填01，其他的留给以后的版本。
2位表示消息类型，其实是一个枚举值2^2有四个消息类型.对于这四种消息类型，rfc7252给的回复标准是：
Confirmable (0),
Non-confirmable (1),
Acknowledgement (2),
Reset (3)
+----------+-----+-----+-----+-----+
| | CON | NON | ACK | RST |
+----------+-----+-----+-----+-----+
| Request | X | X | - | - |
| Response | X | X | X | - |
| Empty | * | - | X | X |
+----------+-----+-----+-----+-----+
4位的token，结合可选的token确定是否在报文里面携带token信息，也就是说coap协议最多可携带2^4-1的15个字节的token信息
紧接着是1字节的code信息，这里的code也是一个枚举值类型，表明请求类型，类似于http的请求方法，不过与http不同的http采用明文表明请求方法，无论你请求方法是啥，只占用1个字节。有的同学就说了，255个方法是不是有点多了，确实，所以对于这一个字节，协议又把它细分了，前三位和后五位，所以就形成了x.xx的数据结构
| Code | Name | Reference |
+------+--------+-----------+
| 0.01 | GET | [[RFC7252] |
| 0.02 | POST | [[RFC7252] |
| 0.03 | PUT | [[RFC7252] |
| 0.04 | DELETE | [[RFC7252] |
| 2.01 | Created | [RFC7252] |
| 2.02 | Deleted | [RFC7252] |
| 2.03 | Valid | [RFC7252] |
| 2.04 | Changed | [RFC7252] |
| 2.05 | Content | [RFC7252] |
| 4.00 | Bad Request | [RFC7252] |
| 4.01 | Unauthorized | [RFC7252] |
| 4.02 | Bad Option | [RFC7252] |
| 4.03 | Forbidden | [RFC7252] |
| 4.04 | Not Found | [RFC7252] |
| 4.05 | Method Not Allowed | [RFC7252] |
| 4.06 | Not Acceptable | [RFC7252] |
| 4.12 | Precondition Failed | [RFC7252] |
| 4.13 | Request Entity Too Large | [RFC7252] |
| 4.15 | Unsupported Content-Format | [RFC7252] |
| 5.00 | Internal Server Error | [RFC7252] |
| 5.01 | Not Implemented | [RFC7252] |
| 5.02 | Bad Gateway | [RFC7252] |
| 5.03 | Service Unavailable | [RFC7252] |
| 5.04 | Gateway Timeout | [RFC7252] |
| 5.05 | Proxying Not Supported | [RFC7252] |
+------+------------------------------+-----------+
2个字节的messgaeid，标示请求和响应的对应关系啊。65535个，用完了再循环呗。
变字节长度的token，结合第一个字节4位的token长度可确定token的字节数。
变长度的option可选配置，有的同学说了，coap不是说是rest的方式请求的吗？那我的方法知道在哪了，uri我放在哪呢？没错就是放在options里面去配置，编码如下。
0 1 2 3 4 5 6 7
+---------------+---------------+
| | |
| Option Delta | Option Length | 1 byte
| | |
+---------------+---------------+
\ \
/ Option Delta / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ Option Length / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ /
\ \
/ Option Value / 0 or more bytes
\ \
/ /
\ \
+-------------------------------+
4位的option增量编号，2^4-1=15，但是rfc7252规定只使用0-14，其中0-12不会有option delta（extended）
13表明option delta（extended）有一个字节，增量编号为13+option delta（extended）
14表明option delta（extended）有两个字节，增量编号为option delta（extended）+255
option lenth同理类比option delta
增量编号表示：
+-----+---+---+---+---+----------------+--------+--------+----------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+----------------+--------+--------+----------+
| 1 | x | | | x | If-Match | opaque | 0-8 | (none) |
| 3 | x | x | - | | Uri-Host | string | 1-255 | (see |
| | | | | | | | | below) |
| 4 | | | | x | ETag | opaque | 1-8 | (none) |
| 5 | x | | | | If-None-Match | empty | 0 | (none) |
| 7 | x | x | - | | Uri-Port | uint | 0-2 | (see |
| | | | | | | | | below) |
| 8 | | | | x | Location-Path | string | 0-255 | (none) |
| 11 | x | x | - | x | Uri-Path | string | 0-255 | (none) |
| 12 | | | | | Content-Format | uint | 0-2 | (none) |
| 14 | | x | - | | Max-Age | uint | 0-4 | 60 |
| 15 | x | x | - | x | Uri-Query | string | 0-255 | (none) |
| 17 | x | | | | Accept | uint | 0-2 | (none) |
| 20 | | | | x | Location-Query | string | 0-255 | (none) |
| 35 | x | x | - | | Proxy-Uri | string | 1-1034 | (none) |
| 39 | x | x | - | | Proxy-Scheme | string | 1-255 | (none) |
| 60 | | | x | | Size1 | uint | 0-4 | (none) |
+-----+---+---+---+---+----------------+--------+--------+----------+
既然options是变长的，前面爷没有说明option的长度，那它和payload怎么区分边界，在这里，协议规定了ff之后就是payload内容，就是你要传递的业务数据了。
下面以一个请求响应报文说明上面的分析：
客户端请求：
image.png
40 01 30 39 46 77 65 65 74 61 67 71 61 31 03 ff 68 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21
40的二进制0100 0000对应的就是版本为01 消息类型为Confirmable token长度为0
01二进制为0000 0001辨识为0.01表示get请求
30 39 两字节的messid 12345（显示的大端字节序）
46 对应二进制 0100 011 表明对应增量是4 option value是6，结合上面对option的讲解大家Etag值为77:65:65:74:61:67，一次类推下面的数据。
ff payload的分割
68 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21 都是可见字符hello world！
服务端响应
image.png
60 45 30 39 c0 ff 68 65 6c 6c 6f 20 74 6f 20 79 6f 75 21
60 二进制 0110 0000对应的就是版本为01 消息类型Acknowledgement
45 对应二进制为 0100 0101 辨识为2.05表示响应Content
30 39 对应请求的messageid12345
c0 对应二进制1100 0000 End of options marker 长度为0
ff分隔符
68 65 6c 6c 6f 20 74 6f 20 79 6f 75 21 可见字符hello to you!
至此分解到此结束，coap协议要写的地方还很多，下次再补充吧，欢迎各位大佬斧正！
