摘要

  • RFC 7641 让客户端以较低开销持续获得 CoAP 资源的当前表示，但它不保证每一个中间状态都能抵达。
  • 24 位 Observe 比较、128 秒时间条件与 Max-Age 解决“哪个表示还能当作当前状态”，并不构成可重放的队列或事件账本。
  • 可问责系统应保存最后接受的表示、新鲜度依据、刷新与取消结果，并显式标记未知缺口；若每次变化都重要，就必须另加持久队列、事件日志或应用层确认。

一次 GET 建立的是关系

客户端发送带有 Observe=0 和自选 Token 的 GET。服务器若返回同时带 Observe 的 2.xx 响应，就建立了由客户端端点与 Token 标识的观察者条目。此后的通知仍是对那一次扩展 GET 的追加响应。服务器不愿或无法保存条目时，可以像普通 GET 一样应答而不带 Observe；客户端由此知道自己不会收到变化，只能改为轮询。

这项设计把有限资源用在真正变化上。温度没有变，就不必反复传送相同表示。缓存与代理可以参与，多个下游客户端还可以共用一次上游观察。对电池、带宽和服务器状态都紧张的环境，这不是小优化，而是协议得以落地的条件。

边界同样写得清楚。RFC 7641 追求尽力而为与最终一致。如果资源不再变化，注册的观察者最终应获得当前表示；在变化过快或网络拥塞时，服务器可以跳过任意数量的中间状态。Observe 因而是“保持足够新的当前状态”机制，而不是让每个事件排队等待消费的消息队列。

24 位只回答发送先后

每个成功通知都会回显客户端 Token，并携带 Observe 值。服务器取严格递增序列号的低 24 位，客户端使用串行数算法比较先后。因此，回绕后的较小数值可以正确地被判定为比回绕前的大数值更新。

规则还使用客户端本地接收时间。如果距离此前最新通知超过 128 秒，新到通知可以不再依赖序列差而被视为更新。这个条件限制小数值空间在长时间静默后的歧义。它没有给物理事件打时间戳，也没有告诉客户端静默期间发生了多少次变化。

服务器也不得在不足 256 秒内跨越超过一半的 24 位空间。这保证比较仍有意义，却不能证明服务器重启后如何恢复序列、代理压缩了什么，或者客户端丢失 Token 后重新建立的是不是同一段连续历史。那些都需要实现证据。

过期撤销的是信赖资格

Max-Age 表示观察状态与实际状态之间的偏差还能被接受多久。在年龄超过它之后，客户端不得继续假定旧表示反映资源当前状态，可以刷新或以原 Token 重新注册。

过期不等于资源已经改变，不等于通知丢失，也不等于服务器故障。它只把“已知当前”降为“未知”。若界面把未知自动显示为正常、零值或沿用旧值，那是产品在替所有者选择风险策略。规范没有授权这个决定。

Confirmable 消息也不能补出历史。CoAP 的确认表示对应消息抵达；Observe 通知可以独立选择 Confirmable 或 Non-confirmable。某个通知得到 ACK，并不证明此前每个资源状态都发送、接收、保存并执行过。

取消不是全局原子动作

客户端可以忘记观察关系。以后收到无法识别 Token 的 Confirmable 通知时，它应以 Reset 拒绝，服务器随后清理条目；客户端也可以发送同一 Token、Observe=1 的 GET 主动注销。Reset 或注销请求都可能丢失。客户端认为已经结束时，服务器仍可能保留状态并继续发包。

RFC 通过可确认通知、重传与超时逐步回收失联观察者，但这不是双方同时看见的事务。如果隐私、无线唤醒成本或服务器容量依赖迅速终止，产品就需要显示注销是否完成，并提供有界重试，而不能只把本地按钮变灰。

代理会制造自己的“现在”

中介可以把多个下游观察合并为一次上游注册，再向客户端分发通知。每一跳独立决定通知数量和消息类型，生成本跳的 Observe 值，并根据自己的当前表示设置 Max-Age。规模效率提高了，证据链也多了一层。

这不是违规。问题出在产品把代理后的流描述成未经加工的源端历史，却不说明哪一跳刷新、重启、跳过或取消。测试必须穿过代理，对照源端与下游的 Token、Observe、Max-Age 和时间记录。