COAP介绍

article/2025/8/19 13:42:17

什么是COAP

CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。在最近几年的时间中，专家们预测会有更多的设备相互连接，而这些设备的数量将远超人类的数量。在这种大背景下，物联网和M2M技术应运而生。虽然对人而言，连接入互联网显得方便容易，但是对于那些微型设备而言接入互联网非常困难。在当前由PC机组成的世界，信息交换是通过TCP和应用层协议HTTP实现的。但是对于小型设备而言，实现TCP和HTTP协议显然是一个过分的要求。为了让小设备可以接入互联网，CoAP协议被设计出来。CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常的小巧，最小的数据包仅为4字节。

CoAP是一种面向网络的协议，采用了与HTTP类似的特征，核心内容为资源抽象、REST式交互以及可扩展的头选项等。这些关键特征使得因特网由简单的文档检索机制(World Wide Web)演进成为现在繁荣的应用平台(Web 2.0)。HTTP作为IETF 成功长期采用的标准，可以用较小的脚本程序来融合不同的资源和服务。它提供的互操作性正是物联网的关键讨论内容，从而HTTP 被推向设备层面。但是由于HTTP基于TCP传输协议，采用点对点的通信模型，不适合于推送通知服务，而且对于受限设备（如8-bit 微处理器）HTTP过于复杂。

CoAP协议基于REST 构架，REST 是指表述性状态转换架构，是互联网资源访问协议的一般性设计风格。为了克服HTTP对于受限环境的劣势，CoAP既考虑到数据报长度的最优化，又考虑到提供可靠通信。一方面，CoAP提供URI，REST 式的方法如GET，POST，PUT和DELETE，以及可以独立定义的头选项提供的可扩展性。另一方面，CoAP基于轻量级的UDP协议，并且允许IP多播。而组通信是物联网最重要的需求之一，比如说用于自动化应用中。为了弥补UDP传输的不可靠性，CoAP定义了带有重传机制的事务处理机制。并且提供资源发现机制，并带有资源描述。

CoAP协议不是盲目的压缩了HTTP协议，考虑到资源受限设备的低处理能力和低功耗限制，CoAP重新设计了HTTP的部分功能以适应设备的约束条件。另外，为了使协议适应物联网和M2M 应用，CoAP协议改进了一些机制，同时增加了一些功能。图1 显示了HTTP和CoAP的协议栈。CoAP和HTTP在传输层有明显的区别。HTTP协议的传输层采用了TCP协议，而CoAP协议的传输层使用UDP协议，开销明显降低，并支持多播。

CoAP协议采用了双层的结构。事务层(Transaction layer)处理节点间的信息交换，同时，也提供对多播和拥塞控制的支持。请求/响应层(Request/Response layer)用以传输对资源进行操作的请求和相应信息。CoAP协议的REST 构架基于该层的通信，REST请求附在一个CON 或者NON消息上，而REST响应附在匹配的ACK消息上。CoAP的双层处理方式，使得CoAP没有采用TCP协议，也可以提供可靠的传输机制。利用默认的定时器和指数增长的重传间隔时间实现 CON消息的重传，直到接收方发出确认消息。另外，CoAP的双层处理方式支持异步通信，这是物联网和M2M应用的关键需求之一。

COAP能否代替HTTP

CoAP并不能替代HTTP协议，但是对于那些小设备（256KB Flash 32KB RAM 20MHz主频）而言CoAP的确是一个好的解决方案。

CoAP消息类型

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

CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。

NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。

ACK——应答消息，如果接受到CON消息的响应。

RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。

COAP的消息结构

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

【版本Version】：类似于IPv6和IPv6，仅仅是一个版本号。

【消息类型Message Type】：CON，NON，ACK，RST。这些消息类型相当于HTTP协议的PUTGET等

【消息ID Message ID】：每个CoAP消息都有一个ID，在一次会话中ID总是保持不变。但是在这个会话之后该ID会被回收利用。

【标记 Token】：标记是ID的另一种表现、

【选项 Options】：CoAP选项类似于HTTP请求头，它包括CoAP消息本身，例如CoAP端口号，CoAP主机和CoAP查询字符串等。

【负载Payload】：真正有用的被交互的数据。

图 CoAP消息结构

CoAP的URL

在HTTP的世界中，正式RESTFul协议由于其简单性和适用性，在WEB应用中越来越受欢迎，这样的道理同样适用于CoAP。一个CoAP资源可以被一个URI所描述，例如一个设备可以测量温度，那么这个温度传感器的URI被描述为：CoAP://machine.address:5683/sensors/temperature。请注意，CoAP的默认UDP端口号为5683。

CoAP观察模式

在物联网的世界中，你需要去监控某个传感器例如温度或湿度等。在这种情况下，CoAP客户端并不需要不停的查询CoAP服务器端的数据变化情况。CoAP客户端可以发送一个观察请求到服务器端。从该时间点开始计算，服务器便会记住客户端的连接信息，一旦温度发生变化，服务器将会把新结果发送给客户端。如果客户端不在希望获得温度检测结果，那么客户端将会发送一个RST复位请求，此时服务器便会清除与客户端的连接信息。

CoAP块传输

CoAP协议的特点是传输的内容小巧精简，但是在某些情况下不得不传输较大的数据。在这种情况下可以使用CoAP协议中的某个选项设定分块传输的大小，那么无论是服务器或客户端可完成分片和组装这两个动作。

最近做了一个项目，使用GPRS模块上传数据应用UDP协议，而服务器没有应答机制。每个数据包均包括一个序列号，序列号占用两个字节。为了保证客户端上传的数据服务器可以收到，客户端采用重发机制，简单的说同一个数据发送2次或者3次，为了区别同一个数据包还加入了子序列号。项目进行到最后出现了一些问题，对比CoAP协议做一个总结。

一个数据包是否需要应答？

这个需要分情况而定，如果是一个传感器的温度数据，那么传输该数据时可能不需要应答，因为即使该数据丢失了下一时刻新的数据也会把旧的数据覆盖掉。但是如果温度超过一个阈值通俗的讲便是温度报警，在这种情况下传输该数据包往往需要应答，必须要保证服务器接收到该数据包，温度报警往往预示着一个紧急情况即将发生或已经发生。从这个角度看看CoAP协议便发觉CoAP协议设计的非常好，CoAP协议支持4种消息，例如CON需确认消息，NON无需确认消息，CON和NON便可解决该项目的困惑。可以肯定的是，继续研究CoAP协议将会获得更大的收获。

开源实现

维基百科：http://en.wikipedia.org/wiki/Constrained_Application_Protocol

其中两个开源版本：libcoap（C语言实现）和Californium（java语言实现），比较实用。