摘要

  • TCP 的累计确认只能推进到连续数据的末尾；选择确认 SACK 让接收方另外报告缺口之后已收到的数据块。
  • RFC 2018 允许接收方丢弃先前通过 SACK 报告的数据。发送方必须保留原件，直到累计确认覆盖那些字节。

档案员收到第一、第二和第四页。印章只能盖到第二页，第三页还在路上；他可以在便笺上写“第四页到了”。麻烦是桌面并非永久档案库。桌子堆满时，第四页也许会被清走。TCP 的累计确认像那枚印章，选择确认像便笺。二者不能混着用。

1988 年的 RFC 1072讨论了长时延、高带宽链路上的困境。一个分段丢失，累计确认就停住；后续分段即使已经抵达，发送方也难以从那个停住的数字看出来。它可能一轮轮等待，也可能把接收方已经拿到的内容再发一次。选择性报告被提出，就是要让缺口后面的“孤岛”露面。这份文件提出的是试验方案，后来的 SACK 线缆格式另有定稿。

1996 年 10 月的 RFC 2018给 SACK 定了 TCP 选项格式。连接开始时，对端须在 SYN 中宣告 SACK-Permitted，接收方才能发送 SACK 选项。TCP 头部原有的确认号继续表示连续前缀；SACK 块另列高于该边界、已经收到的字节范围。同一封回信里，正式印章和散页清单各占一栏。

清单装不下所有内容。TCP 选项空间有限，接收缓存里若有许多不相连的区间，ACK 未必能把它们逐一列出。RFC 2018 要求首个 SACK 块通常指向刚触发这次 ACK 的分段所在区间，除非那个分段推动了累计确认；其余位置尽量列不同区间，并可重复近期报告过的块。某封 ACK 丢在路上，下一封重复的清单还有机会补上消息。发送方看到的因此是一张有限、会更新的快照。

第八节把“收据”的想象彻底戳破。接收方可以因为缓存压力，丢弃先前已用 SACK 报告的乱序数据；规范把这叫 reneging。后续选项不能继续把已扔掉的旧区间当作仍在手里。首块还有一条例外：刚到的分段即使注定被丢弃，触发 ACK 的事实仍要在首块体现。选择确认记录一次到达与当时的队列状态，并不替接收方签下无限期保管合同。

发送方的责任倒是写得很硬：累计确认尚未覆盖的字节，不得从自身缓存中删除。它可以参考 SACK 决定先补哪个洞，暂时绕开那些看来已在对面桌上的页；它不能因此销毁最后一份可重发的原稿。远端若清空乱序缓存，补缺页时还得靠发送方把整段重新送去。

2000 年 7 月的 RFC 2883又给同一个选项添了 D-SACK：接收方可以报告重复到达的数据。累计确认号的含义和发送 ACK 的时机都没有随之改变。某次重复到达可能只在一封 ACK 中露面，那封信丢了，线索也跟着丢。这项扩展让报告更丰富，同时提醒人们报告本身也是会丢的包。

SACK 让修补断裂的数据流不再靠猜。它留下的历史教训更像一条朴素的档案室规矩：便笺可以指导下一次投递，销毁原件要等正式印章跟上。网络协议里，这一道手续救的是整份文件。