摘要

  • RFC 3408 只允许可靠模式里的 R-0 包变成无头包，而且辅助层必须另行提供包类型与序列号证据。
  • 一旦辅助层无法保证接收端会还原出正确序列，它就必须记录 SN_break、停止无头发送，直到后续更新已在断点之后得到确认。

“零字节”很容易让人误以为协议开销被彻底消灭。RFC 3243 给出的背景却更具体：某些无线链路只接受离散的包长，一字节 ROHC 头部足以触发下一档物理包长。省下一字节的收益来自阶梯边界，而不是普遍适用的压缩定律。换一种链路、语音负载或包长，账本就可能完全不同。

RFC 3242 先为单向模式和双向乐观模式设计了链路辅助方案。它没有把头部携带的含义当成可以删除的装饰。接收方仍需知道这是无头包还是带 ROHC 头部的包；丢包后仍需推进序列；乱序仍不能破坏推断。因此，辅助层必须区分包型、保证所依赖的有序交付，并对每次相关链路丢失给出指示。线上少了一段字段，层间多了一组必须兑现的信号。

RFC 3408 把这套安排扩展到可靠模式，但权限收得很窄。只有 R-0 能映射成 NHP，无头包。接收端用“最近一次安全参考序列号加偏移量”还原 RTP 序列号。标准没有假装所有链路都能用同一种公式，而是要求具体链路的实现文档说明偏移量怎样获得。

一种办法是统计上次成功上下文更新以来的所有非更新包与丢包指示；另一种办法是在链路定时与 RTP 序列之间维持线性映射。二者都不是凭空猜数。它们把原先随头部到达的证据，改由链路状态、事件计数或时序关系提供。缺少这些输入时，负载内容仍在，并不代表接收端知道它属于哪个序列位置。

真正体现治理边界的是“不安全”状态。压缩器可能仍允许 NHP，但辅助层已经不能保证对端会正确解压序列号。此时辅助层要把对应的 RTP 序列记为 SN_break，随后暂停无头包。恢复需要同时满足两件事：链路重新符合安全发送规则，并且最近确认的 SN_ACKed 已越过断点。旧确认不能替新状态背书。

被动等待下一次上下文更新可能很久。RFC 3408 因而建议增加一条可选接口，让辅助层向压缩器发送 update_request，请求下一包更新上下文。如果辅助层和压缩器不在同一位置，请求可能在不可靠通道中丢失；规范把后果限定为恢复无头效率更慢。请求重发频率留给实现决定，但丢失请求并不允许系统跳过确认条件。

可靠模式还保留了清楚的上下文界线。NHP 与丢包指示不会更新压缩器或解压器上下文。R-0 本身没有 CRC，因此不像 U/O 模式那样需要替代被省掉的 CRC 功能。六位序列号回绕时出现的 R-0-CRC，会自然提供周期性的上下文核验。省掉一个字节没有削弱“安全参考”的原则。

反馈放在哪里也会影响零字节路径。RFC 3408 不建议用插入数据流的反馈包承载 ACK，因为它会打断 RTP 序列连续性，暂时禁止 NHP。控制面里看似普通的封装选择，会改变数据面能否继续省略头部。

安全章节讨论的主要是可用性。攻击者若能注入带随机 CRC 的虚假上下文检查包，就可能制造错误校验失败，触发上下文失效、反馈与刷新。攻击者无需伪造语音内容，只要让系统不断退回昂贵路径，就能抹掉优化收益。

后来的 ROHC 框架与 ROHCv2 文档重新整理了更大的体系，IANA 注册表也保留了相关配置编号；这些材料都不等于 RFC 3408 的部署成绩单。它更值得保留的历史规则是：字段从报文里消失时，其功能必须在别处以可识别的责任、证据和恢复条件重新出现。

Sources