教你动手写UDP协议栈-CoAP报文解析5

教你动手写UDP协议栈系列文章

背景

• CoAP（Constrained Application Protocol），它属于网络协议栈中应用层协议，它使那些被称为“节点”的受限设备能够使用类似的协议与更广泛的互联网进行通信。CoAP设计用于同一受限网络(例如低功耗、有损网络)上的设备之间、Internet上的设备和一般节点之间，以及通过Internet连接的不同受限网络上的设备之间。
• 在之前的文章中，描述了采用UDP进行OTA，而当时的UDP-OTA局限于本地OTA。而对于物联网设备，不可能每次升级都跑到设备旁边进行本地OTA吧，所以需要进行远程OTA。

CoAP

CoAP协议特点

1. CoAP协议网络传输层是采用UDP。

• 非加密CoAP协议层如下:

+----------------------+
|     Application      |
+----------------------+
|  Requests/Responses  |
+----------------------+
|      Messages        |
+----------------------+
|          UDP         |
+----------------------+

• 加密CoAP协议层如下:

+----------------------+
|     Application      |
+----------------------+
|  Requests/Responses  |
+----------------------+
|      Messages        |
+----------------------+
|         DTLS         |
+----------------------+
|         UDP          |
+----------------------+

1. CoAP它是基于REST软件架构，CoAP是类HTTP协议，它是对HTTP协议简化，server的资源地址和互联网一样也有类似url的格式，客户端同样有POST，GET,PUT,DELETE方法来访问server。
2. CoAP协议是采用二进制格式，而HTTP协议是文本格式，所以CoAP比HTTP协议更加紧凑。
3. Coap协议是一个轻量化协议，最小长度仅仅为4B。
4. 支持可靠传输，数据重传，块传输。确保数据可靠到达，异步通信。
5. 支持IP多播, 即可以同时向多个设备发送请求。
6. 非长连接通信，适用于低功耗物联网场景。

CoAP报文格式

  2   2    4          8                     16
+---+---+-----+----------------+---------------------------|
|ver| T | TKL |      Code      |        Message ID         |
+----------------------------------------------------------|
|   Token(if any, TKL bytes)...                            |
+----------------------------------------------------------|
|   Optons(if any)...                                      |
+---------------+------------------------------------------|
|1 1 1 1 1 1 1 1|    Payload(if any)...                    |
+----------------------------------------------------------|

• 消息头部（如上：第一行是消息头，固定4个byte）

CoAP协议消息类型

• CoAP协议分为4种消息类型

1. CON：需要被确认请求，如果CON请求被发送，那么对方必须做出响应。这种方式有点类似TCP，用于可靠消息传输。模型如下图：

Client             Server
   |   CON[0x7d34]   |
   +---------------->|
   |   ACK[0x7d34]   |
   +<----------------|
   |                 |

1. NON：不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。这适用于消息会重复频繁的发送，丢包不影响正常操作。这种方式有点类似UDP，用以不可靠消息传输。模型如下图：

Client             Server
   |   NON[0x01a0]   |
   +---------------->|
   |                 |

1. ACK：应答消息，接受到CON消息的响应。
2. RST：复位消息，当接收者接收到的消息包含一个错误或者不认识消息，接受者不能回ACK消息，必须回RST消息。

CoAP的请求码（requests）和响应码(responses)

• CoAP的请求码和响应码既是CoAP协议中Code字段，类似HTTP协议中的状态码。其中:
  • 0.XX 表示CoAP请求的某种方法。
  • 2.XX、4.XX、5.XX 表示CoAP响应的具体表现。

1. 请求码（0.XX）

1. 响应码（2.XX）：成功码

• 这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

1. 响应码（4.XX）：客户端错误码

• 这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。

1. 响应码（5.XX）: 服务器错误码

• 这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器的软硬件资源无法完成对请求的处理。

CoAP的可选字段（Option）

1. CoAP支持多个Option，CoAP的Option的表示采用增量的方式描述。Option的属性如下几类：
   • Critical Option：接收方必须能够理解的Option，否则消息无法正常处理。
   • Elective Option：接收方不识别该Option时，可以忽略，不影响消息的正常处理。
   • Unsafe Option：Proxy不识别不能转发其所在的Message的Option，并不是每个Critical Option都是Unsafe Option。
   • Safe-to-Forward Option：Proxy不识别仍可转发其所在的Message的Option
2. CoAP 的Option格式：

+--------------+---------------+
| option delta | option length |   1 byte
+------------------------------+
\         option delta         \
/          (extended)          /   0 ~ 2 byte
+------------------------------+
\        option length         \
/          (extended)          /   0 ~ 2 byte
+------------------------------+
/                              /
\         option Value         \   0 or more bytes
/                              /
+------------------------------+

1. CoAP 的Option格式描述：

• Option Delta：
  1. Option在message中的实例必须按照编号大小顺序存放，Option的实际编号由本Option中Delta值+上一个Option的Delta值确定；假定上一个Option的标号为0，同一个编号的多个Option的实例，其Delta值为0。
  2. 取值0-12表示Option delta；取值为13，需要占用Option Delta extension中一个byte，存放实际option delta减13的值；取值为14，需要占用extension中两个字节，存放实际Option delta减去269的部分；取值为15，为payload marker保留。
• Option Length：取值0~12表示option占用的字节数；取值13表示需要占用扩展中的一个字节，且表示option length减13的部分；取值14表示需要占用扩展中的两个字节，且表示option length减去269部分；取值15表示保留；
• Option Value：Option的具体内容。
  1. 0长度的字符序列
  2. 不透明的字节序列
  3. 无符号整数
  4. UTF-8编码的Unicode字符串

1. CoAP的Option的编号方式：

• Option编号内容：
  • Content-Format和Accept用于表示CoAP负载的媒体格式：
  • Uri-Host、Uri-Port、Uri-Path和Uri-Query等和资源“位置”和参数有关：
  1. Content-Format:指定CoAP复杂媒体类型，媒体类型采用整数描述，例如application/json对应整数50，application/octet-stream对应整数40。
  2. Accept: 指定CoAP响应复杂中的媒体类型，媒体类型的定义和Content-Format相同
  3. Uri-Host：CoAP主机名称，例如：iot.xxxx.org。
  4. Uri-Host：CoAP端口号，默认5683。
  5. Uri-Path：资源路由或路径，例如\temperature。资源路径采用UTF8字符串形式，长度不计第一个""。
  6. Uri-Query：访问资源参数，例如?value1=1&value2=2，参数与参数之间使用“&”分隔，Uri-Query和Uri-Path之间采用“?”分隔。
• Content-Format描述：

• Content-Format编号内容:

1. text/plain: 编号为0，表示负载为字符串形式，默认为UTF8编码。
2. application/link-format：编号为40，CoAP资源发现协议中追加定义，该媒体类型为CoAP协议特有。
3. application/xml：编号为41，表示负载类型为XML格式。
4. application/octet-stream：编号为42，表示负载类型为 二进制格式。
5. application/exi：编号为47，表示负载类型为“精简XML”格式。（翻译不一定准确）

• 另外，还有一种格式也IANA认定，也会在CoAP协议中广泛使用那便是CBOR格式，该格式可理解为 二进制JSON格式。

1. applicaiton/cbor：编号为60。

CoAP实例：

1. 实例说明：CoAP客户端通过GET方法从Server端获取温度数据。
   • CoAP请求报文采用CON报文，Server接收到CON报文必须返回一个ACK报文。
   • CoAP请求采用0.01 GET方法，若操作成功CoAP Server返回2.05 Content。
   • 请求和响应的MID必须完全相同，此处为0x1234。
   • 请求响应中的Token域为空。
   • CoAP请求中包含Option，该Option的类型为Uri-Path，那么Option Delta的值为0+11=11。
   • Option Value的值为字符串形式的“temp”。
   • CoAP返回中包含温度数据。
2. 实例模型

Client      Server
   |    GET   |   Header：GET(T=CON, Code=0.01, MID=0x1234)
   +--------->|      Uri-Path: "temp"
   |   2.05   |
   +<---------|   Header: 2.05 Content (T=ACK, Code=2.05, MID=0x1234)
   |          |      Payload: "22.3 C"

1. 报文格式

/* Client -> Server */
  2   2    4          8                     16
+---+---+-------+----------------+---------------------------|
| 1 | 0 |   0   |    GET=1       |        MID=0x1234         |
+------------------------------------------------------------|
|  11   |   4   |        "temp"(4byte)                       |
+---------------+--------------------------------------------|

/* Server -> Client */
  2   2    4          8                     16
+---+---+-------+----------------+---------------------------|
| 1 | 2 |   0   |    2.05=59     |        MID=0x1234         |
+------------------------------------------------------------|
|1 1 1 1 1 1 1 1|        "22.3 C"(6byte)                     |
+---------------+--------------------------------------------|

总结

• 在物联网终端设备大多都是资源限制型的。有限的CPU、RAM、Flash、网络宽带等。
• 对于这类设备使用TCP或HTTP是不现实的。
• 基于这种考虑，CoAP协议就被设计出来，如应用在NB-IOT等等。
• 像水表那些，不用长连接的，使用这个协议，可以增加续航等能力。