rfcrfc2582.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：mailto:[e-mail]
译者：（）
译文发布时间：2001-11-4
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。




Network Working Group                                            S. Floyd
Request for Comments: 2582                                          ACIRI
Category: Experimental                                         T. Henderson
                                                           U.C. Berkeley
April 1999


TCP快速恢复算法NewReno修正
（RFC2582——The NewReno Modification to TCP's Fast Recovery Algorithm）

本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建
议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化
程度和状态。本备忘录的发布不受任何限制。
版权声明
Copyright (C) The Internet Society (2001).
摘要： 
RFC 2001 [RFC2001]讲述了以下四种相互作用的TCP拥塞控制算法：慢启动，拥塞避免，
快速重传，以及快速恢复。RFC 2581 [RFC2581]明确地允许对这些算法进行某些改动，包括
如下改动，使用TCP选择确认（SACK）选项[MMFR96],以及在没有SACK的情况下响应“部分
确认”(在检测到数据丢失时，新数据的ACKs，而不是发送的所有数据的ACKs)。这篇文档
描述了响应部分确认的一个特定算法，称为NewReno。对部分确认的响应由Janey Hoe在
[Hoe95]中首次提出。


                             目录
1.介绍	2
2.定义	2
3.NewReno中的快速重传和快速恢复算法	2
4.重设重传定时器	4
5.避免多次快速重传	4
6.数据接收端的实现问题	5
8.总结	6
9.致谢	6
10.参考文献	6
11.安全考虑	7
12.作者地址	7
13.完全版权说明	8

1.介绍
对[RFC2581]（在1990年的BSD Reno发行版中首次实现，在[FF96]称之为Reno算法）
中描述的TCP快速恢复算法的典型实现，TCP数据发送端在发生一个超时重传时仅仅重传一
个数据包，或者当三个重复确认到达时触发快速重传算法。单单一个超时重传可能导致许多
数据包的重传，但是每次Reno快速重传算法的启用仅仅导致一个数据包的重传。
因此，当多个数据包从一个数据窗口中丢失并且触发快速重传和快速恢复算法时，问题
就会产生。在这种情况下，如果SACK选项可用，TCP发送端在快速恢复期间就有足够的信
息来决定重传哪个数据包，不重传哪个数据包。这篇文档仅对不能使用TCP选择确认（SACK）
选项的TCP连接适用。
在没有SACK的情况下，TCP发送端在快速恢复期间只能得到很少的信息来作出重传决
定。从三个重复确认中，发送端推断出一个数据包丢失了，并且重传那个声明了数据包。在
这之后，数据发送端可能接收到另外的重复确认，因为在发送端进入快速重传时，数据端确
认已经发送的附加数据包。
在多个数据包从一个数据窗口中丢失这种情况下，当发送端从对重传的数据包（就是第
一次进入快速重传时重传的数据包）的一个确认时，它获得第一条可用新信息。如果只有一
个数据包丢失了，对这个重传的数据包的确认将确认所有进入快速重传（在没有重新排序的
情况下）之前发送的数据包。但是，当有多个数据包丢失时，对此重传数据包的确认将仅确
认一些而不是所有在快速重传之前发送的数据包。我们称这个包是一个部分确认。
和许多其它的建议一起，[Hoe95]建议在快速恢复期间TCP数据发送端通过推断声明的
数据包已经丢失和重传那个数据包的方式响应一个部分确认。这篇文档描述了对Reno TCP
里的快速恢复算法的一个修正，Reno TCP包括了快速恢复期间对接收到的部分确认的一个
响应。我们称这处修正过的快速恢复算法为NewReno，因为它与基础的Reno算法有一些细
小但是很重要的不同。这篇文档没有讨论[Hoe95]和[Hoe96]中的其它建议，比如在慢启动期
间ssthresh参数的一个变化，及在快速恢复期间为每两个重复确认发送一个新数据包的建
议。这篇文档里的NewReno方案也使用了文献[LM97]中的NewReno的讨论。
    我们没有说对于不能使用SACK的TCP，这里描述的快速恢复的NewReno方案是响
应部分确认的一个可选修正。根据我们在NS模拟器上的NewReno修正经验，我们相信这个
修正在很多地方都改善了快速重传和快速恢复的性能，我们仅仅是为了IETF团体的利益而
将它文档化。我们鼓励使用对快速恢复的这一修正，并且我们还鼓励反馈关于此修正或相关
修正的操作经验。
2.定义
这篇文档假设读者熟悉[RFC2581]中定义的术语：最大段尺寸(MSS), 拥塞窗口(cwnd),
和传送尺寸（FlightSize）。传送尺寸在[RFC2581] 中是如下定义的：
传送尺寸：已经发送但还没有确认的数据量。
3.NewReno中的快速重传和快速恢复算法
标准的快速重传和快速恢复算法实现在[RFC2581]给出。这些算法的NewReno修正在下
面给出。NewReno修正[RFC2581]里的实现的不同仅在于步骤1中的变量“recover”的引入，
以及步骤5中对一个部分或新的确认的响应。修正定义了一个“快速恢复过程”，它在接收
到三个重复ACK时开始，并在一个超时重传发生或一个确认所有在快速恢复过程开始后发送
的数据的ACK到达时结束。
1.当收到第三个重复ACK并且发送端还没有处于快速恢复过程时，设置ssthresh不大
于下面等式1中给出的值。（这是[RFC2581]中的等式3）。
ssthresh = max (FlightSize / 2, 2*MSS)           (1)
用变量“recover”记录传送的最大序列号。
2.重传丢失的段并设置cwnd为ssthresh乘以3*MSS。这将人为地按已经离开网络的报
文段数目（3）和接收端缓冲数据量来扩充拥塞窗口。
3.对每个接收到的额外的重复ACK，将cwnd增大SMSS字节。这将人为地扩充拥塞窗口
以反映已经离开网络的附加数据段。
4.发送一个数据段，如果cwnd和接收端的通知窗口的值允许的话。
5.当一个确认新数据的ACK到达时，此ACK可能是由步骤2中的重传引发的确认，或者
是由稍后的一次重传引起的。
  如果这个ACK确认了直到并包含“recover”的数据，那么这个ACK确认了所有在丢
失段的原始传送和第三个重复ACK接收之间的段。设置cwnd为（1）
min(ssthresh,FlightSize+MSS)；或者(2)ssthresh,这里的ssthresh是步骤1中设置的值；
这称为“deflating”窗口。（我们注意到步骤1中“FlightSize”指的是当进入快速恢复时
步骤1中发送的数据量，步骤5中的“FlightSize”指的是当退出快速恢复时发送的数据量。）
如果选择了另一个选项，实现应该采取措施避免可能的数据爆发，万一向网络中发送的数据
量远小于新拥塞窗口允许的量[HTH98]的话。退出快速恢复过程。
如果这个ACK不确认所有并包含到“recover”的数据的话，就产生一个部分ACK。在
此种情况下，重传第一个没有确认的数据段。按确认的新数据量来减小拥塞窗口，然后加回
一个MSS并发送一个新数据段，如果cwnd的新值允许的话。这个“部分窗口缩减”试图确
定这一点，当快速恢复最终结束时，大约ssthresh数量的数据还在向网络中传送。不要退
出快速恢复过程（也就是说，如果任何重复ACK随后到达，执行上面的步骤3和4）。
对在快速恢复期间第一个到达的部分ACK，也要重设重传定时器。
注意到在步骤5中，拥塞窗口在一个部分确认收到时减小。拥塞窗口在部分确认收到时
可能已经大幅膨胀。另外，根据丢失数据包的类型，部分确认可能确认将近一个窗口的数据。
在这种情况下，如果拥塞窗口没有减小，数据端可能能够紧接着发送将近一个窗口的数据。
上面描述的对部分确认的简单响应可能有许多变形。首先，一个问题是部分确认之后何
时重设定时器。这在下面的第4节进一步讨论。
一个相关的问题是在每一个部分确认之后，重传多少数据包。上面描述的算法在每个部
分确认之后重传一个数据包。这是最保守的选择，因为这种办法最没有可能导致一个没有必
要重传的数据包。有效地慢启动也是一个变形，它能从丢失了许多数据包的窗口中更快地恢
复过来，但是要求从丢失了N个数据包 [Hoe96]的恢复必须少于N来回时间。对部分确认采
用这种稍微激烈一点的响应的话，在每个重传之后重设重传定时器就会很有利。因为我们还
没有在我们的模拟器上试验这种变形，我们在这篇文档中不会进一步对此进行讨论。
第三个问题是避免由接收端已经到的数据包的重传引起的多次快速重传。这在下面的第
5节中讨论。避免多次快速重传在对部分确认采用更激烈的响应的情况下特别重要，因为在
这种情况下，发送端更可能重传接收端已经接收的数据包。
最后，我们考察一下没有SACK选项的情况，数据发送端在没有足够信息的情况下工作。
一个发送端可能花很长时间仔细考虑在这种情况哪个快速恢复的变形对这种环境是最优的。
因为从丢失了多个数据包的一个窗口中恢复的问题特别重要，所以最好的选择是使用SACK
选项。
4.重设重传定时器
第3节的算法仅在第一个部分ACK之后重设重传定时器。在这种情况下，如果很多数据
包从一个窗口中丢失了，TCP数据发送端的重传定时器最终将超时，接着TCP数据发送端将
调用慢启动。（这在[F98]在12页中被例证。）我们称此为NewReno的Impatient变形。
相反地，[FF96]中的NewReno模拟例证了上面描述的算法，不同的是重传定时器在每个
部分确认之后都要重设。我们称此为Slow-but-Steady变形。在这种情况下，对于一个丢失
了大量数据包的窗口来说，TCP数据发送端每个来回时间至少发送一个数据包。（这种行为
在[FF96]中的NewReno TCP模拟和[F98]的11页中被例证。）
对于超时重传值（RTO）一般不大于往返时间（RTT）的TCP实现来说，Impatient变形
即使在只有少量数据包丢失的情况下也会导致一个超时重传。对于超时重传值（RTO）一般
远大于往返时间(RTT)的TCP实现来说，Slow-but-Steady变形当多个数据包从一个窗口中
丢失时能够长时间维持快速恢复。这些变形没有一个是最优的；一个更优的算法可能是某个
从多个数据包丢失中迅速恢复，并且在重设重传定时器时与Slow-but-Steady进行混合的算
法。然而我们注意到，在没有SACK选项的情况下，对潜在性能有个限制。
5.避免多次快速重传 
    在没有SACK选项时，一个重复确认没有携带任何有关信息，这种信息是用来确定TCP
数据接收端触发重复确认的一个或多个数据包的。TCP数据发送端不能把区分重复确认是由
数据包丢失或延时引起的，还是由发送端重传了一个TCP接收端已经接收到的数据包引起
的。由于这个原因，一个窗口的多个数据段丢失某些时候能导致不必要的多次重传（以及拥
塞窗口的多次缩减）[Flo94]。
    在Reno或NewReno TCP中使用了快速重传和快速恢复算法的话，由多次快速重传引起
的性能问题就相对小一些（和Tahoe TCP的潜在问题相比，它没有实现快速恢复）。然而，
Reno或NewReno TCP也会发生不必要的快速重传，特别是如果快速恢复期间发生了一个重
传超时的话。（这在［F98］第6页中作为Reno的例证，第8页中作为NewReno的例证。）有
NewReno的话，数据发送端一直处于快速恢复，直到发生一个超时重传，或者快速重传时发
送的所有数据都已得到确认。因此有了NewReno，多次快速重传的问题只有在一个超时重传