摘要

  • RFC 3366把链路层ARQ的重试持久性视为一笔时间预算：链路在放弃前愿意花多少时间恢复一帧，而不是免费获得更多可靠性。
  • 重传可能帮助一条流，却给其他流带来累积时延、抖动或队头阻塞；帧级确认并不能证明应用按时收到数据。

一帧并不等于一个完整数据包

故事从IP之下开始。自动重传请求（Automatic Repeat reQuest，ARQ）发现链路帧缺失或损坏后，会再传一次。根据链路设计，一帧可能装着一个IP数据包的片段、完整数据包，或多个数据包的部分内容。链路层确认只回答一个范围很窄的问题：按本链路协议的规则，接收端是否接受了这帧？它不证明端到端数据包已经抵达，更不证明应用仍来得及使用。

RFC 3366以最佳当前实践BCP 62的身份发布，提醒链路设计者认真对待这道边界。它没有规定某一种无线协议，也没有要求所有设备采用同一个重试次数。它讨论的是链路本地修复机制如何影响其上承载的互联网流量。

重试预算花掉的是共享时间

文件把愿意继续重试称作“持久性”。链路可以规定固定的尝试次数，也可以让计时器和链路故障判定来决定何时停止。次数不是时钟：传播时延、共享介质退避、排队、帧长和处理过程都会改变实际耗时。

因此，可靠性是有条件的。本地链路的控制环路通常比TCP端到端环路反应更快，能在发送端重传之前修复信道错误。但修复成功的帧也可能晚到，足以影响传输层定时器。如果链路要维持帧或包的顺序，后面已经完整接收的数据包可能会被仍在重试的帧挡住。在共享信道上，这些额外尝试还会占用其他节点可用的空中时间。

“完全持久”让这种取舍很直观：只要接收端仍可能接受，就继续重传，甚至不设有限次数。这或许适合目标就是可靠传送的数据流。但在一条由多段链路组成的IP路径上，各段反复修复可能重复端到端传输本就负责的工作；它仍不能提供与端点传输层相同的端到端可靠性。对流媒体等重视时效的UDP应用来说，太晚抵达的数据包可能还不如丢失的数据包有用。

链路可以知道什么，不该猜什么

设计者可能想把更长的重试预算给“看起来需要可靠性”的流，把更短预算给其他流。RFC 3366解释了为什么仅凭观察并不够。链路或许看得出某条流有拥塞控制，却不知道应用的截止时间，也不知道它更重视完整性还是新鲜度。端口号可能误导，也可能被地址转换重映射；隧道会把不同流合在一起；加密载荷会限制检查；服务标记可能被覆盖，或只在本地才有特定含义。

所以建议是有条件的。若设计者能可靠地区分服务类别，不同的重试行为可能有益；若不能，所有流就要继承同一种链路行为。在无法安全分类时，BCP通常倾向较低的持久性：尽力恢复一些帧，但不要让一个尚未完成的数据包无限期占住后面的队列。文件同时保留了另一面：在某些信道错误变化剧烈、或瞬时中断恢复之后，较高持久性可能有利于TCP。不存在适用于所有情况的单一最佳值。

2004年发布的RFC 3819是范围更广的子网设计建议，它把权衡扩展为丢包、平均时延和时延变化三者之间的关系。它进一步支持灵活选择，却没有把RFC 3366中的“两到五次”示例变成今天的统一规则，也没有提供网络采用率的测量。

确认仍是一张本地收据

RFC 3366留下的教训也关乎证据。一条帧确认记录的是本地事件。数据包离开链路、传输层接受数据、应用及时收到数据，是后续不同事件，各自需要不同证据。重传可能降低信道错误造成的丢包，却也可能加大抖动、延迟拥塞反馈，或花掉其他流急需的时间。

链路设计者设定本地预算，整条路径累积其后果。不知道路径其余部分，也不知道应用的新鲜度要求，设备就无法把“更多尝试”直接许诺为“更好服务”。BCP 62要求把这种不确定性写进设计，而不是用一个“可靠”标签把它藏起来。

来源

Lu Heng并非RFC 3366的作者。这里明确把两篇文章作为分析视角，用于区分建议、运行中的实现、实际配置与可观察结果。