CoAP 是受限制的应用协议（Constrained Application Protocol）的代名词。由于通常物联网设备都是资源限制型的，有限的CPU 能力，有限RAM，有限的FLASH，有限的网络带宽，针对此类特殊场景，CoAP 协议借鉴了HTTP 协议机制并简化了协议包格式。CoAP 是一种应用层协议，它运行于UDP 协议之上而不是像HTTP 那样运行于TCP 之上。CoAP 协议非常小巧，最小的数据包仅为4 字节。该协议由IETF 的CoRE 工作组提出，通常应用于一些低功耗物联网场合，例如，6LowPAN 协议栈中的应用层协议就采用了CoAP。
CoAP 和HTTP 协议都是通过4 个请求方法（GET，PUT，POST，DELETE）对服务器端资源进行操作。两者之间明显的区别在于HTTP 是通过文本描述方式描述协议包内容，协议包里面会包含一些空格符、换行符等，协议包可读性很强。而CoAP 是通过定义二进制各位段功能来描述协议包内容。因此，CoAP协议包更小，更紧凑。CoAP 协议最小的协议包只有4 B。协议包需要经过解析后才能知道里面具体内容，另外还有一个明显的区别是，传统的HTTP 协议中主机与web 服务器之间是单向通信的（用WebSocket 除外）。而CoAP 系统中CoAP Client 与CoAP Server 是可以双向通信，双方都可以主动向对方发送请求。
CoAP 采用与HTTP 相同的请求响应工作模式，CoAP 协议共有4 种不同消息类型：
（1）CON—— 需要被确认的请求，如果CON 请求被发送，那么对方必须做出响应。
（2）NON—— 不需要被确认的请求，如果NON 请求被发送，那么对方不必做出回应。
（3）ACK—— 应答消息，接收到CON 消息的响应。
（4）RST—— 复位消息，当接收者接受的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。
CoAP 消息报文格式如图7-3 所示，由Header（必选）、Token（可选）、Option（可选，0 个或者多个）和Payload（可选）四大部分构成。其中，报文头Header的含义如表7-1 所示。
图7-3 CoAP 报文格式
表7-1 报文头含义
(www.xing528.com)
服务器上可访问资源统一用URL 来定位（如/deviceID/temp 访问某个设备的温度信息）。客户端通过某个资源的URL 来访问服务器具体资源，通过4 个请求方法（GET，PUT，POST，DELETE）完成对服务器上资源增删改查操作。例如，某个设备需要从服务器端查询当前温度流程，如图7-4 所示。请求消息（CON）：GET /temperature，请求内容会被包在CON 消息里面。响应消息（ACK）=2.05 Content "22.5 C"，响应内容会被放在ACK 消息里面。具体的消息流程和报文格式如图7-5 所示。
图7-4 两个温度查询报文流程
图7-5 基于CoAP 的温度查询报文示例
CoAP 通过扩展协议方式也简单地实现了订阅与发布模型。当一个客户端需要定期去查询服务器端某个资源的最新状态时，订阅与发布模型就非常有用。订阅与发布协议在CoAP 基础协议上增加了1 个Observe option，其值为整数，通过该option 来实现订阅与发布模型管理在GET 请求消息里面：
oberser value 为0：代表向CoAP 服务器端订阅一个主题。
oberser value 为1：代表向CoAP 服务器端移除一个已订阅主题。
在notification 消息里面的oberser value 代表主题发生变化时，检测到顺序，以便客户端可以知道状态变化的先后。一个CoAP Client 可以分次向CoAP server订阅多个资源主题。一个CoAP server 上的主题可以被多个观察者（CoAP Client）订阅。这样就通过了CoAP server 实现了CoAP Client 之间直接数据转发通信。
可以通过灵活设计服务器上的资源链接，来实现对某个主题的条件订阅（类似触发器或者阈值等）。例如，订阅主题是：<coap：//server/temperature/critical?above=42>，当温度超过42，CoAP Server 需要发送通知。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
