物联网受限网络：分块传输与状态订阅各守什么边界

物联网节点使用CoAP后，报文头变小并不代表大数据一定传得稳，状态订阅也不等于完整事件流。受限网络要分别控制一次传输占用的资源，以及客户端看到的状态是否仍然新鲜。

大报文的风险首先出在底层分片。一个应用报文若被拆成多个链路片段，接收端通常需要等到相关片段齐备后才能重组；任一关键片段丢失，都可能使整个上层数据报无法使用。在其他条件近似时，涉及片段越多，一次完整重组所需的成功接收条件越苛刻。低功耗节点的重组缓冲还会被未完成报文占用，使并发通信更容易触及内存上限。因此，应区分应用载荷大小、传输层开销与链路实际可用空间，不能仅根据IP层看似允许的报文长度决定发送规模。

CoAP分块传输把较大的资源表示拆成可分别处理的应用块，让失败恢复能够限定在较小范围，但块大小并非越小越好。小块增加请求响应轮次与报文头比例，长往返链路上的总完成时间可能明显变长；大块减少交互，却更容易再次触发底层分片。配置时还要预留安全封装、选项和网络头部的空间，同样的应用块在不同安全模式下可能产生不同的最终报文长度。应以实际抓包和内存测量为依据，寻找可接受的轮次、片段数和缓冲占用之间的平衡。

分块接收还需确认各块是否属于同一份资源表示。若读取过程中资源发生变化，直接拼接先前版本的前半段与当前版本的后半段，就可能得到格式正确但内容不一致的结果。可结合实体标签等版本依据检查表示一致性，检测到变化后重新获取，或在服务端保持一次读取所需的稳定快照。上传场景也要限定未完成块的保存时间与并发数量，避免慢速传输长期占住资源。分块改善的是资源管理和恢复粒度，不能替代对资源版本、完成条件及超时清理的约束。

状态订阅面对的则是另一道边界。Observe机制让服务端在资源状态变化后向观察者发送新的表示，客户端维护的是所观察资源的当前视图。它并不承诺为每一次短暂变化保存一条不可遗漏的历史记录。若阀门短时开启后又关闭，观察端最终看到关闭状态，并不能据此证明中间从未开启。对累计读数或当前配置，这类状态收敛往往足够；审计每次动作需要持久事件记录，不能只数通知次数。

物联网客户端接收通知时，应按Observe定义的序号比较规则处理乱序，而不是简单把数值更大的一条当作更新。计数存在回绕，协议还对相隔较长时间的比较给出规则，因此实现需要遵循完整条件。资源表示中的有效期同样不可忽略：在有效期内可以按策略使用缓存，超过后若没有得到更新或重新验证，就应把状态标成未知或陈旧。连接尚在也不能延长数据的新鲜度，否则旧状态会被无限期当成当前事实。

通知确认也只解决相应报文交互的问题，不能保证设备的每次物理变化都被完整采集。对于变化频率高于可发送频率的资源，服务端可能只能让观察者逐步获得较新的表示。客户端可显示最近有效状态，同时记录最近一次成功更新的时刻与质量，避免操作人员将缺少变化误解成设备稳定。测试时应分别注入通知丢失、乱序与长时间静默，检查视图是否会回退、是否按期失效。历史完整性应直接用事件记录核验。

受限网络的可靠使用，要让分块传输管理有限资源，让状态订阅维护有时效的视图。资源能完整取回与历史能完整保留，是两种需要分别验证的结果。