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（已把二进制解析为文本，可以直观的了解该协议所包含内容）

get

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

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

COAP Requests ：请求方法与HTTP协议类似，有4个。
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，就可以知道该响应是针对之前哪个请求回复的。

option（可选，0个或者多个）

请求消息与回应消息都可以0~多个options。主要用于描述请求或者响应对应的各个属性，类似参数或者特征描述。

payload（可选）

实际携带数据内容，若有，前面加payload 标志 OxFF.

option 介绍

格式

当一个消息报文里面有多个option时，每个option需要按照该option在协议里面对应的编号顺序排列下来。并且每个option索引是通过增量来计算的。option Delta 代表相对于前面一个option编号的增量。

举个例子
假设前面一个option编号为20，当前option编号为25，则当前option的增量Delta就设置为5
增量最大可占用2个byte，计算方式如下
当option Delta = 0~12时，只占4bit。
当option Delta =13 则占1B，实际数字是option Delta【extended】 - 13
当option Delta =14 则占2B ，实际数字是option Delta【extended】 - 269

COAP 支持OPTION编号列表，是HTTP协议 options 子集。

举例
Uri-Host:服务器主机名称，如californium.eclipse.org
Uri-Port:服务器端口号，默认为5683
Uri-Path:资源路路径，如\temperature
Uri-Query:访问资源参数，例如?v=1&t=2

4.块传输

需要传输大量数据时，比如一个大文件，需要采用分块传输，把文件拆解成多个块进行传输。扩展的块传输协议在COAP基础协议上增加了3个options， 2个response codes 用于块传输大小协商及控制。

block option结构

有三部分组成：
SZX: Block Size，占用2bit，取值范围0~6，对应每个block 大小为2xx（SZX+4），即范围（16 ~ 1024），以Byte为单位
M: More Flag，占用1bit，代表是否还有剩下数据块未传输。如果设置为0，代表数据块都已传输出去
NUM: Block Number，占用0~3Byte，代表当前块编号，以0开始，如我们要传10个数据块，则数据块的编号为0~9

option block1：主要用于客户端发出请求时，分块传输，比如需要上传一个大的数据包到服务器上。
option block2：主要用于服务器端响应时，分块传输，比如设备端发起资源发现式，由于服务器上资源较多，就要启动分块传输。

Size option

主要用于向对方说明，这次块传输需要传送的数据总数量。
Size1 option：代表客户度发出请求里面资源总的大小。
Size2 option：代表服务器端响应资源总的大小。

如何启动块传输？

当请求消息或者响应消息里面有出息 block1/block2 option时，代表这是块传输通信。需要根据option block 里面M标识，决定是否继续进行块传输。

示例

第一个消息，客户端发起发现资源请求信息CON并设置Block2：0(NUM)/0(M)/64（SZX）告诉服务器端，能接受最大block size为64.
第二个消息。服务器端回复确认消息ACK，并设置Block2：0/1/64，告诉客户端，block size已接受为64，且后面还有数据，当前传输块编号是0. size2：1094，告诉客户端，接下来总的数据大小是1094B。
第三个消息，客户端发起请求获取下一个block。设置Block2：1/0/64.告诉服务器端下一个要获取的block编号是1.

5.订阅与发布

MQTT协议是基于订阅与发布模型的，coap通过扩展协议方式也简单的实现了订阅与发布模型。

当一个客户端需要定期去查询服务器端某个资源的最新状态时，订阅与发布模型就非常有用，不用这个模型，客户端就要周期的不断发送请求到服务器端。

模型框架

关键概念
主题Subject：代表coap的某个资源
观察者Observer：代表对某个coap资源感兴趣的客户端
登记Registration：观察者需要向服务器登记感兴趣的主题。
通知Notification：当观察者感兴趣的主题发生内容变化时，服务器主动通知到观察者。

观察协议在COAP基础协议上增加了1个Observe option，其值为整数，通过该options来实现订阅与发布模型管理

在get请求消息里面
oberser value 为 0：代表向服务器端订阅一个主题。
oberser value 为 1：代表向服务器端移除一个已订阅主题。

在notification消息里面
oberser value 代表主题发生变化时，检测到顺序，以便客户端可以知道状态变化的先后。

举个例子

1. 客户端向服务器端登记感兴趣的主题 /temperature
2. 当temperature发生状态改变时，服务器端主动通知到客户端。
3. 客户端根据token，就可以与之前订阅主题关联起来，以此确定是哪个主题订阅的。

6.安全

COAP使用DTLS来做安全传输层，该层运行于UDP之上.

当前考虑使用DTLS时，需要考虑设备终端资源受限情况，有些资源有限设备无法运行DTLS安全加密算法。

做安全加密，需要根据应用场景需要，对应只上报数据，且数据敏感度不高场景，可以不考虑加入安全层。

7.参考协议

COAP基本协议RFC7252
块传输协议 RFC7959
订阅与发布 RFC7641

转载请注明出处

了解更多物联网技术资讯，物联网开放代码，IOT解决方案请访问www.adminiot.com.cn