一 起源
随着越来越多的人通过PC、手机等设备相互连接，现代互联网蓬勃发展使得人们的生活发生了翻天覆地的变化。很多人预测将会有更多其他的设备相互连接，这些设备的数量将远远超过人类的数量，到时候形成的网络将是现有网络的N个量级，这个网络带给世界的变化将是无法估量的。
不像人接入互联网的简单方便，由于物联网设备大多都是资源限制型的，有限的CPU、RAM、Flash、网络宽带等。对于这类设备来说，想要直接使用现有网络的TCP和HTTP来实现设备实现信息交换是不现实的。于是为了让这部分设备能够顺利接入网络，CoAP协议就被设计出来了。
二 概念
CoAP约束应用协议（Constrained Application Protocol）是一种专用于受限设备的Internet应用协议，如RFC 7252所定义，它使那些被称为“节点”的受约束设备能够使用类似的协议与更广泛的Internet进行通信。CoAP被设计用于同一受限网络（例如，低功耗、有损网络）上的设备之间、设备和因特网上的一般节点之间以及由因特网连接的不同受限网络上的设备之间使用。CoAP也被用于其他机制，如移动通信网络上的SMS。
简言之，CoAP是受约束设备的专用Internet应用程序协议。
三 特点
- 基于消息模型，定义了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上。
四 区别于其他物联网协议(HTTP、CoAP、MQTT)
CoAP协议的设计参考了HTTP，CoAP和MQTT都是行之有效的物联网协议，一下为它们之间的异同。
- HTTP和CoAP
- HTTP代表超文本传输协议，CoAP代表约束应用协议;
- HTTP协议的传输层采用了TCP，CoAP协议的传输层使用UDP;
- CoAP协议是HTTP协议的简化版;
- CoAP协议和HTTP协议一样使用请求/响应模型，拥有相同的方法;
- CoAP开销更低，并支持多播;
- CoAP专为资源构成应用而设计，如:IoT/WSN/M2M等…
- CoAP和MQTT
- MQTT协议使用发布/订阅模型，CoAP协议使用请求/响应模型;
- MQTT是长连接，CoAP协议是无连接;
- MQTT通过中间代理传递消息的多对多协议，CoAP协议是Server和Client之间消息传递的单对单协议;
- MQTT不支持带有类型或者其它帮助Clients理解的标签消息，CoAP内置内容协商和发现支持，允许设备彼此窥测以找到交换数据的方式。
五 详解CoAP协议
- 数据包格式
(2位的版本编号一般区固定值0b01;2位的报文类型;4位的标签长度指示;8位的准则;16位的报文序号;32位标签;32位的选项;8位的分隔符;24位的负载) - 消息模型
COAP协议通信是通过在UDP上传输消息类完成。UDP比作公路话，消息就是公路上汽车。
COAP定义了4种类型消息，来实现设备端与云端之间双向通信
- 需要确认消息 CON
- 不需要确认消息 NON （适用于消息会重复频繁的发送，丢掉消息不对业务产生影响）
- 确认应答消息 ACK
- 复位消息 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消息里面
|