摘要

  • RFC 2354 按时延、带宽、计算量、编解码知识和恢复精度区分四类流媒体修复，没有给出一种适用于所有会话的答案。
  • 丢包只能证明出现了缺口，不能授权无限加大发送；修复包会占用同一路径，过量时可能形成“拥塞—丢包—加码修复”的正反馈。

Colin Perkins 与 Orion Hodson 在 1998 年 6 月发布这份 Informational RFC。它不是互联网标准，也不声称穷尽所有方法。讨论范围只包括需要发送端参与的修复；纯接收端掩盖技术不在范围内。

文件先区分“媒体单元”和“网络包”。单元是编解码器产生的一段有时间位置的数据，一个包可以装一个或多个单元。于是“修复成功”至少有四种含义：原始字节被精确重建、较低质量的替代单元可用、一个大缺口被摊成若干小缺口，或者精确副本终于到达却已经错过播放时间。

RTP 提供两种不同证据。序列号表示发送顺序，用来发现缺包；时间戳表示单元应当在何时播放。许多修复方法会让单元乱序传输，因此接收端必须按时间戳排播。序列缺口说明“少了什么”，播放时钟说明“还来不来得及”。

Mbone 的损失形状

RFC 2354 引用了当时 Mbone 的观测：某大型会话中，多数接收端丢包率约为 2% 至 5%，少数更高；单包丢失占绝大多数，连续两包以上的突发少一个数量级，长突发更少。这是特定历史环境的证据，不能外推成今天所有网络的固定分布。

但它给出了设计顺序：先高效处理最常见的单包缺失，再衡量短突发值不值得额外成本。为罕见长突发永久配置大量冗余，会让保护本身成为日常负担。

四种修复，各自付账

重传在发现丢失后行动。接收端发请求，发送端再发一遍。它可以精确恢复，却要等待反馈往返，并增加双向控制与数据负载。大型多播中，几乎每个包都可能被至少一个接收端漏掉；如果请求不做抑制，一个局部缺口会变成全组成本。

RFC 因而把重传主要放在能够容忍时延的场景，并提出组合：FEC 处理常见单包丢失，遭遇突发且愿意等待的接收端再请求额外修复。不同接收端不必购买相同的延迟。

媒体无关 FEC 在丢失前缴费。发送端附加奇偶校验或编码数据，接收端不再询问源端也能重建原包。简单 XOR 计算较轻；更强的编码能覆盖突发，却增加计算和时延。即使路径没有丢包，保险流量也一直占用容量。

媒体相关冗余利用编解码器知识。较低码率的副本可能用更少带宽保住一段语音；视频格式可以重复关键结构；也可以只保护最敏感的位。代价是“修复”不再必然等于原样恢复，而是用可接受近似换效率。

交织不发副本，而是改变单元装包顺序。原本相邻的时刻被放进不同包，一个包丢失后会留下多个短缺口，而不是一个长中断。它不增加带宽，却需要缓存并推迟播放。对延迟宽松的单向节目有利，对交互谈话不利。

播放期限才是裁判

广播式、非交互传输可以拿时延换接收质量，因此重传、FEC 和交织都可能合理。交互会话不能承受长往返或深交织，只剩低时延 FEC 较适用；但究竟选择通用 FEC 还是编解码器专用冗余，仍取决于格式、计算与允许的近似程度。

真正危险的不是某一算法，而是反馈方向。若丢失来自拥塞，看到丢包后大幅增加修复数据，会加重队列、制造更多丢失，再触发更多修复。RFC 2354 在安全部分明确指出，极端情况下这会成为拒绝服务。

当时尚无通用的流媒体拥塞控制方案。文件借助近似的 TCP 等价吞吐关系给“合理”行为划上界，同时坦承：平均公式没有捕捉 TCP 的动态，多播组的往返时间也只是粗略平均值。这个数字是节制工具，不是容量真相。

后来的 RFC 4588 与 RFC 5109 分别规范 RTP 重传和通用 FEC；RFC 8085 则要求 UDP 应用控制聚合流量，并在拥塞信号出现时降低速率。它们证明不同修复面各有协议责任，而不是把所有方法并成一个“可靠”开关。

RFC 2354 留下的是一套分账：序列缺口、修复发送、解码重建、期限前到达和用户体验必须分别记录。只有这样，系统才知道自己是在修复媒体，还是只是在发送更多东西。