【RFC2018 TCP选择确认选项】（翻译）

原文 https://datatracker.ietf.org/doc/html/rfc2018 TCP Selective Acknowledgement Options TCP选择确认选项

概述

当多个数据包从一个数据窗口丢失时，TCP 的性能可能会很差。由于累积确认提供的信息有限，TCP 发送方在每个往返时间内只能了解一个丢失的数据包。激进的发送方可以选择提前重新传输数据包，但可能已经成功接收到此类重新传输的数据段。

选择性确认 (SACK) 机制与选择性重复重传策略相结合，可以帮助克服这些限制。接收方 TCP 将 SACK 数据包发送回发送方，通知发送方已收到数据。然后发送方可以仅重传丢失的数据段。

本文提出了 SACK 的实现并讨论了其性能和相关问题。

1. 简介

一个数据窗口中的多个数据包丢失会对 TCP 吞吐量产生灾难性影响。 TCP [Postel81] 使用累积确认方案，其中不确认不在接收窗口左边缘的接收段。这迫使发送方要么等待一个往返时间以找出每个丢失的数据包，要么不必要地重新传输已正确接收的数据段 [Fall95]。对于累积确认方案，多个丢弃的段通常会导致 TCP 丢失其基于 ACK 的时钟，从而降低整体吞吐量。

Selective Acknowledgment (SACK) 是一种策略，可以在面对多个丢弃的段时纠正这种行为。通过选择性确认，数据接收方可以通知发送方所有已成功到达的段，因此发送方只需要重传实际丢失的段。

包括 NETBLT [Clark87]、XTP [Strayer92]、RDP [Velten84]、NADIR [Huitema81] 和 VMTP [Cheriton88] 在内的几种传输协议都使用了选择性确认。有一些经验证据支持选择性确认——简单的 RDP 实验表明，禁用选择性确认工具会大大增加在有损、高延迟 Internet 路径上重传的段数 [Partridge87]。最近由 Kevin Fall 和 Sally Floyd [Fall95] 进行的一项模拟研究证明了 TCP 与 SACK 相比非 SACK Tahoe 和 Reno TCP 实现的优势。

RFC1072 [VJ88] 描述了 TCP 的 SACK 选项的一种可能实现。不幸的是，它从未在 Internet 中部署过，因为对于 SACK 选项应如何与 TCP 窗口移位选项（最初描述为 RFC1072 并在 [Jacobson92] 中修订）结合使用存在分歧。

我们建议对 RFC1072 中提出的 SACK 选项进行轻微修改。具体来说，为最近收到的数据发送选择性确认减少了对长 SACK 选项的需要 [Keshav94, Mathis95]。此外，SACK 选项现在带有完整的 32 位序列号。这两个修改代表了对 RFC1072 中提案的唯一更改。它们使 SACK 更容易实现并解决关于健壮性的问题。

选择性确认扩展使用两个 TCP 选项。第一个是启用选项，“SACK-permitted”，它可以在 SYN 段中发送，以指示一旦建立连接就可以使用 SACK 选项。另一个是 SACK 选项本身，一旦