摘要

  • RFC 5401 让接收者在随机退避期间监听他人的修复请求，以减少大量成员同时发送 NACK 造成的反馈内爆。
  • 延长退避可以降低反馈密度，却会增加发现缺口到启动修复的时间，并要求发送端和接收端保留更久的状态。
  • “没有新 NACK”只描述反馈通道，不能代替成员范围、修复接收、本地重建与应用接受的分层凭据。

安静是被设计出来的

RFC 5401 于 2008 年 11 月以标准轨文档发布，取代实验性的 RFC 3941。它处理的不是如何让每个接收者都不断报告成功，而是如何让大规模组播中的失败反馈保持可控：正常收到数据的成员不说话，检测到缺失的成员才启动 NACK 周期。

如果所有丢失同一数据块的成员立即发出请求，负向确认同样会形成反馈内爆。因此，接收者选择随机退避时间。在等待期间，它可能听到更早的 NACK；只要该请求覆盖自己的修复需求，就可以抑制本地消息。发送端转发的修复状态、或者发送位置回退所显示的修复行为，也可能触发抑制。

这套设计主动制造沉默。沉默越多，控制流量越少；但沉默并不自动表示数据完整。一个成员可能已经完成，也可能只是被另一个成员的请求代表，仍在等修复；还可能刚加入、已经断开、回程不可达，或者其 NACK 在途中丢失。

因此，反馈曲线变平只能说明系统减少了发言，不能说明所有人都得到了结果。把它直接命名为“交付完成”，等于把扩展性机制误写成业务凭据。

更长的窗口压低峰值，也推迟行动

随机退避为早到的代表性 NACK 留出时间。窗口越长，后续成员听到已有请求并抑制自己的概率越大。在成员数量庞大时，这可以显著降低同时反馈的压力。

代价出现在另一端。接收者必须等到退避结束，才能确认自己的需求仍未被覆盖并发送请求。发送端需要保留可供修复的数据，接收端需要保留接收历史与编码块状态。窗口放大后，首次缺失与实际修复之间的尾部延迟会扩大，缓冲区的生命周期也更长。

RFC 5401 使用组规模估计和组内最大往返时间等信息调节计时。这里的关键词是“估计”。它们帮助系统选择窗口，却不证明每个成员都已知、最远成员仍在线，或者最弱成员能够回传。成员可能在测量后加入，远端链路也可能在会话中变化。

管理界面如果只显示平均恢复时间，就可能把边缘队列隐藏在漂亮的中位数后。更可靠的观察应同时显示退避分布、估计值年龄、抑制比例、修复轮次、对象剩余寿命以及不同接收群组的完成情况。

抑制只回答“还需要重复提问吗”

接收者发现缺口时，要保存足够的已收内容历史，并记录启动 NACK 周期时的发送位置。退避期间到达的新数据不应让系统忘记周期为什么开始。计时结束时，它再判断尚未满足的修复需求。

若另一个成员已经提出覆盖面足够的请求，本地 NACK 可以取消。这个动作回答的是“现在再提一次是否冗余”，而不是“我是否已经修好”。两者之间还隔着发送端聚合、修复包发出、网络传输、本地接收、对象重建和应用验证。

任何一段都可能失败。代表性 NACK 可以到达，而修复包没有到达某个成员；修复包可以到达，但符号数量不够；对象可以重建，却没通过校验；内容可以通过校验，却没有被应用加载。把“已抑制”涂成绿色，会让这些失败在最需要解释时失去出处。

同样，NACK 自身不必在每种设计中获得绝对可靠传输，只要后续周期能够继续收敛。一个请求丢失后，接收者可以保留历史并再次发起。这说明协议依赖时间序列，而非某一个静默窗口。单轮无反馈绝不是全组确认。

FEC 降低个性化修复，不统一接收结果

前向纠错允许一个修复符号帮助丢失了不同源包的多个接收者。RFC 5052 给出内容交付中的 FEC 框架。对组播而言，它可以把许多不同的缺口压缩成共享修复，而不必逐一重传原始包。

但每个成员的起点仍不相同。甲可能只差一个符号，乙可能缺失多个，丙可能在编码块开始后才加入。发送同一批冗余符号，不等于所有成员同时获得了可重建对象。

接收者在发出 NACK 前，还应把已经计划的修复考虑在内。这能避免过度请求，却又产生一个容易误读的状态：需求仍然存在，但反馈被暂缓，因为修复“预计会来”。预计并非收到，发出也并非重建。

FEC 本身也不提供完整的拥塞控制。RFC 5052 与 RFC 5651 都把兼容的拥塞控制放在完整协议实例中。为了缩短尾部而猛烈增加修复，可能进一步伤害本已拥塞的路径。编码效率、网络公平与应用完成必须分别证明。

多轮收敛需要保留时间轴

一次修复可能不足以填补所有缺失。接收者可以在新数据到达后重新计算需求，再进入下一轮。这个循环使系统在不保证每条反馈都可靠的情况下仍有机会收敛。

运营记录应给每轮分配可关联的标识：对象、编码块、启动边界、退避值、听到的代表请求、本地 NACK 是否发送、发送端采用的修复以及轮后剩余需求。只有这样，事故复盘才能区分“请求没发出”“请求被抑制”“请求丢失”“修复丢失”和“修复不足”。

如果日志只留下最后的“无待处理修复”，之前未完成的成员就会从中心视野消失。发送端队列为空，可能因为全部问题解决，也可能因为反馈窗口关闭、成员离线或对象过期。队列状态是系统内部事实，不是接收结果。

RFC 5740 所定义的 NORM 展示了相关构件如何组成具体协议。即便传输协议认为对象状态结束，也不能直接推断软件已经安装、配置已经启用或业务动作已经完成。应用层必须提供自己的接受凭据。

成员变化会改变分母

接收者可以晚加入、离开并重新进入。晚加入者缺少先前发送内容；早期成员可能在重建前消失。当前能听到的成员集合，既不一定等于最初承诺的对象，也不一定等于最终报告应覆盖的对象。

有些应用达到一个阈值即可行动；另一些应用必须跟随最弱成员。长期表现不佳的接收者可以按策略被排除，或迁移到另一个交付组。RFC 5401 把这些完成规则留给具体协议与应用。

这意味着“全部”首先是治理定义。哪些成员计入？在哪个时间点冻结范围？晚加入者是否有权获得完整对象？离线多久后可以转入例外？迁移到慢速组算延期、失败还是完成？谁能批准排除？

如果没有事先定义，完成率可以通过缩小分母得到改善。网络可能完全按照配置运行，而报告却把未服务成员悄悄移除。应当分别保存预期成员、当前可达成员和完成政策纳入的成员，并记录每一次排除或迁移。

保留优势，而不是强迫所有人回执

纠正误报不等于要求所有场景都改成逐成员正向确认。那会损失 NACK 组播的规模优势。正确做法是按风险选择凭据强度。

普通内容分发可以使用群组统计、关键成员抽样、明确阈值与例外队列。安全更新、兼容性切换或不可逆操作，则可能要求指定成员返回重建或应用接受凭据。在两种模式下，界面都必须诚实显示自己拥有的是哪一级证据。

完整的凭据链从预期成员和交付内容标识开始，经过发送位置、接收历史、缺失检测、NACK 周期、抑制或发送、修复发出与收到、本地重建，最后到应用接受和组级策略判断。并非每次都要收集所有成员的每一步，但任何省略都应是明示的风险选择。

现有标准来源没有给出当前部署份额、厂商实现差异、事故发生频率或唯一最佳计时参数。评估具体系统时仍需查阅实现文档、配置和实测数据。不过，这些来源足以否定一个常见捷径：不能只凭发送端安静，就宣布全组完成。