4. CoAP协议特性详解：观察者模式、块传输与资源目录
好，咱们进入CoAP协议最核心的三个特性。说实话，这三个特性是CoAP能在物联网领域站稳脚跟的关键。我最早接触CoAP时，觉得它就是个简化版HTTP，直到深入项目才发现——这些特性才是真正的杀手锏。
4.1 观察者模式（Observe）——让服务器主动“汇报”
先聊聊观察者模式。你想想看，传统HTTP是怎么获取数据的？客户端不停地轮询，每隔几秒发一次GET请求。这在PC端没问题，但在资源受限的物联网设备上，这就是灾难。
观察者模式的核心思想：客户端注册一个“观察”请求，服务器在有新数据时主动推送。说白了，就是从“你去问”变成“它来说”。
关键机制：
- 客户端在GET请求中加上
Observe: 0选项 - 服务器返回
2.05 Content，并带上一个递增的观察编号 - 当资源变化时，服务器主动发送通知
- 客户端可以随时取消观察（发送RST或带Observe: 1的GET）
我在一个智能农业项目中用过这个特性。传感器节点每5分钟上报一次温湿度，如果用轮询，网关得同时管理几百个定时器，CPU占用率直接飙到80%。换成观察者模式后，服务器只在数据变化超过阈值时才推送，网关负载降到了15%。
避坑指南：
我曾经踩过一个坑——观察者模式的通知是非可靠传输的。如果网络丢包，客户端可能错过更新。解决方案是：在关键数据上使用CON（确认）消息，或者客户端定期发送“心跳”GET来同步状态。
4.2 块传输（Block-wise Transfer）——大数据的“分片”艺术
CoAP默认基于UDP，单个数据报最大只有64KB（实际受MTU限制，通常1500字节左右）。那如果我要传输一个固件包（比如500KB）怎么办？
块传输就是干这个的。它把大数据切成多个小块，每个块独立传输，接收方再拼回去。
块传输的两种模式：
| 模式 | 描述 | 适用场景 |
|---|---|---|
| Block1 | 请求体分块（客户端上传） | 固件升级、大文件上传 |
| Block2 | 响应体分块（服务器下载） | 日志下载、配置备份 |
每个块请求都包含三个关键参数：
- 块编号（NUM）：当前是第几个块（从0开始）
- 块大小（SZX）：2的幂次，如16、32、64、128、256、512、1024字节
- 是否结束（M）：1表示还有后续块，0表示这是最后一块
代码示例：ESP32上的块传输下载
// 客户端请求第一个块（块大小256字节）
GET /firmware.bin
Block2: 0, 256, 1
// 服务器响应
2.05 Content
Block2: 0, 256, 1
[前256字节数据]
// 客户端请求第二个块
GET /firmware.bin
Block2: 1, 256, 1
// 服务器响应
2.05 Content
Block2: 1, 256, 0 // M=0，表示这是最后一块
[剩余数据]我个人习惯在固件升级时使用动态块大小调整。如果网络质量好，用1024字节的块；如果丢包率高，自动降到128字节。嗯，这个策略帮我解决了不少弱网环境下的升级失败问题。
注意：块传输的顺序性很重要。如果块乱序到达，接收方需要缓存并重排。我在一个项目中遇到过块编号溢出（超过16位最大值），后来改用CoAP的Block-wise Transfer with Random Access扩展才解决。
4.3 资源目录（Resource Directory）——物联网的“黄页”
最后一个特性，资源目录。说白了，就是让设备能“自报家门”。
在大型物联网系统中，可能有成千上万个设备。每个设备提供什么资源？温度？湿度？开关状态？如果没有目录，客户端得一个个去问，效率极低。
资源目录的工作流程：
- 注册：设备启动后，向资源目录服务器（RD）发送POST请求，注册自己的资源
- 发现：客户端向RD发送GET请求，查询特定类型的资源
- 访问：客户端根据RD返回的地址，直接访问设备
注册示例：
// 设备注册自己的资源
POST /rd?ep=node-001<=/sensor/temp>;rt="temperature";if="sensor",
<=/sensor/humidity>;rt="humidity";if="sensor"
// 服务器返回注册ID
2.01 Created
Location: /rd/12345资源目录的核心参数：
| 参数 | 含义 | 示例 |
|---|---|---|
| ep | 设备端点名称 | node-001 |
| rt | 资源类型 | temperature |
| if | 接口类型 | sensor, actuator |
| lt | 注册有效期（秒） | 86400 |
我记得在一个智慧楼宇项目中，部署了300多个传感器节点。如果没有资源目录，客户端得维护一个巨大的静态IP列表，每次设备更换位置都得手动更新。用了RD后，设备自动注册，客户端通过查询 /rd-lookup?rt=temperature 就能拿到所有温度传感器的地址。
实战建议：
资源目录的心跳机制很重要。设备需要定期（比如每30分钟）发送 POST /rd/12345 来续约。如果设备离线超过有效期，RD会自动删除注册信息。我曾经遇到过设备死机后，RD里还残留着旧地址，导致客户端连接失败。后来加了心跳检测和自动清理，问题就解决了。
4.4 三个特性的协同工作
这三个特性不是孤立的。在实际项目中，它们经常配合使用：
- 观察者 + 块传输：服务器推送大文件时，可以用块传输分片，观察者模式通知客户端有新版本
- 资源目录 + 观察者：客户端可以观察RD上的查询结果，当有新设备注册时自动收到通知
- 块传输 + 资源目录：设备注册时如果资源描述太长，可以用块传输分片发送
举个例子，我在一个智能家居项目中，网关通过资源目录发现所有灯泡设备，然后用观察者模式监听每个灯泡的状态变化。当用户批量更新固件时，用块传输并行下发固件包。三个特性配合下来，整个系统既高效又稳定。
最后提醒：CoAP的这些特性虽然强大，但不是所有CoAP库都完整支持。选型时一定要确认库的RFC兼容性。我吃过这个亏——某个开源库号称支持Observe，结果在并发观察时内存泄漏，排查了两天才找到原因。
好了，这三个特性讲完了。下一章咱们会深入CoAP的安全机制——DTLS和OSCORE，那又是另一片天地。