阅读时间：约 15 分钟
标签：#CoAP #IoT #RFC7252 #LwM2M #协议栈

---

1. 引言：巴别塔下的“微型”信徒

在物联网的构建初期，我们往往陷入一种错觉：认为将互联网现有的协议栈（HTTP, TCP/IP）直接下移到嵌入式设备即可万事大吉。然而，现实是残酷的。对于一个只有 32KB RAM、依靠电池供电、处于蜂窝网络边缘（NB-IoT 或 LoRa）的传感器节点来说，HTTP 协议那繁复的 Header（动辄数百字节的文本开销）和 TCP 协议那沉重的“三次握手”与拥塞控制机制，无异于让一辆重型卡车在乡间土路上强行掉头。

如果说 MQTT 是物联网消息总线上的“轻型轿车”，那么 CoAP (Constrained Application Protocol) 则是为这片资源受限的“荒原”设计的“越野摩托”。

本文将摒弃常规的“入门教程”式写法，而是站在 RFC 7252 规范制定者的视角，结合 TR-069/TR-369 (USP) 的演进逻辑，深度考古 CoAP 的设计哲学，并通过报文抓取与状态机分析，带你通过 4 字节的头部玩转物联网。

---

2. 协议考古：从 REST 到“受限 REST”的哲学跃迁

2.1 为什么不是 MQTT？（设计哲学的差异）

很多工程师会问：“我已经很熟悉 MQTT 了，为什么还要学 CoAP？”

这就好比在问“为什么有了 Java 还需要 C 语言”。MQTT 和 CoAP 并非单纯的竞争关系，而是针对不同场景的架构级互补。

• MQTT (Message Queuing Telemetry Transport)：
  • 模型：发布/订阅。
  • 核心：解耦生产者与消费者，依赖中心化的 Broker。
  • 痛点：TCP 长连接在弱网环境下维护成本极高（心跳丢包导致连接断开），且 Topic 路由在超大规模网络中存在瓶颈。
• CoAP (Constrained Application Protocol)：
  • 模型：请求/响应，完美映射 HTTP 的 REST 架构。
  • 核心：一对一的设备间交互，支持多播，无状态。
  • 优势：基于 UDP，无连接建立开销；支持 Observe (RFC 7641) 扩展实现类似订阅的功能。

深度洞察：CoAP 的本质是将 Web（HTTP）的语义在 UDP 之上重新实现了一遍。它保留了 GET, POST, PUT, DELETE 方法，保留了 URI，甚至保留了 Content-Format（类似 MIME）。这意味着你可以像写 Web 后端一样写设备端代码，但传输层却极其精简。

2.2 协议栈全景图

CoAP 并非凭空出世，它处于 OSI 模型的应用层，但为了适应受限环境，它定义了自己的分层结构：

---

3. 核心拆解：4 字节头部的极致压缩艺术

CoAP 之所以被称为“受限”协议，核心在于其极简的报文结构。让我们通过 Wireshark 的视角来解剖它。

3.1 报文结构：Fixed Header

CoAP 的固定头部仅为 4 字节，相比 HTTP 动辄几十字节的文本头部，这是数量级的压缩。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Ver| Type |  TKL  |    Code     |          Message ID           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Token (if any, TKL bytes) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options (if any) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1 1 1 1 1 1 1 1|    Payload (if any) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

关键字段考古：

• Ver (2 bits)：版本号，目前为 1。简单明了，不像 IPv4/IPv6 那样纠结。
• Type (2 bits)：消息类型，这是 CoAP 可靠传输的核心。
  • 00 (CON): Confirmable。需要 ACK。
  • 01 (NON): Non-Confirmable。类似 UDP 发后即忘。
  • 10 (ACK): Acknowledgement。
  • 11 (RST): Reset，表示拒绝或错误。
• TKL (4 bits)：Token Length。Token 用于异步匹配请求与响应（类似 HTTP 的 Session ID 但更轻）。
• Code (8 bits)：类似于 HTTP 状态码。
  • 0.01 (GET), 0.02 (POST), 0.03 (PUT), 0.04 (DELETE)
  • 2.05 (Content), 4.04 (Not Found)
• Message ID (16 bits)：用于去重和匹配 CON/ACK。

3.2 实战抓包：CoAP 握手与数据交互

让我们模拟一个 NB-IoT 烟感探测器向服务器上报温度的场景。这里使用 libcoap 实现。

场景：Client 发送 CON 消息 -> Server 返回 ACK (Piggybacked Response)。

报文深度解析：

1. 请求包:

   • 54 01 : 0101 (Ver=1) 00 (Type=CON) 0000 (TKL=0) 00000001 (Code=GET)
   • BE 01: Message ID.
   • B1 6C 6F 63 61 6C 68 6F 73 74: Option Delta=11 (Uri-Host: localhost).

2. 响应包:

   • 64 45 : Ver=1, Type=ACK, Code=2.05 (Content).
   • FF: Payload Marker.

设计哲学：注意 ACK 消息中的 Message ID (BE 01) 必须与 CON 消息一致。这是 CoAP 在 UDP 之上实现“伪连接”可靠性的机制。如果服务器收到重复的 Message ID，会直接丢弃，防止重复处理。

---

4. 进阶机制：CoAP 如何解决 UDP 的不可靠？

很多人认为 UDP 不可靠，所以 CoAP 不可靠。这是大错特错。CoAP 引入了简单的停止等待机制。

4.1 Confirmable 消息的重传

如果 Client 发送了 CON 消息但没有收到 ACK，CoAP 协议栈（而非应用层）会自动触发重传。

• 初始超时：ACK_TIMEOUT (默认 2s - 3s，需随机化以避免同步风暴)。
• 退避算法：每次重传时间翻倍。
• 最大重传次数：默认 4 次。

这种机制类似于 TR-069 (CWMP) 中的 Session 重试逻辑，但 CoAP 将其下沉到了协议报文层，极大地解放了应用层开发者。

4.2 分块传输

在物联网场景中，OTA 固件升级或传输图片是常见需求。UDP 有 MTU 限制（通常 1500 字节，但在 6LoWPAN 中甚至只有 127 字节）。

CoAP 通过 Block1 (传输请求) 和 Block2 (传输响应) 选项来实现分块。

• Block Option 格式：<SZX> <M> <NUM>
  • SZX: 块大小指数 (0=16B, …, 6=1024B)。
  • M: More flag (1 表示还有后续块)。
  • NUM: 当前块序号。

实战场景：设备上传一张 50KB 的 JPEG 图片。

1. Client 发送 POST，携带 Block1 (Num=0, M=1, Szx=6)。
2. Server 回复 ACK，包含 Block1 (Num=0, M=1)，表示接收成功。
3. Client 继续发送 Block1 (Num=1…)，直到 M=0。

---

5. 纵向对比：CoAP vs MQTT vs HTTP

为了更直观地理解 CoAP 的定位，我们引入 HTTP 和 MQTT 进行多维度对比。

维度	CoAP	MQTT	HTTP (REST)
传输层	UDP (无连接，低开销)	TCP (有连接，保活开销)	TCP
通讯模型	Request/Response (同步/异步)	Publish/Subscribe (异步)	Request/Response
头部开销	极低 (4 Bytes Fixed)	低 (2 Bytes Min)	高 (文本流，数百 Bytes)
QoS 等级	2 层 (CON/NON, 轻量级)	3 层 (0, 1, 2，复杂)	依赖 TCP
多播支持	原生支持 (UDP 特性)	不支持 (需 Broker 扩展)	不支持
资源发现	/.well-known/core	N/A	HTML/Sitemap
适用场景	NB-IoT, LoRa, 资源受限传感器	不稳定网络下的即时通讯, 车联网	通用 Web, 互联
安全性	DTLS / OSCORE	TLS	TLS

专家点评：

• 如果你需要控制设备（如开关灯、读取配置），CoAP 的 Request/Response 模型比 MQTT 的 Pub/Sub 更符合直觉。
• 如果你需要海量数据流（如遥测数据流），MQTT 可能更高效。
• OSCORE (Object Security for Constrained RESTful Environments, RFC 8613) 是 CoAP 的杀手锏，它提供了端到端的应用层加密，即使消息经过网关或代理，内容也是加密的，这比 TLS/DTLS 的逐跳加密更安全。

---

6. 行业生态：从 LwM2M 到 TR-369 (USP)

CoAP 不仅仅是一个协议，它是 IoT 标准化的基石。

6.1 LwM2M (Lightweight Machine-to-Machine)

OMA SpecWorks 定义的 LwM2M 协议是 CoAP 最成功的应用案例。

• 对象模型：LwM2M 定义了标准的 Object 和 Resource ID。
  • Object ID 3 (Device): 包含 Manufacturer, Model Number。
  • Object ID 3303 (Temperature): 包含 Sensor Value。
• TLV 编码：为了进一步压缩载荷，LwM2M 常使用 TLV (Type-Length-Value) 格式编码数据，配合 CoAP 传输，效率极高。

6.2 TR-369 (USP) 与 协议融合

Broadband Forum (BBF) 的 TR-369 (USP - User Services Platform) 是智能家居和网关管理的下一代标准。
虽然 USP 官方参考实现使用了 MQTT 或 WebSockets 作为 MTP (Message Transfer Protocol)，但其数据模型深受 CoAP/REST 哲学的影响。

• TR-069 (CWMP) 基于 SOAP/HTTP，极其臃肿。
• TR-369 (USP) 采用了基于记录的协议，但其命令结构（Get, Set, Operate, Add, Delete）与 CoAP 的 RESTful 风格高度对齐。

考古视角：为什么 USP 没有直接用 CoAP？因为 USP 更关注 Controller 和 Agent 之间的复杂事务（如固件升级的状态机、分层级的故障诊断），这需要比 CoAP 更厚的传输层（如 WebSocket）来承载 Record 语义。但在边缘侧的传感器网络，CoAP 依然是王者。

---

7. 总结与最佳实践

CoAP 是针对“受限”环境优化的工程奇迹。它没有试图重新发明轮子，而是聪明地将 Web 的成熟架构（REST）嫁接在轻量的 UDP 传输之上。

给架构师的最后建议：

1. 不要迷信 TCP：在 NB-IoT 或 LoRa 场景下，TCP 的拥塞控制算法往往是反作用力。CoAP 的简单重传机制足以应付偶发的丢包。
2. 利用多播：CoAP 的多播能力（例如 FF02::FD）可以让你用一条指令同时配置成百上千个路灯，这是 MQTT 难以企及的。
3. 安全性：务必启用 DTLS 或 OSCORE。UDP 是开放的，明文传输在物联网环境中是巨大的隐患。
4. 报文分析：在调试 CoAP 时，不要只看 Log，抓包看 4 字节 Header 和 Option 的编码，能帮你发现许多隐蔽的对齐或解析 Bug。

CoAP 证明了：Simple is the ultimate sophistication.（至繁归于至简）。

---

参考引用：

• RFC 7252 - The Constrained Application Protocol (CoAP)
• RFC 7641 - Observing Resources in CoAP
• RFC 7959 - Block-Wise Transfers in CoAP
• OMA SpecWorks - LwM2M
• Broadband Forum - TR-369 (USP)