6.3 CoAP：受限应用协议

6.3 CoAP：受限应用协议

CoAP 是给微内存、低功耗设备准备的"迷你 REST"。它跑在 UDP 上、头部更小、天然拥抱 IPv6，适合一问一答的受限设备。本节拆它的 REST 风格、资源发现与 U 层确认机制，以及和 MQTT 的分工。

这三个对照要入眼

阅读完本节，你应当能够：

1. 说清 CoAP 用 UDP 而非 TCP，靠什么换可靠性。
2. 解释 CoAP 与 HTTP 的风格相似（GET/POST）但底层体量不同。
3. 判断一个 RAM/内存极小、一问一答的传感器该用 CoAP 还是 MQTT。

一、给"内存只有几 KB"的设备准备

无线通道能低到几百 bps，大量传感节点的内存也只有可怜的几 KB。这种受限程度连 MQTT 的 TCP 连接与 QoS 都可能显得"重"。CoAP（Constrained Application Protocol，受限应用协议）就是为这类设备准备的——它把 Web 世界经典的 REST 风格，用一个轻到极致的包承载起来。

CoAP 用 UDP 承载，绕开了 TCP 的握手与连接开销，从而大幅省内存、省功耗、省延时。它的报文头只有固定的一段（通常就几个字节），非常适合同一问一答的传感小数据。开发者会觉得它眼熟——CoAP 的方法名（GET/POST/PUT/DELETE）与 URI 风格近乎照抄 HTTP，学过 Web 的人上手极快。

二、REST 化的思绪：把设备当资源

数 CoAP 的特色，最重要的是它的"Web 化"心智：

• 资源即对象：每台设备把状态、读数暴露成一堆"资源"（如 温度/房间X），用 URI 指认。
• 一比一映射 HTTP 方法：GET 读资源、POST 更新、PUT 写入、DELETE 删除。
• 确认与重传：可选 Confirmable 消息——发出去要等回 ACK，没回就重传；还有可观察（Observe）机制，让客户端订阅某资源的持续更新，不用轮询。

这套风格让 CoAP 的受限设备像"微型 Web 服务"一样被编程，既省资源又保持 Web 生态熟悉感，这是它在受限域高接受度的根。把 CoAP 一次"可确认"的一问一答画成时序，能解释它怎么在 UDP 上仍保住可靠性：

三、一张 MQTT 与 CoAP 的分工对照

判据一句话：极受限设备、一问一答、资源紧张 → CoAP；设备成百上千、要解耦一对多、要上云 broker → MQTT。二者在一些设计里还会"网关翻译"互相连——传感器送 CoAP，网关转成 MQTT 上云，各用所长。

四、一次"换网关不换语义"的混合演练

设想一座楼宇的几百个极省电温控传感器：它们内存极小，只做"读到温度就报一下、收到开关就执行"的一问一答，完全契合 CoAP。于是设计成：传感器跑 CoAP，与本层网关按 REST 一问一答；网关再把汇聚结果转成 MQTT 上云平台做集中管理。底层用 CoAP 省钱省内存的边界感，顶端用 MQTT 的 broker 能力服务于多后端消费——一次方案同时吃满两种协议的长处。

五、CoAP 的边界

CoAP 不是没短板：它一对一请求响应，解耦不如 MQTT 彻底；UDP 无连接，大流量可靠性要靠额外重传；与 Web 生态互通往往要网关映射。如果你优先要的是海量一对多解耦上报，那就老老实实 MQTT；如果设备受限到极致且只需一问一答，CoAP 是更对位的答案。

六、CoAP 到底能省多少字节：一次报文解剖

"CoAP 省"不能只停留在形容词，拆开看一条真实报文才算数。同样是一次"读温度"的请求，HTTP 和 CoAP 的开销差距很直观：

HTTP GET /temp  头部动辄 100+ 字节（方法行、多个 Header 字段、可能带 Cookie/UA）
CoAP GET /temp  固定短头约 4 字节（版本+类型+Token 长度+方法码）
                 + 可选的 2~8 字节 Token
                 + URI 占用数十字节
                 → 整体往往只有 HTTP 的十分之一甚至更少
​

这一差异四条链同时受益：内存（缓存区小）、功耗（带宽占用低、唤醒时间短）、时延（包小传输快）、以及弱网通过率（小包更不容易在中途被截断）。

占比更长一点，CoAP 还有一套 Blockwise（分块）传输：当一条确认消息的载荷太大（协议约 1024 字节上限之一），客户端与服务器会自动把数据切成若干块（block）逐块传输，避免 UDP 单包把网络打爆。这让 CoAP 能被拿去做固件升级这类稍大文件的传输，而不只是"传一条几字节读数"。所以别小看这个"受限协议"，它在"限制内能做的活"比想象中宽。

七、资源自报家门：CoAP 的"发现"能力

受限设备连地址都没有几字节富余，怎么让人知道它提供什么资源？CoAP 用一条近乎自动的"自我介绍"解决：设备提供一个标准入口，别人 GET 它，就返回一个资源清单（RFC 7252 的 .well-known/core 规范）。看一条示意：

客户端  GET  coap://[fe80::1]:5683/.well-known/core
服务器  返回  资源清单，比如：
  </temp>       → 只读，/temperature
  </switch/1>   → 可 POST 开关，第 1 枚按钮
  </config>     → 可 PUT 配置
​

这份清单让网关/上位机"扫一眼就接管"一台设备，不用逐一写死地址——对动辄几十上百台受限节点的大规模部署，省下一整套手工录入。配合前面说的 Observe，可观察订阅 + 资源发现，CoAP 在"极简 Web 服务"这条路上几乎把能省的全省了。它确实是 MQTT 之外，受限域里另一位搬砖扛把子。

八、重传与安全：UDP 上的可靠怎么来、跟安全怎么搭

前面提过 CoAP 用"可确认消息 + 重传"在 UDP 上抠可靠，这里展开它的机制，你才明白它为什么扛得住。当一个 Confirmable（CON）消息发出去，客户端就开始等服务器回 ACK；等不到，会按指数退避重发（初始约 2 秒、之后翻倍，最多重发数次），直到收到对端确认或放弃。这一套"自己管超时、自己管重发"把 TCP 的可靠搬运工作搬到应用层，代价是每次重发都让设备多醒一次，所以在极弱网下要合理设重试上限，别让重传把电耗光。

安全上，受限设备跑 HTTPS 太贵，CoAP 走的是 DTLS（Datagram TLS）——把 TLS 那套加密搬到 UDP 上，同样要握手、可配 PSK（预共享密钥）或证书。选 DTLS 要权衡：它给"极简"加了握手与运算开销，对内存仅几 KB 的设备依然吃力。最常碰到的坑是把 DTLS 上到本就紧张的节点上，导致握手内存不足反复掉线——所以要么给这类设备更宽裕的内存预算，要么在网关上做 DTLS 终结，让受限节点只做轻量的内部 CoAP 通信。理解这两条，CoAP 那份"省"才算在可靠与安全两条线上都被接住，而不是看着省、用起来却处处漏水。

本节要点回顾

• 天生受限：UDP 承载 + 超小头部，为几 KB 内存设备而生。
• REST 心智：资源即对象、方法即 GET/POST，比 MQTT 更贴近 Web。
• 可靠性自管：用 Confirmable 确认与重传，在 UDP 上筑牢下限。
• 分工判据：极受限一问一答 → CoAP；海量解耦上云 → MQTT。
• 可中庸：CoAP 前端 + MQTT 上云的异构组合常见适用。

轻量派还有向"企业级"挺进的分支。下一节看 AMQP 与 DDS——它们一个管重级消息路由与事务，一个管工业实时数据分发。