CoAP协议在资源受限设备上的实践：RESTful风格通信的物联网实现

为什么资源受限设备需要一种新协议

第一次在真实物联网项目里接触 CoAP，是在一台只有几十 KB RAM 的 MCU 上。当时团队要把它做成一个可被远程查询的温湿度节点，候选方案有 HTTP、MQTT 和 CoAP。HTTP 太庞大，TCP 连接的内存开销就不是小数目；MQTT 走订阅发布，对于这类一读一回答的场景反而有点绕。于是 CoAP 进入了视野。

CoAP 的全称是 Constrained Application Protocol，IETF 用了很长时间才让它在 RFC 7252 里稳定下来。它的目标很明确：在资源受限设备上，用类似 HTTP 的方式提供 RESTful 通信。你需要 GET、POST、PUT、DELETE 来表达意图，也用 URI 定位资源，甚至连错误码都能找到和 HTTP 的对应关系。但它的底层传输是 UDP，这是它与 HTTP 最大的分岔点，也是后来各种工程问题的主要来源。

设备受限到什么程度，才需要考虑 CoAP 而不是直接上 HTTP？很多人以为只看 RAM 大小，其实还要看使用场景和能耗预算。一个每周采一次数据，通过 LoRa 上报的传感器，和一台能流畅运行 Linux 的智能网关，对网络协议的要求完全不同。如果设备内存只有几百字节可用，一个完整的 TLS 握手都可能触发内存溢出。即使设备能力足够，网络链路可能很窄，时延很高，TCP 的多次往返会让交互变得极慢。CoAP 的设计是在这两个前提之间寻找平衡：协议头很小，默认基于 UDP，把复杂度留给可选的扩展。

RESTful 模型在 CoAP 上如何体现

很多文档喜欢把 CoAP 描述成 HTTP over UDP，这个说法容易让人误解。CoAP 确实是 RESTful 的，但它的消息模型是异步的。你发出一个 GET 请求，不代表下一秒就能收到响应，甚至你可能需要先发出一个独立的确认消息，才对上一个请求进行确认。这种设计能减少链路唤醒次数，但对习惯了 HTTP 同步请求的开发者来说，是一个认知转变。

在 CoAP 里，方法名看起来和 HTTP 一样：GET、POST、PUT、DELETE，另外还有 FETCH 和 PATCH。响应码也不是 200 404 这种三位数，而是 2.05、4.04 这种写法的两位编码。URI 照样存在，但在消息里通过 option 逐段编码，而不是一个完整的字符串。为了更直观地看到差异，这里列一张常用映射表：

资源的表示方式由 Content-Format 选项指定，常见的有 text/plain、application/link-format、application/octet-stream 等。如果你把 JSON 数据当作 text 返回，客户端就没法自动识别，对接时容易误解。这一点和 HTTP 的 Content-Type 很像，但在 CoAP 的 option 编码里更容易被漏掉。

CoAP 消息格式到底长什么样

为了让你对消息开销有一个直观感受，这里给一个最简 CoAP 数据包结构示例，通常用 C 语言可以这样描述：

typedef struct {
    uint8_t ver_type_tkl;   // 版本(2bit)、类型(2bit)、Token长度(4bit)
    uint8_t code;           // 例如 0.01=GET, 0.02=POST, 2.05=Content
    uint16_t message_id;    // 用于匹配 CON 与 ACK
    uint8_t token[8];       // 客户端生成的绑定 Token
    uint8_t options[];      // CoAP Option 区
    uint8_t payload_marker; // 固定 0xFF，表示后面是载荷
    uint8_t payload[];      // 应用数据
} coap_message_t;

这个结构里的每一部分都有明确作用，比如 message id 用于可靠传输，token 用于匹配请求与异步响应。初次接触容易搞混 message id 和 token，实际上它们是不同层级的标识。

CoAP 的可靠性：不是简单 UDP

真正麻烦的地方在于可靠性。UDP 本身不保证送达，CoAP 定义了两大类消息：CON 和 NON。CON 要求接收方返回 2 字节的 ACK 确认，发送方如果超时未收到 ACK，会按指数退避重发。NON 则不需要确认，适合周期上报这类允许偶发丢失的数据。

这里最容易踩的第一个坑，是把 CON 当成了应用层保证。比如一个设备的开关动作，你用 CON 发出去并收到了 ACK，这只能说明网关收到了 CoAP 消息，并不代表执行机构真的被触发了。如果事务处理流程的应用层没有返回状态，重传或业务错误都很难排查。

收到 ACK 不等于应用执行成功。CoAP 的可靠传输只能保证消息到达，应用状态还需要自己的状态机和超时设计。

第二个坑是不调整重传参数。CoAP 默认的 ACK_TIMEOUT 是 2 秒，但在低功耗传感器网络中，设备可能正在休眠，唤醒到接收需要 5 秒以上。一旦超时重传发生，整个网络的拥塞会被放大。类似问题通常需要通过调试日志观察重传和 ACK 情况，再针对网络类型设置参数。一些低功耗网络的信道非常窄，一个较大的资源响应可能需要切分成多块传输，这就牵出 CoAP 的 Blockwise 传输，也叫块传输。

这里还要区分两个容易混淆的标识：message id 和 token。message id 仅用于链路层确认，而 token 绑定的是请求与响应。如果服务端处理很慢，客户端可能收到多个相同 message id 的消息，但 token 不同，处理逻辑必须依赖 token 而不是 message id，否则会出现串数据。

资源发现、观察与块传输

CoAP 的实践价值不止 Request/Response。设备可以提供 /.well-known/core 资源，返回一个类似 link-format 的资源描述。这使得网关第一次接上设备时，不需要烧死配置就能知道设备支持哪些路径。在做电机控制器接入时，这一特性帮了很大的忙。

另一个高价值功能是 Observe。客户端带上 Observe 选项订阅某个资源，设备在资源变化时单播通知客户端。相比每次轮询，Observe 通信次数和等待时延都少了很多。但需要注意，Observe 通知并不是无限期的，服务器可能因为资源删除或超时取消订阅，客户端也要处理重新订阅的情况。

块传输解决的是 UDP 数据报大小限制的问题。比如一个包含升级包或大日志的资源，几百字节的数据可能被 IP 分片，如果中间有 NAT 或质量不高的链路，分片丢失经常出现。CoAP 的 Block1/Block2 允许把大资源拆成多个 block 传输。很多库默认支持，但如果你没有正确配置 block size，两端会陷入反复重传的困境。

安全与网络边界问题

说到 CoAP，安全上绕不开 DTLS。许多嵌入式系统的第一反应是：先用 PSK 预共享密钥跑，比证书轻。确实，PSK 在资源受限的环境中是合理选择，但也带来了密钥管理问题。一个设备出厂内置一把密钥，固件升级后发现密钥泄露，如何远程更新？如果没有一套密钥轮换机制，安全协议反而变成信任黑洞。

另外，CoAP 基于 UDP，跨公网时往往要面对 NAT、防火墙和运营商 UDP 限制。很多物联网平台实际上是在公网上跑 HTTP 或 MQTT，而不是直接暴露 CoAP。如果你的设备需要跨网络通信，比较常规的做法是设备连接边缘网关，网关把 CoAP 翻译成 HTTP 上报云端，这样既享受了设备端的轻量通信，也兼容了云服务的成熟链路。

值得注意的一点是，CoAP 支持组播，而组播下几乎没有可靠的 DTLS 握手方案。因此安全保护和资源发现最好分开处理：用组播做本地服务发现，用单播 DTLS 做实际控制。代理服务器的缓存行为也需要注意，CoAP 响应可以标记 cache-control，代理如果忽略它，设备会发现读取过的数据一直不更新。

CoAP、MQTT 与 HTTP：如何选择

现在把 CoAP、MQTT 和 HTTP 放在一起看，应该更清楚了。它们不是彼此的替代品，而是解决不同问题的方案。CoAP 在请求响应模型上最贴近 REST，适合设备作为服务端被控制或查询；MQTT 的模型是发布订阅，适合设备作为客户端不断上报数据，也更容易在公网穿透；HTTP 则适合设备能力强，数据量小，直接和 Web 服务交互的场景。

如果问我在一个设备上做控制命令，比如打开继电器，我更倾向于 CoAP，因为这天然是一个 PUT 操作。如果做的是每分钟上报一次电量，MQTT 会显得更顺手。而 HTTP 通常出现在设备本身有一定算力，并且需要直接兼容现有 Web 服务的情况下。

落地时，可以从一个最小闭环开始：

• 先在开发板上用开源 CoAP 库跑通资源发现、普通读写、Observe 三条路径，同时打印消息 id 和 token 的变化，理解异步响应的匹配逻辑；
• 把设备丢进实际网络，观察 ACK 超时和重传日志，再根据网络时延调节重传参数，不要使用默认值硬扛低功耗网络；
• 设计数据模型时，明确哪些资源需要 CON 保证，哪些可以用 NON 节省流量，并确认是否真的需要 Observe 或块传输；
• 安全方案从 PSK 起步，但要预留密钥更新通道；跨公网时优先考虑 CoAP 到 HTTP 的网关转换，避免直接穿透 UDP。

最后

CoAP 不是一个容器化的 HTTP 复刻品，也不是 UDP 上硬编码的协议。它真正解决的是受限设备如何在一些相对可信的局部网络里，优雅地暴露资源。如果你把它当作一种接口风格来理解，会发现它非常灵活。但如果你忽略底层传输和网络链路，它也会给你足够多的小麻烦。了解这些边界，才能在一次真实的物联网部署里做对选择。