3. CoAP 消息模型：请求/响应、Confirmable / Non-confirmable
概念解释
CoAP 的消息模型建立在 HTTP 式的请求/响应交互之上，但针对物联网受限环境做了精简。每条消息由 Method（GET、POST、PUT、DELETE）与 Response Code（2.xx 成功、4.xx 客户端错误、5.xx 服务器错误）组成。与 HTTP 最大的不同是，CoAP 定义了两种可靠等级的消息：
- Confirmable (CON) — 需要接收方回复 ACK（确认），若超时未收到 ACK，发送方按指数退避重传，最终超时失败。适用于命令类、状态设置类等需要保证送达的场景。
- Non-confirmable (NON) — 发送后不需要 ACK，接收方也不会回复确认。适用于周期上报、日志、事件通知等可容忍少量丢失的场景。
一个完整的 CoAP 请求/响应交互可以是 CON→CON、CON→NON、NON→CON 或 NON→NON（RST 用于拒绝）。最常见的是客户端发送 CON 请求，服务端回 CON 响应（携带 ACK 或独立响应）。
关键点：CoAP 不强制所有请求都是 CON，也不要求响应必须与请求同类型。开发者可根据业务对可靠性的要求自由组合。
流程拆解
下面以设备读取传感器数据为例，展示 CON 和 NON 两条典型路径：
- CON 可靠路径
- 客户端构造 CON 消息（Message ID = X），包含 GET 请求，Options 指定资源路径。
- 服务端收到后立即回复一个空 ACK（Message ID = X），表示已接收；再延后发送一个带数据的 CON 响应（或 Piggybacked Response 直接在 ACK 中携带）。
- 若客户端未收到 ACK，则在超时后重发同一 Message ID 的 CON（最多 4 次，重传间隔指数增长）。
- NON 不可靠路径
- 客户端构造 NON 消息，不等待确认，发送即结束。
- 服务端处理请求后，也以 NON 消息返回响应（可选）。
- 发送方不重传，丢包由应用层或更高层协议（如重复数据过滤）处理。
流程对比：CON 引入了两次消息交换（CON + ACK），NON 只需一次发送，通道占用更少，但可靠性依赖链路质量。
案例分析
温湿度传感器每 10 秒上报数据（NON） + 远程控制继电器开关（CON）
某楼宇自动化场景中，部署了 200 个低功耗无线温湿度节点和一个中央控制器。
- 温湿度节点使用 NON 消息定期（每 10 秒）向控制器 POST 数据：
/sensor/temperature。节点无需等待 ACK，发送后可立即休眠，节省电池寿命。偶有丢包不影响整体趋势。 - 控制器下发“关闭 3 楼空调”指令时，使用 CON 消息 PUT
/actuator/relay/3。若空调节点 3 秒内未回复 ACK，控制器重试 3 次，仍失败后告警。确保指令必须被执行，避免安全事故。
若一律使用 CON，200 个节点每 10 秒发送 200 次 CON 并等待 ACK，不仅增加信道碰撞概率，还使节点无法及时休眠，功耗上升 3~5 倍。若一律使用 NON，则控制指令丢失可能导致设备状态不一致。按业务分开选用是设计的关键。
表格总结：CON vs NON
| 特性 | CON（Confirmable） | NON（Non-confirmable） |
|---|---|---|
| 是否需要 ACK | 是（必须收到 ACK 或响应中携带） | 否 |
| 重传机制 | 指数退避重传（默认最多 4 次） | 无重传 |
| 可靠性 | 高（确认语义） | 低（最好努力交付） |
| 典型场景 | 命令控制、配置写入、状态设置 | 周期性上报、日志、广播 |
| 功耗影响 | 较高（需保持接收 ACK 窗口） | 低（发送后立即休眠） |
| 信道占用 | 2 次或以上消息交换 | 1 次消息发送 |
实践清单：选择消息类型的决策要点
- 检查业务容忍度：该消息丢失是否导致严重事故？是 → 选 CON；否 → 选 NON。
- 评估网络质量：丢包率 > 10% 且消息重要，用 CON + 合理超时；丢包率低且数据可重复，用 NON。
- 考虑节点供电：电池供电且对功耗极敏感，优先 NON；主供电或可频繁充电的设备可多用 CON。
- 观察响应是否可缓存：若响应是幂等的，可用 NON 客户端重试（客户端自维护超时）。
- 组合使用：允许同一设备的请求和响应使用不同可靠等级，需在实现中明确标记 Message ID 及 Token。
常见错误：将 CON 消息的 ACK 超时时间设得过短（< 1 秒），导致不必要的重传拥塞；或将 NON 用于不可幂等的写操作，造成数据不一致。