組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：（  ）
譯文發布時間：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連接問題。讓我們想象一下，