转至：https://blog.csdn.net/robert_tina/article/details/78864345

COAP协议全面分析

HTTP与COAP 请求与响应示例

HTTP请求（文本格式）

POST https://getman.cn/echo HTTP/1.1 User-Agent: Fiddler Host: getman.cn Content-Length: 9  {temp:22}

HTTP响应（文本格式）

HTTP/1.1 200 OK Server: NWSs Date: Thu, 07 Dec 2017 14:38:25 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Cache-Control: private, no-cache Vary: Accept-Encoding X-Powered-By: PHP/7.1.7 Access-Control-Allow-Origin: * X-NWS-LOG-UUID: 6bac6a30-99fb-4441-8c04-fe0f6556e5b7 X-Daa-Tunnel: hop_count=2 Content-Length: 298  POST /echo HTTP/1.1 X-DAA-TUNNEL: hop_count=2 X-TENCENT-UA: Qcloud QVIA: 7f0000016285484627467c8660a39b6bbf1af144 X-NWS-LOG-UUID: 6bac6a30-99fb-4441-8c04-fe0f6556e5b7 X-FORWARDED-PROTO: https X-FORWARDED-FOR: 223.73.213.93 USER-AGENT: Fiddler CONTENT-LENGTH: 9 HOST: getman.cn  {temp:22}

COAP请求与响应

COAP SPEC里面例子（二进制格式）
COAP firebox copper插件log（已把二进制解析为文本，可以直观的了解该协议所包含内容）

COAP请求与响应都会放在COAP Message里面。

HTTP 与 COAP协议都是通过4个请求方法（GET, PUT, POST, DELETE）对服务器端资源进行操作。两者之间明显的区别在于HTTP是通过文本描述方式描述协议包内容，协议包里面会包含一些空格符，换行符等,协议包可读性很强。而COAP是通过定义二进制各位段功能来描述协议包内容。因此COAP协议包大小更小，更紧凑。COAP协议最小的协议包只有4B。协议包需要经过解析后才能知道里面具体内容

COAP协议背景

在物联网应用里面，设备与设备之间都存在网络里面，它们需要互相进行网络通信。但由于通常物联网设备都是资源限制型的，有限的CPU能力，有限RAM,有限的flash，有限的网络带宽，针对此类特殊场景，COAP协议借鉴了HTTP协议机制并简化了协议包格式。简洁地实现了物联网设备之间通信。

COAP协议特点

消息模型，以消息为数据通信载体，通过交换网络消息来实现设备间数据通信
对云端设备资源操作都是通过请求与响应机制来完成，类似HTTP，设备端可通过4个请求方法（GET, PUT, POST, DELETE）对服务器端资源进行操作。
协议包轻量级，最小长度仅为4B。
支持可靠传输，数据重传，块传输。确保数据可靠到达。
支持IP多播, 即可以同时向多个设备发送请求
非长连接通信，适用于低功耗物联网场景

COAP具体协议介绍

协议框架

运行在UDP上

1.消息模型 Messages

COAP协议通信是通过在UDP上传输消息类完成。UDP比作公路话，消息就是公路上汽车。

COAP定义了4种类型消息，来实现设备端与云端之间双向通信

1. 需要确认消息   CON  2. 不需要确认消息  NON （适用于消息会重复频繁的发送，丢掉消息不对业务产生影响） 3. 确认应答消息   ACK 4. 复位消息  RST

基于4种消息类型，可以实现2种传输质量。即可靠消息传输与不可靠消息传输。

怎么是可靠消息传输？

主要是通过确认及重传机制来实现的，客户端发送消息后，需要等待服务器收到通知，如果在规定时间内，没有收到需要重新发送数据。可靠传输是基于CON消息传输的。

怎么是不可靠消息传输？

客户端只管发送消息，不管服务器端有没有收到，因此可能存在丢包。不可靠传输是基于NON消息传输的。

2.资源请求/响应模型 Requests/Responses

上面谈到的消息模型比如汽车话，资源请求及响应好比汽车上货物。资源请求及响应内容最终会被放在消息包里面。

GET, PUT, POST, DELETE

COAP Responses：响应内容也与HTTP协议类似。主要有如下3类：

Success 2.xx 代表客户端请求被成功接收并被成功处理
Client Error 4.xx 代表客户端请求有错误，比如参数错误等
Server Error 5.xx 代表服务器在执行客户端请求时出错。

比如某个设备需要从服务器端查询当前温度信息。

请求消息（CON）： GET /temperature , 请求内容会被包在CON消息里面
响应消息 (ACK)： 2.05 Content “22.5 C” ，响应内容会被放在ACK消息里面

3.消息报文定义 Messages Define

Header（必须）：固定4个byte

Ver : 2bit，代表版本信息，当前是1
T： 2bit，代表该消息类型， CON, NON. ACK, RST
TKL: 4bit，token长度，当前支持0~8B长度，其他长度保留将来扩展用
Code：8bit，分成前3bit（0~7）和后5bit（0~31），前3bit代表类型。 0代表空消息或者请求码， 2开头代表响应码，取值如下：
```
0.00 Indicates an Empty message 0.01-0.31 Indicates a request.  1.00-1.31 Reserved 2.00-5.31 Indicates a response.  6.00-7.31 Reserved 
```
- 1
- 2
- 3
- 4
- 5
- 6
Message ID：16bit，代表消息MID，每个消息都有一个ID ，重发的消息MID不变。

token（可选）

也叫做请求ID。把响应与之前的请求关联起来。有时候客户端发送出请求带上token，服务器端有时不能立即响应，带服务器端准备好数据后，会单独发送一个消息给客户端，这时候客户端需要判断这个消息是针对之前的哪个请求回复的，token用途就在这里，通过token，客户端收到响应后，取出TOKEN，就可以知道该响应是针对之前哪个请求回复的。