3. CoAP协议核心特性：观察者模式、资源发现与块传输
CoAP（Constrained Application Protocol）专为物联网受限节点设计，其核心特性直接决定了设备接入的效率和功耗表现。本章聚焦三个对低功耗通信至关重要的特性：观察者模式（Observe）、资源发现（/.well-known/core）和块传输（Block-wise）。理解这些特性，是配置ThingsBoard网关与终端设备通信的基础。
3.1 观察者模式（Observe）—— 服务器主动推送，避免轮询
在传统HTTP模型中，客户端需要定期轮询（Polling）服务器以获取最新数据，这在物联网场景中会导致大量无效请求和功耗浪费。CoAP的观察者模式（RFC 7641）允许客户端“订阅”一个资源，当资源状态发生变化时，服务器主动向所有观察者推送更新。
核心价值：将通信模式从“客户端拉取”转变为“服务器推送”，显著减少网络交互次数，延长电池供电设备的休眠周期。
3.1.1 观察者模式工作流程
- 注册观察请求：客户端发送一个带有
Observe: 0选项的GET请求，表示希望观察该资源。 - 服务器确认：服务器返回当前资源状态，并在响应中包含
Observe选项和一个递增的序列号。 - 状态变更推送：当资源状态发生变化时，服务器立即向所有已注册的观察者发送包含新状态和递增序列号的非确认（Non-confirmable）或确认（Confirmable）响应。
- 取消观察：客户端发送一个带有
Observe: 1选项的GET请求，或直接发送RST报文取消订阅。
ThingsBoard实践提示：在ThingsBoard中，CoAP网关或设备端点默认支持Observe模式。当设备作为CoAP服务器时，ThingsBoard可以作为观察者订阅设备属性或遥测数据资源，实现实时数据更新，无需设备端频繁上报。
3.1.2 观察者模式与轮询模式对比
| 对比维度 | 轮询模式（Polling） | 观察者模式（Observe） |
|---|---|---|
| 通信方向 | 客户端主动请求 | 服务器主动推送 |
| 网络流量 | 高（大量无效请求） | 低（仅在有变化时传输） |
| 设备功耗 | 高（频繁唤醒收发） | 低（可深度休眠，等待推送） |
| 实时性 | 取决于轮询间隔 | 高（状态变化即推送） |
| 服务器负载 | 高（处理大量请求） | 低（仅处理状态变化） |
| 适用场景 | 低频、非实时数据采集 | 实时监控、告警、状态同步 |
3.2 资源发现（/.well-known/core）—— 设备能力自描述
CoAP设备通常资源受限，无法运行复杂的服务发现协议。为此，CoAP定义了标准化的资源发现机制，通过访问 /.well-known/core 路径，客户端可以获取服务器上所有可用资源的列表及其属性。
3.2.1 资源发现请求与响应
客户端向CoAP服务器发送一个GET请求到 /.well-known/core，服务器返回一个 application/link-format 格式的响应，其中包含资源链接描述。
// 客户端请求
REQ: GET coap://[设备IP]/.well-known/core
// 服务器响应（示例）
RES: 2.05 Content
</sensors/temperature>;rt="temperature";if="sensor",
</sensors/humidity>;rt="humidity";if="sensor",
</actuators/led>;rt="light";if="actuator",
</config>;rt="device-config";if="config"3.2.2 资源描述属性
| 属性 | 含义 | 示例值 |
|---|---|---|
rt |
资源类型（Resource Type） | temperature, light |
if |
接口描述（Interface Description） | sensor, actuator |
ct |
内容类型（Content Type） | 0 (text/plain), 50 (application/json) |
sz |
资源大小估计（Size） | 128 |
obs |
是否可观察（Observable） | 存在即表示支持Observe |
安全注意事项：在生产环境中，建议对
/.well-known/core 端点进行访问控制，避免暴露过多设备信息。ThingsBoard支持通过CoAP DTLS加密和访问令牌机制来保护资源发现过程。
3.3 块传输（Block-wise）—— 突破MTU限制，可靠传输大数据
物联网网络通常存在较小的最大传输单元（MTU），例如IEEE 802.15.4的MTU仅为127字节。CoAP的块传输机制（RFC 7959）允许将大型资源分割成多个小块，通过多次请求/响应交互完成传输，同时支持乱序传输和断点续传。
3.3.1 块传输核心参数
| 参数 | 位置 | 说明 |
|---|---|---|
NUM |
块编号 | 当前块在资源中的序号，从0开始 |
SZX |
块大小指数 | 实际块大小 = 2^(SZX + 4) 字节，SZX范围0-6 |
M |
更多标志 | 1表示后续还有更多块，0表示最后一块 |
3.3.2 块传输工作流程（上传大文件示例）
- 客户端发起第一块上传：发送POST/PUT请求，包含
Block1选项（NUM=0, SZX=2, M=1）和第一块数据。 - 服务器确认并请求下一块：服务器返回2.31 Continue，包含
Block1选项（NUM=0, SZX=2, M=1），表示已接收第一块，请发送第二块。 - 客户端发送后续块：客户端递增NUM，继续发送后续数据块，直到M标志为0。
- 传输完成：服务器返回2.01 Created或2.04 Changed，表示资源已完整创建或更新。
// 块上传示例（分3块上传一个固件包）
// 第一块：NUM=0, SZX=2 (64字节), M=1
REQ: PUT coap://[设备IP]/firmware
Block1: 0, 2, 1
Payload: [前64字节固件数据]
// 服务器响应：继续
RES: 2.31 Continue
Block1: 0, 2, 1
// 第二块：NUM=1, SZX=2, M=1
REQ: PUT coap://[设备IP]/firmware
Block1: 1, 2, 1
Payload: [中间64字节固件数据]
// 第三块：NUM=2, SZX=2, M=0 (最后一块)
REQ: PUT coap://[设备IP]/firmware
Block1: 2, 2, 0
Payload: [最后剩余固件数据]
// 服务器响应：创建成功
RES: 2.01 Created3.4 三大特性协同关系
在ThingsBoard的CoAP设备接入场景中，这三个特性通常协同工作：
- 资源发现用于设备上线时向ThingsBoard网关注册自身能力。
- 观察者模式用于ThingsBoard订阅设备的关键遥测数据，实现实时监控。
- 块传输用于设备上报大容量日志、固件升级包或历史数据缓存。
3.5 低功耗通信最佳实践
结合上述三大特性，在ThingsBoard中配置低功耗CoAP设备时，建议遵循以下原则：
低功耗配置清单：
- 优先使用Observe：对于温度、湿度等周期性变化的数据，让ThingsBoard作为观察者订阅，设备仅在数据变化时发送更新。
- 合理设置块大小：根据网络MTU选择SZX值，避免IP分片。对于IEEE 802.15.4网络，推荐SZX=2（64字节）或SZX=3（128字节）。
- 资源发现缓存：设备首次上线时通过
/.well-known/core注册资源，ThingsBoard缓存该信息，后续通信无需重复发现。 - 非确认消息：对于非关键遥测数据，使用Non-confirmable消息减少确认开销；对于固件升级等关键操作，使用Confirmable消息确保可靠传输。
3.6 本章小结
- 观察者模式实现了服务器主动推送，是低功耗通信的核心机制，适用于实时监控场景。
- 资源发现通过
/.well-known/core端点实现设备能力自描述，简化了设备接入配置。 - 块传输解决了受限网络中的大数据传输问题，支持分片、乱序和断点续传。
- 在ThingsBoard中，合理组合这三个特性可以构建高效、可靠、低功耗的物联网通信方案。