摘要

  • 累积确认只能说明连续数据到达了哪里；同一批数据发生多处丢失时，它无法展示缺口之后已经安全抵达的区间。
  • RFC 2018 让接收方报告不连续的已收字节块，但这些信息只是建议性证据，最终释放数据仍以累积确认为准。
  • RFC 3517 与 RFC 6675 把这张地图纳入保守的记分板和在途数据估算，并在确认时钟可能停摆时允许一次受限的救援重传。

设想发送方连续发出八个报文段，第二个在途中丢失，其余都到达。接收方手里已经有第三至第八段，但确认号只能停在第一个缺口之前。不断重复同一确认号能告诉发送方“有问题”，却不能完整说明“哪些数据没有问题”。发送方要么每经过一个往返时间才发现下一个洞，要么提前重传一批可能已经收到的数据。

选择性确认正是对这种信息不足的修补。1996 年 10 月发布的 RFC 2018 并非从零开始；RFC 1072 已提出过一种形式，但由于与窗口扩大选项的配合存在分歧，并未在互联网普遍部署。新版把能力协商与实际报告分开：连接建立时在 SYN 中发送 SACK-Permitted，连接建立后才可用 SACK 选项报告连续字节块的左右边界。

两种确认并存，是这一设计最重要的边界。累积确认作出强承诺：确认号之前的每个字节都已到达。SACK 块只描述缺口之后暂存在接收队列中的“岛屿”，不会推动连续前沿，也不是不可撤销的收据。接收方遇到内存压力时可以丢弃已经报告过的数据，因此发送方在普通确认号越过相应字节之前，不能清除自己的重传副本。

这张地图还必须压缩。TCP 选项空间只有 40 字节，SACK 最多能装四个块；同时使用时间戳时通常只剩三个。RFC 2018 要求首先报告触发当前确认的最新数据块，并建议重复近期块。排序让信息保持新鲜，重复则抵抗回程 ACK 丢失。代价是接收方传递的从来不是完整队列，而是有限空间内最有价值的一组证据。

RFC 2018 规定了信息格式，却刻意没有把它写成完整的发送方策略。它强调必须保留 TCP 拥塞控制。2003 年 4 月的 RFC 3517 随后提供了保守的 SACK 恢复算法。发送方维护一块“记分板”，记录累积确认和选择性确认覆盖的序列区间；根据更高位置已有数据推断缺口；用 Pipe 估计仍在网络中的字节；再在拥塞窗口许可范围内选择下一段数据。

这套分工没有让信息提供者变成控制者。接收方报告自己看见的队列状态，发送方负责解释、保留原始数据并承担误判成本。SACK 可以在一个恢复阶段内修补多处丢失，却不能取消减小窗口、限制发送和容忍乱序的义务。信息变得更细，公共网络的约束没有消失。

2012 年 8 月，RFC 6675 取代 RFC 3517。修订利用新的 SACK 信息来定义重复确认，改进对小于最大发送段的数据的丢失判断，并增加 RescueRxt。当窗口末端发生丢失、又没有新数据可发，确认时钟可能停止；此时算法允许每个恢复阶段进行一次乐观的救援重传。这个例外被严格限定为一个不超过发送方最大报文段的单位。

因此，SACK 的历史并不是“更多信息必然带来更多速度”。它讲的是分布式系统如何划定信任。接收方最清楚自己此刻持有哪些块，却未必会永远保留；发送方掌握重传与拥塞窗口，却只能通过延迟而不完整的报告观察路径；选项空间迫使状态压缩；超时又可能推翻之前积累的判断。

真正持久的改变，是确认从单一前沿扩展成部分地图，但地图仍没有变成命令。标准允许发送方少做无用重传，也要求它继续对速率、缓存和判断负责。TCP 因此获得了更精确的恢复能力，却没有把一次局部优化的代价轻易转嫁给共享路径。

来源