rfc896.txt

中文RFC文档

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



Network Working Group                                                John Nagle
Request For Comments:  896                                       6 January 1984
                                  Ford Aerospace and Communications Corporation


 
                         TCP/IP互联网上的拥塞控制
（RFC896——Congestion Control in IP/TCP Internetworks）


    这个文档讨论了TCP/IP互联网上拥塞控制的某些方面的问题。它旨在激发
人们对这个问题的思考和进一步的讨论。为了实现改良的拥塞控制而提出某些具
体建议时,这个文档并不具体制定任何标准。
                                  引  言
    拥塞控制在复杂的网络中公认的问题。我们发现，国防部的网间网协议（IP），
一种纯数据报协议，和传输控制协议（TCP），一种传输层协议，当把它们一起使
用时容易遭受不寻常的拥塞问题，这是由在传输层和数据报层之间的相互作用而
引起的。特别的，IP网关对于被我们称为“拥塞崩溃”的现象而言是脆弱的，
特别是当这种网关连到大范围的不同带宽的网络上的时候。我们研究了防止拥塞
崩溃的方案。

    由于这些协议在基于ARPANET IMP技术的网络上使用频繁，这些问题没有得
到普遍的认识。基于ARPANET IMP的网络通常有一致的带宽和完全相同的交换节
点，并且容量很大。对大多数TCP/IP主机和网络而言, 盈余的容量以及IMP系
统控制主机传输量的能力已足以处理拥塞。然而,随着最近ARPANET分成两个互
连的网络以及连到ARPANET上的具有不同特性的其他网络的增长,IMP系统良性
特性中的可靠性已不足以允许主机迅速而可靠的通信。为了使网络成功的运转,
必须改善拥塞控制。

    福特航空航天及通信股份有限公司,和它的总公司,福特汽车公司,经营着如
今实际存在的唯一一家私有的TCP/IP长距离网络。这个网络与四个网点相连(一
个在Michigan,两个在Galifornia,另一个在England),它们中的一些还有大规
模的本地网。这个网络交叉连接在ARPANET上但却使用它自己的长距离线路。福
特公司各网点之间通过私人租赁线路进行传输，包括一条专用的横渡大西洋的卫
星通讯线路。所有的交换节点都是没有点到点流量控制的纯IP报交换，并且所
有主机运行的软件都是由福特公司或它的子公司编写或者经他们大量修改的软
件。这个网络上的链接带宽变化很大，从1200到10，000，000bps。通常，我
们已经没有能力购买昂贵的ARPANET那样的额外的长距离带宽，而且我们的长距
离链接在高峰时期是超负荷的。几秒的传输时间在我们的网络里是如此的平常。
由于我们的纯数据报定向,负荷过重和带宽的大范围变化，我们不得不去解决
ARPANET/MILNET组织才刚开始认识到的问题。我们的网络对主机的TCP实现的
次最优性能很敏感，包括与我们的网络连接或断开。我们力图检查在不同条件下
的TCP性能，并且已经解决了一些TCP普遍存在的问题。在这里我们提出了两个
问题及其解决办法。许多TCP实现有这些问题；如果对于某个给定的TCP实现，
经过ARPANET/MILNET网关的吞吐量比经过一个单一的网络糟，那么很可能这个
TCP实现存在这些问题中的一个或两个。

拥塞崩溃

    在我们开始讨论这两个具体问题及其解决办法之前，描述一下当这些问题没
有解决时会发生什么是妥当的。在负载较重的带有端到端重发机制的纯数据报网
络中，当交换节点拥塞时，网络上的往返时间增加，在网络上传输的数据报的数
量也增加了。这在轻负载下是正常的.只要在传输中仅有每个数据报的一个拷贝，
拥塞就在控制之中。一旦还没递送成功的数据报开始重传，潜在的严重问题就可
能会出现。

    主机TCP的实现预期在增加的时间间隔内多次重传数据报，直到重传间隔
的某个时间上限已到。通常，这个机制足以防止严重的拥塞问题。虽然有更好的
自适应主机重传算法，但是网络上的意外负载能使往返时间的增长速度比发送方
估计的往返时间的更新更快。当一个新的大量数据传输时，这样的负载就产生了，
这样的文件传输开始填充一个大的窗口。如果这个往返时间超过了所有主机的最
大重传间隔，那么主机将开始向网络产生越来越多的同一数据报的副本。这时,
这个网络有了严重问题。最终在交换节点中所有可获得的缓冲将饱和，于是必须
丢失数据报。这时,被传送的这个数据报的往返时间到达它的最大值。主机多次
发送每个报文，最终每个报文的某个拷贝到达它的目的地。这就是拥塞崩溃。

    这个状态是稳定的。一旦到达饱和点，如果选择包丢弃算法良好，网络将继
续运行在性能降低了的状态下。在这种状态下，每个包被传输几次，吞吐量将降
低到正常情况的几分之一。我们实验性地迫使我们的网络处于这样的状态并且观
察它的稳定性。往返时间可能变得很大以致于由于主机超时造成连接中断。

    拥塞崩溃和不正常的拥塞通常不出现在ARPANET/MILNET系统中，因为这
些网络有足够大的超额容量。只要连接不经过IP网关，增强的主机流量控制机
制通常能防止拥塞崩溃，特别是自从针对和纯ARPANET网情况相关的时间常量
很好地调整了TCP实现以来。然而，当TCP运行在ARPANET/MILNET上数据
报在网关被丢弃时，除了ICMP的源抑制报文外，没有什么基本的机制来防止拥
塞崩溃。一些运行不好的主机通过它们自身使网关拥塞并阻止其他主机通过是没
价值的。我们已经在ARPANET上的某些主机上（我们已私下与这些主机的管理
员交流过）重复观察到这个问题。

    给网关添加额外的内存不能解决这个问题。添加的内存越多，在数据报被丢
弃之前往返时间变得越长。这样，拥塞崩溃的发生将被延迟，但当崩溃发生时，
网络中的更大的数据报分片将被复制，吞吐量将变得更糟。
两个问题
    和TCP实现的技术有关的两个关键问题已经被观察到；我们称它们为短数
据报问题和源抑制问题。第二个问题正由几个实现方案着手解决，第一个问题通
常被（不正确地）认为已经被解决了。我们发现，一旦短数据报问题解决，源抑
制问题就变得更加容易处理。因此，我们首先提出短数据报问题及其解决方案。
短数据报问题
    这里有一个与短数据报相关的具体问题。当TCP用来传输来自键盘的单字
符信息时，典型的结果是为了传输一个字节的有用数据传输了41个字节的数据
报（1个字节的数据，40个字节的头文件）。这4000%的开销是令人讨厌的，但
在轻负载的网络里是可以容忍的。然而，在负荷过重的网络中，由这个开销引起
的拥塞能导致数据报的丢失和重传，以及在交换节点和网关中由于拥塞而造成传
输时间过大。事实上，吞吐量可能降低以致于TCP连接被异常中断。

    这个典型的问题在20世纪60年代下半期在Tymnet网络中第一次被提出并
被广泛认识。那里所采用的解决办法是强行对每单位时间里所产生的数据报的数
量给定一个限制。这个限制是通过对短数据报延迟一个短的时间（200-500ms）
后再传输来实施的，以期可以在定时器到时之前另一个或两个字符到来并附加在
同一个数据报中。为了增加用户的可接受性，一个附加的特性是当一个控制字符
（比如回车字符）到来时，禁止时间延迟。

    这个技术已经在NCP Telnet，X.25 PADs 和TCP Telnet中使用。它的优点是
易于理解和不难实现。它的缺点是很难给出一个使每个人满意的时限。一个在
10M bps以太网上提供高速应答服务的时限太短以致于不能防止在有5秒往返时
间的高负荷的网络上的拥塞崩溃；相反，处理高负荷的网络的时限太长又会给以
太网的用户造成挫折感。
短数据报的解决方案
    显然,一个自适应的方法是不难想到的。我们期望为自适应交互包的时限提
出一个建议方案，这个时限是在TCP所观察到的往返时间延迟的基础上的。然而
虽然这样一个机制确实能被实现，但它是不必要的。我们发现了一个简单且优化
的解决方案。

    这个解决方案是，如果任何先前在连接上传输的数据仍没有被确认，那么来
自用户的输出数据到来时，禁止传输TCP数据段。这个限制是无条件的，没有定
时器，不需要测试收到的数据的大小，不需要其他条件。典型的实现只需要TCP
程序中的一两行程序。

乍看，这个解决方案好象意味着TCP行为的剧烈改变。但并非如此。最终它
很好地工作。让我们看看为什么是这样。

    当一个用户向一个TCP连接写数据时,TCP收到一些数据。它可以保持这些
数据以便以后传送或者也可以立即送出一个数据包。如果它不立即传送，它将在
一个传入的数据包到来且改变了系统状态之后传送数据。可以有两种方式之一来
改变这种状态；这个到来的数据包确认远端主机收到数据，或者通告远端主机为
新数据提供的可用缓冲空间大小。（后者指“更新窗口”）。每次，此连接上的数
据到来时，TCP必须重新检查它的当前状态并可能会送出一些数据包。这样，当
我们忽略送出来自用户端的数据时，我们只是简单地延迟传输直到下一个来自远
端的主机的报文到来。报文总是很快就到来，除非这条连接之前是空闲的或者与
另一端的通信丢失。在第一种情况，即空闲连接，我们的方案将使用户在任何时
候向TCP连接写数据时送出数据包。这样，我们就不会在空闲连接时死锁。第二
种情况，远端主机失败，传送更多的数据都是无效的。注意，我们没有采取任何
措施来禁止正常的TCP重传逻辑，因此，丢失报文不是问题。

    这个方案在不同条件下的性能测试表明这个方案可以在所有情况下工作。第
一个测试的情况是我们想解决面向字符的Telnet连接问题。让我们想象一下，
用户每200ms向TCP输出一个新的字符，并且这个连接要经过以太网，此以太网