1. 简介

1. 简介 (Introduction)

TCP协议被设计为能够在几乎任何传输介质上可靠地运行，无论传输速率、延迟、损坏、重复或段的重新排序如何。当前的生产TCP实现能够适应100 bps到10**7 bps的传输速率，以及1 ms到100秒的往返延迟。最近关于TCP性能的工作表明，TCP可以在各种互联网路径上良好工作，从800 Mbit/sec I/O通道到300 bit/sec拨号调制解调器。

光纤的引入正在导致越来越高的传输速度，最快的路径正在超出TCP最初设计的范围。本备忘录定义了一组适度的TCP扩展，以扩展其应用领域以匹配这种不断增长的网络能力。它基于RFC-1072和RFC-1185并废弃了它们。

"TCP能跑多快？"这个问题没有一句话的答案。存在两种独立的问题类型，性能和可靠性，每种都取决于不同的参数。我们依次讨论每一种。

1.1 TCP性能 (TCP Performance)

TCP性能不取决于传输速率本身，而是取决于传输速率与往返延迟的乘积。这个"带宽延迟积"测量了填满"管道"所需的数据量；它是发送方和接收方在TCP连接上获得最大吞吐量所需的缓冲区空间，即TCP必须处理的未确认数据量以保持管道满载。当带宽延迟积很大时，TCP就会出现性能问题。我们将在该区域运行的互联网路径称为"长肥管道" (long, fat pipe)，将包含此路径的网络称为"LFN"（发音为"elephan(t)"）。

高容量分组卫星信道（例如，DARPA的宽带网）是LFN。例如，DS1速度的卫星信道具有106位或更多的带宽*延迟积；这对应于100个1200字节的未完成TCP段。陆地光纤路径也将属于LFN类；例如，在DS3带宽（45Mbps）下30 ms的跨国延迟也超过106位。

当前TCP在LFN路径上存在三个基本性能问题：

(1) 窗口大小限制 (Window Size Limit)

TCP头使用16位字段向发送方报告接收窗口大小。因此，可以使用的最大窗口是2**16 = 65K字节。

为了解决这个问题，本备忘录的第2节定义了一个新的TCP选项"窗口缩放" (Window Scale)，以允许大于2**16的窗口。此选项定义了一个隐式缩放因子，用于将TCP头中找到的窗口大小值相乘以获得真实的窗口大小。

(2) 损失恢复 (Recovery from Losses)

LFN中的数据包丢失可能对吞吐量产生灾难性影响。直到最近，正确运行的TCP实现会导致数据管道在每次数据包丢失时耗尽，并需要慢启动动作来恢复。最近，引入了快速重传 (Fast Retransmit) 和快速恢复 (Fast Recovery) 算法。它们的组合效果是从每个窗口的一个数据包丢失中恢复，而不耗尽管道。但是，每个窗口超过一个数据包丢失通常会导致重传超时以及由此导致的管道耗尽和慢启动。

扩展窗口大小以匹配LFN的容量会导致每个窗口丢失多个数据包的概率相应增加。这可能对LFN上的TCP吞吐量产生毁灭性影响。此外，如果在网关中引入了基于某种形式的随机丢弃的拥塞控制机制，则随机间隔的数据包丢失将变得普遍，可能增加每个窗口丢失多个数据包的概率。

要将快速重传/快速恢复机制推广以处理每个窗口丢失的多个数据包，需要选择性确认 (selective acknowledgments)。与TCP的正常累积确认不同，选择性确认为发送方提供了在接收方排队的段和尚未到达的段的完整图像。已经发表了一些支持选择性确认的证据，并且选择性确认已包含在许多实验性互联网协议中——VMTP、NETBLT和RDP，并为OSI TP4提出。但是，在非LFN环境中，选择性确认减少了重传的数据包数量，但不会改善性能，使其复杂性的价值受到质疑。但是，在LFN环境中，选择性确认预计将变得更加重要。

RFC-1072定义了一个新的TCP"SACK"选项来发送选择性确认。但是，关于SACK选项的格式和语义，还有重要的技术问题需要解决。因此，SACK已从此扩展包中省略。希望SACK可以在标准化过程中"赶上"。

(3) 往返测量 (Round-Trip Measurement)

TCP通过重传在某个重传超时 (RTO) 间隔内未被确认的段来实现可靠的数据传递。准确动态确定适当的RTO对TCP性能至关重要。RTO通过估计测量的往返时间 (RTT) 的平均值和方差来确定，即发送段和接收其确认之间的时间间隔。

第4节引入了一个新的TCP选项"时间戳" (Timestamps)，然后定义了一个使用此选项的机制，该机制允许几乎每个段（包括重传）以可忽略的计算成本进行计时。我们使用助记符RTTM (往返时间测量，Round Trip Time Measurement) 来表示此机制，以将其与时间戳选项的其他用途区分开来。

1.2 TCP可靠性 (TCP Reliability)

现在我们从性能转向可靠性。高传输速率通过带宽*延迟积进入TCP性能。但是，仅高传输速率就可能通过违反TCP用于重复检测和排序的机制背后的假设来威胁TCP可靠性。

TCP序列号意外重用可能导致特别严重的错误。假设"旧的重复段"（例如，在互联网队列中延迟的重复数据段）在错误的时刻传递给接收方，以至于其序列号落在当前窗口内的某个位置。将不会有校验和失败来警告错误，结果可能是数据的未检测到的损坏。在发送方接收旧的重复ACK段可能只是稍微不那么严重：它很可能锁定连接，使得无法进一步进展，迫使连接上的RST。

TCP可靠性取决于段生命周期的界限的存在："最大段生命周期"或MSL。任何可靠的传输协议通常都需要MSL，因为每个序列号字段都必须是有限的，因此任何序列号最终都可能被重用。在互联网协议套件中，MSL界限由IP层机制"生存时间"或TTL字段强制执行。

序列号的重复可能以以下两种方式之一发生：

(1) 当前连接上的序列号回绕 (Sequence number wrap-around)

TCP序列号包含32位。在足够高的传输速率下，可以在段在队列中延迟的时间内"回绕"（循环）32位序列空间。

(2) 连接的早期实例 (Earlier incarnation of the connection)

假设连接通过适当的关闭序列或由于主机崩溃而终止，并且立即重新打开相同的连接（即使用相同的套接字对）。来自已终止连接的延迟段可能落在新实例的当前窗口内，并被接受为有效。

来自早期实例的重复（情况2）通过强制执行TCP规范的当前固定MSL来避免，如第5.3节和附录B所述。但是，情况(1)，即避免在同一连接内重用序列号，需要一个取决于传输速率的MSL界限，并且在足够高的速率下，需要一个新的机制。

更具体地说，如果TCP能够在特定路径上以最大有效带宽B字节/秒传输，则必须满足以下约束才能进行无错误操作：

2**31 / B  > MSL (秒)                     [1]

下表显示了一些重要带宽B值的Twrap = 2**31/B（以秒为单位）的值：

网络	B*8 bits/sec	B bytes/sec	Twrap秒
ARPANET	56kbps	7KBps	3*10**5 (~3.6天)
DS1	1.5Mbps	190KBps	10**4 (~3小时)
Ethernet	10Mbps	1.25MBps	1700 (~30分钟)
DS3	45Mbps	5.6MBps	380
FDDI	100Mbps	12.5MBps	170
Gigabit	1Gbps	125MBps	17

显然，对于56kbps分组交换甚至10Mbps以太网，序列空间的回绕不是问题。另一方面，在DS3和FDDI速度下，Twrap与TCP规范假设的2分钟MSL相当。向千兆位速度移动时，Twrap变得太小，无法通过互联网TTL机制可靠地强制执行。

TCP的16位窗口字段将有效带宽B限制为2**16/RTT，其中RTT是以秒为单位的往返时间。如果RTT足够大，这会将B限制为满足大MSL值的约束[1]的值。例如，考虑一个RTT为60ms的跨大陆主干（由物理定律设定）。由于TCP窗口大小限制，带宽*延迟积限制为64KB，因此B被限制为1.1MBps，无论路径的理论传输速率多高。这对应于Twrap= 2000秒循环序列号空间，这在今天的互联网中是安全的。

重要的是要理解，罪魁祸首不是更大的窗口，而是高带宽。例如，考虑一个（非常大的）直径为10km的FDDI LAN。使用光速，我们可以计算跨环的RTT为(210**4)/(310**8) = 67微秒，延迟*带宽积为833字节。跨此LAN的TCP连接仅使用833字节的窗口将以全100mbps运行，并且可以在约3分钟内回绕序列空间，非常接近TCP的MSL。因此，即使没有扩展窗口，仅高速就可能导致序列号回绕的可靠性问题。

Watson的Delta-T协议包括用于精确执行MSL的网络层机制。相比之下，用于MSL执行的IP机制在互联网中定义松散，甚至更松散地实现。因此，依赖主动执行TCP连接的MSL是不明智的，并且想象设置比当前值更小的MSL（例如，TCP指定的120秒）是不现实的。

解决序列空间循环问题的一个可能的解决方案是增加TCP序列号字段的大小。例如，序列号字段（以及确认字段）可以扩展到64位。这可以通过更改TCP头或通过附加选项来完成。

第5节提出了一个不同的机制，我们称之为PAWS (防止序列号回绕，Protect Against Wrapped Sequence numbers)，以将TCP可靠性扩展到远超网络带宽可预见上限的传输速率。PAWS使用第4节中定义的TCP时间戳选项来防止来自同一连接的旧重复。

1.3 使用TCP选项 (Using TCP Options)

本备忘录中定义的扩展都使用新的TCP选项。我们必须解决关于使用TCP选项的两个可能问题：(1) 兼容性和 (2) 开销。

我们必须特别注意兼容性，即与现有实现的互操作。之前定义的唯一TCP选项MSS只能出现在SYN段上。每个实现都应该（我们期望大多数会）忽略SYN段上的未知选项。但是，一些有错误的TCP实现可能会被首次出现在非SYN段上的选项崩溃。因此，对于下面定义的每个扩展，仅当SYN段上的选项交换表明双方都理解该扩展时，才会在非SYN段上发送TCP选项。此外，仅当在初始<SYN>段中接收到相应的选项时，才会在<SYN,ACK>段中发送扩展选项。

可能会对TCP选项的带宽和处理开销提出疑问。出现在SYN段上的那些选项不太可能引起性能问题。打开TCP连接需要执行重要的特殊情况代码，处理选项不太可能显著增加该成本。

另一方面，时间戳选项可能出现在任何数据或ACK段中，在20字节的TCP头上增加12字节。我们认为，通过减少不必要的重传而节省的带宽将超过额外头带宽的成本。

还存在关于解析选项的可变字节对齐格式的处理开销问题，特别是对于RISC架构CPU。为了解决这个问题，附录A包含了TCP头中选项的推荐布局，以实现合理的数据字段对齐。本着头部预测的精神，TCP可以快速测试这种布局，如果验证，则使用快速路径。使用此规范布局的主机将有效地将选项用作附加到TCP头的一组固定格式字段。但是，为了保留TCP选项的哲学和协议框架，TCP必须准备好解析任意选项字段，尽管效率较低。

最后，我们观察到本备忘录中定义的大多数机制对于LFN和/或非常高速的网络都很重要。对于低速网络，不使用这些机制可能是性能优化。关心在低速路径上获得最佳性能的TCP供应商可能会考虑为低速路径关闭这些扩展，或者允许用户或安装管理器禁用它们。