标签：response options 算法 必须 flash 定时 new 文件 文本
POST https://getman.cn/echo HTTP/1.1
User-Agent: Fiddler
Host: getman.cn
Content-Length: 9
{temp:22}
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 SPEC里面例子（二进制格式） 
COAP firebox copper插件log（已把二进制解析为文本，可以直观的了解该协议所包含内容）
COAP请求与响应都会放在COAP Message里面。
HTTP 与 COAP协议都是通过4个请求方法（GET, PUT, POST, DELETE）对服务器端资源进行操作。 两者之间明显的区别在于HTTP是通过文本描述方式描述协议包内容，协议包里面会包含一些空格符，换行符等,协议包可读性很强。而COAP是通过定义 二进制各位段功能来描述协议包内容。 因此COAP协议包大小更小，更紧凑。COAP协议最小的协议包只有4B。 协议包需要经过解析后才能知道里面具体内容，另还有一个明显的区别是传统的HTTP协议是主机与web服务器之间是单向通信的（用websocket除外）。而CoAP系统中CoAP Client与CoAP server是可以双向通信，双方都可以主动向对方发送请求。
在物联网应用里面， 设备与设备之间都存在网络里面，它们需要互相进行网络通信。 但由于通常物联网设备都是资源限制型的，有限的CPU能力，有限RAM,有限的flash，有限的网络带宽， 针对此类特殊场景，COAP协议借鉴了HTTP协议机制并简化了协议包格式。简洁地实现了物联网设备之间M2M通信。
- 基于消息模型，定义了4个消息类型，以消息为数据通信载体，通过交换网络消息来实现设备间数据通信
- 对CoAP Server云端设备资源操作都是通过请求与响应机制来完成，类似HTTP，设备端可通过4个请求方法（GET, PUT, POST, DELETE）对服务器端资源进行操作。 请求与响应的数据包都是放在CoAP消息里面进行传输的
- 基于消息的双向通信（M2M），CoAP Client与CoAP server双方都可以独立向对方发送请求.双方可当client或者server角色。
- 协议包轻量级，最小长度仅为4B。
- 支持可靠传输，数据重传，块传输。 确保数据可靠到达。
- 支持IP多播, 即可以同时向多个设备发送请求（比如CoAP client搜索CoAP Server）
- 非长连接通信，适用于低功耗物联网场景
CoAP默认运行在UDP上，但它也支持运行在SMS,TCP等数据传输层上。本文主要是基于UDP上的CoAP协议介绍
COAP协议通信是通过在UDP上传输消息类完成。UDP比作公路话，消息就是公路上汽车。
COAP定义了4种类型消息，来实现设备端与云端之间双向通信
1. 需要确认消息 CON
2. 不需要确认消息 NON （适用于消息会重复频繁的发送，丢掉消息不对业务产生影响）
3. 确认应答消息 ACK
4. 复位消息 RST
基于4种消息类型，可以实现2种传输质量。即可靠消息传输 与 不可靠消息传输。
主要是通过确认及重传机制来实现的，客户端发送消息后，需要等待服务器收到通知， 如果在规定时间内，没有收到需要重新发送数据。 可靠传输是基于CON消息传输的，服务器端收到CON类型的消息后，需要返回ACK消息，客户端到在指定时间ACK_TIMEOUT内收到ACK消息后，才代表这个消息以可靠到服务器端。
客户端只管发送消息， 不管服务器端有没有收到，因此可能存在丢包。不可靠传输是基于NON消息传输的。服务器端收到NON类型的消息后，不用回复ACK消息。
对于物联网，服务器上的资源可以简单的认为是物联网设备的实时运行影子， 通过访问服务器上资源就可以实现与设备间数据的交互。 上面谈到的消息模型比如汽车话， 资源请求及响应好比汽车上货物。 资源请求及响应内容最终会被放在CoAP消息包里面。CoAP请求与响应，类似HTTP，且根据RESTful架构设计的。 CoAP客户端发出请求，CoAP服务端进行请求处理然后发送响应。
COAP 请求Request方法： 请求方法与HTTP协议类似，有4个。 GET, PUT, POST, DELETE， 所有的请求方法都会放在CoAP CON/NON消息里面进行传输。
COAP 请求响应Response代码： 响应内容也与HTTP协议类似。 主要有如下3类：
所有的请求服务器响应可以放在CoAP CON/NON/ACK消息里面进行传输。针对CoAP 带CON消息请求，响应如果快速处理完（有些请求的处理需要耗时多，服务器无法立即响应），则可直接放在ACK消息包里面返回。对于无法立即响应的，服务器带资源ready后，会单独发一个响应消息包给客户端
服务器上可访问资源统一用URL来定位（比如/deviceID/temp 访问某个设备的温度信息）。客户端通过某个资源的URL来访问服务器具体资源，通过4个请求方法（GET,PUT,POST,DELETE）完成对服务器上资源增删改查操作。
举个例子： 比如某个设备需要从服务器端查询当前温度信息。
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
也叫做请求ID。把响应与之前的请求关联起来。有时候客户端发送出请求带上token，服务器端有时不能立即响应， 当服务器端准备好数据后，会单独发送一个消息给客户端， 这时候客户端需要判断这个消息是针对之前的哪个请求回复的，token用途就在这里，通过token，客户端收到响应后，取出TOKEN，就可以知道该响应是针对之前哪个请求回复的。
请求消息 与回应消息都可以0~多个options。 主要用于描述请求或者响应对应的各个属性，类似参数或者特征描述。
实际携带数据内容， 若有， 前面加payload 标志 OxFF.
格式
当一个消息报文里面有多个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
需要传输大量数据时，比如一个大文件，需要采用分块传输，把文件拆解成多个块进行传输。扩展的块传输协议在COAP基础协议上增加了3个options， 2个response codes 用于块传输大小协商及控制。
有三部分组成：
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： 主要用于服务器端响应时，分块传输， 比如设备端发起资源发现式，由于服务器上资源较多，就要启动分块传输。
主要用于向对方说明，这次块传输需要传送的数据总数量。
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.
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需要发送通知。
COAP使用DTLS来做安全传输层，该层运行于UDP之上.
当前考虑使用DTLS时，需要考虑设备终端资源受限情况， 有些资源有限设备无法运行DTLS安全加密算法。
做安全加密，需要根据应用场景需要，对应只上报数据，且数据敏感度不高场景，可以不考虑加入安全层。
标签：response options 算法 必须 flash 定时 new 文件 文本
原文地址：https://www.cnblogs.com/LJWJL/p/9674712.html
