Coap协议学习（二）

1、基础了解

1.1 CoAP消息类型
CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。

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

CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。
NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。
ACK——应答消息，接受到CON消息的响应。
RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。

1.2 COAP具体协议介绍:

协议框架运行在UDP上

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

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

CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。
NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。
ACK——应答消息，接受到CON消息的响应。
RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。

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

#####怎么是可靠消息传输？

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

#####怎么是不可靠消息传输？
客户端只管发送消息， 不管服务器端有没有收到，因此可能存在丢包。
不可靠传输是基于NON消息传输的。服务器端收到NON类型的消息后，不用回复ACK消息。

资源请求/响应模型 Requests/Responses
对于物联网，服务器上的资源可以简单的认为是物联网设备的实时运行影子， 通过访问服务器上资源就可以实现与设备间数据的交互。 上面谈到的消息模型比如汽车话， 资源请求及响应好比汽车上货物。 资源请求及响应内容最终会被放在CoAP消息包里面。CoAP请求与响应，类似HTTP，且根据RESTful架构设计的。 CoAP客户端发出请求，CoAP服务端进行请求处理然后发送响应。

COAP 请求Request方法： 请求方法与HTTP协议类似，有4个。
GET, PUT, POST, DELETE， 所有的请求方法都会放在CoAP CON/NON消息里面进行传输。

COAP 请求响应Response代码： 响应内容也与HTTP协议类似。 主要有如下3类：

Success 2.xx 代表客户端请求被成功接收并被成功处理
Client Error 4.xx 代表客户端请求有错误，比如参数错误等
Server Error 5.xx 代表服务器在执行客户端请求时出错。
所有的请求服务器响应可以放在CoAP CON/NON/ACK消息里面进行传输。针对CoAP 带CON消息请求，响应如果快速处理完（有些请求的处理需要耗时多，服务器无法立即响应），则可直接放在ACK消息包里面返回。对于无法立即响应的，服务器带资源ready后，会单独发一个响应消息包给客户端

服务器上可访问资源统一用URL来定位（比如/deviceID/temp 访问某个设备的温度信息）。客户端通过某个资源的URL来访问服务器具体资源，通过4个请求方法（GET,PUT,POST,DELETE）完成对服务器上资源增删改查操作。

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

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

1.3 CoAP帧格式
一个CoAP消息最小为4个字节，以下是CoAP协议不同部分的描述。

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

Message ID:    16bit， 代表消息MID，每个消息都有一个ID ，重发的消息MID不变。

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

Options:    CoAP选项类似于HTTP请求头，它包括CoAP消息本身，例如CoAP端口号，CoAP主机和CoAP查询字符串等。
Payload:    真正有用的被交互的数据 若有,前面加payload 标志 OxFF。