摘要

  • RFC 5372 的 mh_id 只有七个活动值。连续六次主头更新被随机丢包或选择性抑制后，新状态可以绕回旧缓存的同一编号；数值相等并不证明参数连续。
  • 接收端只有在完整收到主头时，才应把 RTP 序列号、编号与主头一起保存。编号不是内容摘要，也不是无限增长的版本号，更不是经过认证的新鲜度纪元。
  • mhc 协商、主头完整接收、缓存来源、补偿决定、解码器一致性检查与画面输出分别回答不同问题。优先级零表示头部重要，却不保证它必然送达。

攻击者不必伪造编号

在最直观的攻击想象里，对手会修改字段，把一个假值塞进数据包。RFC 5372 揭示的边界更微妙：如果对手能够让关键更新消失，它甚至不必碰最终抵达的编号。

发送端从一开始。编码参数改变后，它发送新主头并把 mh_id 推进到二。接收端没收到。之后三、四、五、六、七也分别伴随参数改变与新主头，却都在传输中消失。下一次改变发生时，有限编号空间绕回一。接收端手中仍有最初那份主头，也仍记着一。当前包同样显示一。

比较运算没有出错。错误发生在比较结果被赋予了过大的含义。

RFC 5372 的安全章节直接指出：该字段最多识别七个不同主头；严重丢包无论随机还是人为引入，只要让连续六次更新丢失，解码器就可能拿错误主头尝试解压。标准随后建议，在解码器发现主头与载荷不一致时，清除已保存的编号和主头。

这条链路说明，威胁不一定是“假包被相信”，也可能是“使真包缺席，从而让旧状态继续拥有权威”。完整性保护可以证明收到的包没有被改动，却无法为根本没有到达的六次状态转移作证。

丢失的不是六个普通包，而是六次失效通知

网络运营习惯把丢包压缩成比例：一分钟丢了多少，某条链路的平均损失率是多少。对主头补偿而言，位置与语义比平均数更重要。

六个普通压缩数据包丢失，可能降低画质。六个连续的参数更新主头丢失，则会删除缓存失效所需的历史。接收端缺少的不只是若干字节，而是“旧主头已经不再适用”的通知链。

因此，监控至少要回答：

  • 丢包是否发生在完整主头附近；
  • 丢失区间之前和之后的 mh_id 分别是什么；
  • 是否观察到从七回到一；
  • 发送端是否发生重启、换源或重新协商；
  • 当前缓存主头来自哪个 RTP 序列位置；
  • 补偿后解码器是否报告不一致；
  • 清缓存后是否重新完整获得主头。

只有总丢包率而没有事件位置，无法解释陈旧缓存风险。只有字段采样而没有序列来源，也无法区分稳定持续与整圈回绕。

三位字段是坐标，不是内容身份

mh_id 的名字容易诱导系统把它当成“主头 ID”，仿佛每个值永久对应一份内容。RFC 5372 明确否定这种一一对应关系。

发送端在规定的编码参数不变时保持编号；参数改变并发送新主头时推进编号。比较范围包括 SIZ，以及 COD、COC、RGN、QCD、QCC、POC 等功能标记段。编号本身并不携带这些内容，也不承诺字节级相等。

它更像一个可复用坐标：在最近历史连续可见的前提下，相同坐标允许接收端推断参数仍与上一帧相同。历史一旦出现足以容纳整圈变化的盲区，坐标就失去了唯一性。

可靠记录不能只写 mh_id=1。它还应保存会话与同步源、完整主头的 RTP 序列号、主头字节或稳定本地哈希、保存时间、此后观察到的编号转移以及清除原因。没有这些来源信息，编号只能证明“一个三位值被看见”，不能证明“当前解码状态是谁”。

完整收到主头，缓存才获得资格

RFC 5372 要求接收端在完整收到主头后，保存 RTP 序列号、mh_id 和主头，并且只保留最后一份完整收到的主头。

这条规则把“看见字段”和“拥有可复用对象”分开。最后一个主头分片到达，不证明此前分片齐全。某个包通过认证，不会补回缺失字节。SDP 接受 mhc=1，也不会自动把一份完整主头放进缓存。

一个严谨实现需要显式状态：尚无完整主头；已保存完整主头；观察到编号改变但新主头不完整；已用完整新主头替换；解码不一致后已失效；重新获得完整主头。把这些状态都压缩成“缓存开/关”，会掩盖最重要的来源区别。

替换动作同样需要凭证。编号改变时，接收端应保存当前完整主头与新编号，删除旧状态。若新主头没有完整到达，就不能仅凭新编号把旧对象重新命名。

相等只授权一次尝试

当前主头丢失、当前编号与已保存编号相同时，接收端可以用上一份主头尝试解码。这是补偿机制的价值所在：视频相邻帧的编码参数很少改变，重复发送的上下文偶尔丢失时，复用能避免不必要的画面中断。

“可以尝试”不是“已经证明”。编号相等不证明缓存新鲜，解码器接纳不证明输出正确，完成解码也不证明画面被目标应用显示。

至少应拆开六项结果：编号比较、补偿决策、解码资源接纳、解码结束、输出帧生成、下游显示或消费。每项的成功都只能回答自身问题。

如果监控在比较相等时立即记“恢复成功”，它会把随后发生的解码失败算到另一个组件。缓存机制获得成功率，解码器承担错误率，因果关系被组织边界拆散。

解码器发现不一致时，风险已经进入执行面

标准认为 JPEG 2000 解码器可能发现主头与 codestream 不一致，并建议届时清除缓存。这是一道重要的恢复防线，但不是事前认证。

在发现之前，接收端已经选择陈旧状态并把组合输入交给解码器。内存可能已经分配，时延预算可能已经消耗，错误也可能以丢帧、通用失败或降级输出的形式出现。规范没有声称所有不一致都会在任何输出之前被发现，也没有声称所有解码器以同样方式报告。

清除缓存完成的是阻断：不再继续复用已知可疑状态。它不会创造那六份丢失主头，也不会自动获得最新参数。真正恢复仍需一份新的完整主头，或者一条另有证据的替代路径。

运营记录应把“不一致发现”“缓存清除”“完整主头重新获得”“正常输出恢复”分别记账。只记录清除动作，会把处置误写成恢复。

零值明确撤销了补偿捷径

mh_id=0 不参加一到七的普通循环。RFC 5372 规定，接收端不得在零值下保存主头，也不得为丢失主头进行补偿。

零不是缺省主头，不是通配符，也不是“继续沿用上一个值”。数据清洗若把零转换成空值，再由下游填入最近值，就会反转协议意图。

监控要区分：扩展未启用；基础 RFC 5371 接收端忽略字段；协商返回 mhc=0；扩展启用且发送端使用 mh_id=0；非零编号但没有完整缓存；非零命中后尝试失败。它们都可能不发生补偿，却指向不同责任与下一步。

协商的是方法，不是运行时库存

RFC 5372 通过 video/jpeg2000 的 mhc 参数协商主头补偿。报价中使用一表示提出该能力；接受方在回答中体现接受。规范示例也展示了回答零：对端可以拒绝补偿，同时接受色彩、尺寸或优先级等其他属性。

mhc=1 是共同方法的凭证，不是缓存内容清单。两个都接受补偿的接收端可能处于完全不同状态：一个刚收到完整主头，一个从未收到，一个已经因不一致清空。

因此，SDP 记录必须绑定到具体 RTP 上下文，运行时缓存事件也必须带同一坐标。重新协商、payload type 改变、源替换或会话断裂后，旧缓存不能仅因时间相邻而继承权威。

配置证明能力，运行日志证明动作，输出遥测证明结果。三者不能互相代替。

优先级零仍然可能丢失

RFC 5372 还定义了 priority 字段。包含主头或 tile-part 头的载荷使用优先级零，数值越低，声明的重要性越高。实现必须支持按 JPEG 2000 包序号映射；按 progression、layer、resolution、component 的映射是可选项，并通过 pt 协商。

priority 的零与 mh_id 的零不是同一种语义。前者说“这份头部材料最重要”，后者说“不要缓存与补偿”。把两个零合并成通用标志会同时破坏两套控制。

更重要的是，优先级描述 codestream 内的相对重要性，不提供网络资源预留。头部包可以被正确标为零，却仍然丢失。字段告诉系统该优先保护什么，不是已经得到保护的回执。

若一个 RTP payload 装入多个 JPEG 2000 包，载荷取其中最低数值，也就是最高重要性。这种聚合帮助调度，却不证明其中每项贡献都被解码或呈现。

同一组播中的接收端并不拥有同一证据

RFC 5372 是 RFC 5371 上的可选扩展。只实现基础规范的接收端会安全忽略 mh_id 和 priority。组播环境中，即使某个成员不支持，发送端仍可使用扩展。

于是，同一批网络包可以在不同设备上产生不同语义。扩展接收端维护缓存与映射；基础接收端不赋予这些位相同含义。仅凭发送端抓包，不能宣称整个组都完成补偿或优先级处理。

群体报表必须保留接收端能力、协商上下文和真实动作。兼容性保证共同传输不被破坏，不保证共同观察，更不保证共同画面。

把缺失历史保留为缺失

最稳健的自动化不会猜测盲区内发生了多少变化。它记录最后完整主头、其哈希与序列来源，记录已经观察到的每次编号变化，也记录无法解释的序列缺口。

补偿前，它检查当前会话、源、mhc、非零值、完整缓存、失效标志与回绕历史。补偿后，它关联解码结果、缓存清除与输出。

本地策略可以更严格：缓存超时；长缺口后强制等待完整主头；没有观察到七到一的连续历史时拒绝回绕命中；多次不一致后暂停补偿。这些是风险选择，不应伪装成 RFC 的强制条款。

重要的不是消灭所有不确定性，而是拒绝把不确定性改名为连续性。六次更新已经消失，就让这段历史在记录中保持未知。