协议框架
CoAP默认运行在UDP上，但它也支持运行在SMS,TCP等数据传输层上。本文主要是基于UDP上的CoAP协议介绍
1.消息模型 Messages
COAP协议通信是通过在UDP上传输消息类完成。UDP比作公路话，消息就是公路上汽车。
COAP定义了4种类型消息，来实现设备端与云端之间双向通信
1. 需要确认消息 CON
2. 不需要确认消息 NON （适用于消息会重复频繁的发送，丢掉消息不对业务产生影响）
3. 确认应答消息 ACK
4. 复位消息 RST
基于4种消息类型，可以实现2种传输质量。即可靠消息传输 与 不可靠消息传输。
怎么是可靠消息传输？
主要是通过确认及重传机制来实现的，客户端发送消息后，需要等待服务器收到通知， 如果在规定时间内，没有收到需要重新发送数据。 可靠传输是基于CON消息传输的，服务器端收到CON类型的消息后，需要返回ACK消息，客户端到在指定时间ACK_TIMEOUT内收到ACK消息后，才代表这个消息以可靠到服务器端。
怎么是不可靠消息传输？
客户端只管发送消息， 不管服务器端有没有收到，因此可能存在丢包。不可靠传输是基于NON消息传输的。服务器端收到NON类型的消息后，不用回复ACK消息。
2.资源请求/响应模型 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消息里面
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
- 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:资源路路径，如 emperature
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服务器上的某个资源resource，该资源状态随时可能发生变化 观察者Observer：代表对某个coap资源最新状态感兴趣的客户端CoAP Client 登记Registration： 观察者需要向服务器CoAP server登记感兴趣的主题Subject。
通知Notification：当CoAP观察到某个主题发生状态变化时，CoAP服务器会主动向该主题下的已登记的观察者列表里面的每个观察者发送其订阅的主题最新状态数据。 备注：如果已订阅某个主题的CoAP client对CoAP server Notification无法确认，则会从主题订阅列表里面移除掉。
订阅与发布协议在COAP基础协议上增加了1个Observe option， 其值为整数，通过该options来实现订阅与发布模型管理
在get请求消息里面
oberser value 为 0： 代表向CoAP服务器端订阅一个主题。
oberser value 为 1： 代表向CoAP服务器端移除一个已订阅主题。
在notification消息里面
oberser value 代表 主题发生变化时，检测到顺序，以便客户端可以知道状态变化的先后。
举个例子
1. 客户端向服务器端登记感兴趣的主题 /temperature
2. 当temperature发生状态改变时，服务器端主动通知到客户端。
3. 客户端根据token，就可以与之前订阅主题关联起来，以此确定是哪个主题订阅的。
一个CoAP Client可以分次向CoAP server订阅多个资源主题。 一个CoAP server上的主题可以被多个观察者（CoAP Client）订阅。 这样就通过了CoAP server实现了CoAP Client之间直接数据转发通信。
可以通过灵活设计服务器上的资源链接，来实现对某个主题的条件订阅（类似触发器或者阀值等）。 比如订阅主题是: coap://server/temperature/critical?above=42， 当温度超过42，CoAP Server需要发送通知。