組織：中國互動(dòng)出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：（  ）
譯文發(fā)布時(shí)間：2001-12-28
版權(quán)：本中文翻譯文檔版權(quán)歸中國互動(dòng)出版網(wǎng)所有?？梢杂糜诜巧虡I(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。



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


 
                         TCP/IP互聯(lián)網(wǎng)上的擁塞控制
（RFC896——Congestion Control in IP/TCP Internetworks）


    這個(gè)文檔討論了TCP/IP互聯(lián)網(wǎng)上擁塞控制的某些方面的問題。它旨在激發(fā)
人們對這個(gè)問題的思考和進(jìn)一步的討論。為了實(shí)現(xiàn)改良的擁塞控制而提出某些具
體建議時(shí),這個(gè)文檔并不具體制定任何標(biāo)準(zhǔn)。
                                  引  言
    擁塞控制在復(fù)雜的網(wǎng)絡(luò)中公認(rèn)的問題。我們發(fā)現(xiàn)，國防部的網(wǎng)間網(wǎng)協(xié)議（IP），
一種純數(shù)據(jù)報(bào)協(xié)議，和傳輸控制協(xié)議（TCP），一種傳輸層協(xié)議，當(dāng)把它們一起使
用時(shí)容易遭受不尋常的擁塞問題，這是由在傳輸層和數(shù)據(jù)報(bào)層之間的相互作用而
引起的。特別的，IP網(wǎng)關(guān)對于被我們稱為“擁塞崩潰”的現(xiàn)象而言是脆弱的，
特別是當(dāng)這種網(wǎng)關(guān)連到大范圍的不同帶寬的網(wǎng)絡(luò)上的時(shí)候。我們研究了防止擁塞
崩潰的方案。

    由于這些協(xié)議在基于ARPANET IMP技術(shù)的網(wǎng)絡(luò)上使用頻繁，這些問題沒有得
到普遍的認(rèn)識?；贏RPANET IMP的網(wǎng)絡(luò)通常有一致的帶寬和完全相同的交換節(jié)
點(diǎn)，并且容量很大。對大多數(shù)TCP/IP主機(jī)和網(wǎng)絡(luò)而言, 盈余的容量以及IMP系
統(tǒng)控制主機(jī)傳輸量的能力已足以處理擁塞。然而,隨著最近ARPANET分成兩個(gè)互
連的網(wǎng)絡(luò)以及連到ARPANET上的具有不同特性的其他網(wǎng)絡(luò)的增長,IMP系統(tǒng)良性
特性中的可靠性已不足以允許主機(jī)迅速而可靠的通信。為了使網(wǎng)絡(luò)成功的運(yùn)轉(zhuǎn),
必須改善擁塞控制。

    福特航空航天及通信股份有限公司,和它的總公司,福特汽車公司,經(jīng)營著如
今實(shí)際存在的唯一一家私有的TCP/IP長距離網(wǎng)絡(luò)。這個(gè)網(wǎng)絡(luò)與四個(gè)網(wǎng)點(diǎn)相連(一
個(gè)在Michigan,兩個(gè)在Galifornia,另一個(gè)在England),它們中的一些還有大規(guī)
模的本地網(wǎng)。這個(gè)網(wǎng)絡(luò)交叉連接在ARPANET上但卻使用它自己的長距離線路。福
特公司各網(wǎng)點(diǎn)之間通過私人租賃線路進(jìn)行傳輸，包括一條專用的橫渡大西洋的衛(wèi)
星通訊線路。所有的交換節(jié)點(diǎn)都是沒有點(diǎn)到點(diǎn)流量控制的純IP報(bào)交換，并且所
有主機(jī)運(yùn)行的軟件都是由福特公司或它的子公司編寫或者經(jīng)他們大量修改的軟
件。這個(gè)網(wǎng)絡(luò)上的鏈接帶寬變化很大，從1200到10，000，000bps。通常，我
們已經(jīng)沒有能力購買昂貴的ARPANET那樣的額外的長距離帶寬，而且我們的長距
離鏈接在高峰時(shí)期是超負(fù)荷的。幾秒的傳輸時(shí)間在我們的網(wǎng)絡(luò)里是如此的平常。
由于我們的純數(shù)據(jù)報(bào)定向,負(fù)荷過重和帶寬的大范圍變化，我們不得不去解決
ARPANET/MILNET組織才剛開始認(rèn)識到的問題。我們的網(wǎng)絡(luò)對主機(jī)的TCP實(shí)現(xiàn)的
次最優(yōu)性能很敏感，包括與我們的網(wǎng)絡(luò)連接或斷開。我們力圖檢查在不同條件下
的TCP性能，并且已經(jīng)解決了一些TCP普遍存在的問題。在這里我們提出了兩個(gè)
問題及其解決辦法。許多TCP實(shí)現(xiàn)有這些問題；如果對于某個(gè)給定的TCP實(shí)現(xiàn)，
經(jīng)過ARPANET/MILNET網(wǎng)關(guān)的吞吐量比經(jīng)過一個(gè)單一的網(wǎng)絡(luò)糟，那么很可能這個(gè)
TCP實(shí)現(xiàn)存在這些問題中的一個(gè)或兩個(gè)。

擁塞崩潰

    在我們開始討論這兩個(gè)具體問題及其解決辦法之前，描述一下當(dāng)這些問題沒
有解決時(shí)會(huì)發(fā)生什么是妥當(dāng)?shù)?。在?fù)載較重的帶有端到端重發(fā)機(jī)制的純數(shù)據(jù)報(bào)網(wǎng)
絡(luò)中，當(dāng)交換節(jié)點(diǎn)擁塞時(shí)，網(wǎng)絡(luò)上的往返時(shí)間增加，在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)報(bào)的數(shù)
量也增加了。這在輕負(fù)載下是正常的.只要在傳輸中僅有每個(gè)數(shù)據(jù)報(bào)的一個(gè)拷貝，
擁塞就在控制之中。一旦還沒遞送成功的數(shù)據(jù)報(bào)開始重傳，潛在的嚴(yán)重問題就可
能會(huì)出現(xiàn)。

    主機(jī)TCP的實(shí)現(xiàn)預(yù)期在增加的時(shí)間間隔內(nèi)多次重傳數(shù)據(jù)報(bào)，直到重傳間隔
的某個(gè)時(shí)間上限已到。通常，這個(gè)機(jī)制足以防止嚴(yán)重的擁塞問題。雖然有更好的
自適應(yīng)主機(jī)重傳算法，但是網(wǎng)絡(luò)上的意外負(fù)載能使往返時(shí)間的增長速度比發(fā)送方
估計(jì)的往返時(shí)間的更新更快。當(dāng)一個(gè)新的大量數(shù)據(jù)傳輸時(shí)，這樣的負(fù)載就產(chǎn)生了，
這樣的文件傳輸開始填充一個(gè)大的窗口。如果這個(gè)往返時(shí)間超過了所有主機(jī)的最
大重傳間隔，那么主機(jī)將開始向網(wǎng)絡(luò)產(chǎn)生越來越多的同一數(shù)據(jù)報(bào)的副本。這時(shí),
這個(gè)網(wǎng)絡(luò)有了嚴(yán)重問題。最終在交換節(jié)點(diǎn)中所有可獲得的緩沖將飽和，于是必須
丟失數(shù)據(jù)報(bào)。這時(shí),被傳送的這個(gè)數(shù)據(jù)報(bào)的往返時(shí)間到達(dá)它的最大值。主機(jī)多次
發(fā)送每個(gè)報(bào)文，最終每個(gè)報(bào)文的某個(gè)拷貝到達(dá)它的目的地。這就是擁塞崩潰。

    這個(gè)狀態(tài)是穩(wěn)定的。一旦到達(dá)飽和點(diǎn)，如果選擇包丟棄算法良好，網(wǎng)絡(luò)將繼
續(xù)運(yùn)行在性能降低了的狀態(tài)下。在這種狀態(tài)下，每個(gè)包被傳輸幾次，吞吐量將降
低到正常情況的幾分之一。我們實(shí)驗(yàn)性地迫使我們的網(wǎng)絡(luò)處于這樣的狀態(tài)并且觀
察它的穩(wěn)定性。往返時(shí)間可能變得很大以致于由于主機(jī)超時(shí)造成連接中斷。

    擁塞崩潰和不正常的擁塞通常不出現(xiàn)在ARPANET/MILNET系統(tǒng)中，因?yàn)檫@
些網(wǎng)絡(luò)有足夠大的超額容量。只要連接不經(jīng)過IP網(wǎng)關(guān)，增強(qiáng)的主機(jī)流量控制機(jī)
制通常能防止擁塞崩潰，特別是自從針對和純ARPANET網(wǎng)情況相關(guān)的時(shí)間常量
很好地調(diào)整了TCP實(shí)現(xiàn)以來。然而，當(dāng)TCP運(yùn)行在ARPANET/MILNET上數(shù)據(jù)
報(bào)在網(wǎng)關(guān)被丟棄時(shí)，除了ICMP的源抑制報(bào)文外，沒有什么基本的機(jī)制來防止擁
塞崩潰。一些運(yùn)行不好的主機(jī)通過它們自身使網(wǎng)關(guān)擁塞并阻止其他主機(jī)通過是沒
價(jià)值的。我們已經(jīng)在ARPANET上的某些主機(jī)上（我們已私下與這些主機(jī)的管理
員交流過）重復(fù)觀察到這個(gè)問題。

    給網(wǎng)關(guān)添加額外的內(nèi)存不能解決這個(gè)問題。添加的內(nèi)存越多，在數(shù)據(jù)報(bào)被丟
棄之前往返時(shí)間變得越長。這樣，擁塞崩潰的發(fā)生將被延遲，但當(dāng)崩潰發(fā)生時(shí)，
網(wǎng)絡(luò)中的更大的數(shù)據(jù)報(bào)分片將被復(fù)制，吞吐量將變得更糟。
兩個(gè)問題
    和TCP實(shí)現(xiàn)的技術(shù)有關(guān)的兩個(gè)關(guān)鍵問題已經(jīng)被觀察到；我們稱它們?yōu)槎虜?shù)
據(jù)報(bào)問題和源抑制問題。第二個(gè)問題正由幾個(gè)實(shí)現(xiàn)方案著手解決，第一個(gè)問題通
常被（不正確地）認(rèn)為已經(jīng)被解決了。我們發(fā)現(xiàn)，一旦短數(shù)據(jù)報(bào)問題解決，源抑
制問題就變得更加容易處理。因此，我們首先提出短數(shù)據(jù)報(bào)問題及其解決方案。
短數(shù)據(jù)報(bào)問題
    這里有一個(gè)與短數(shù)據(jù)報(bào)相關(guān)的具體問題。當(dāng)TCP用來傳輸來自鍵盤的單字
符信息時(shí)，典型的結(jié)果是為了傳輸一個(gè)字節(jié)的有用數(shù)據(jù)傳輸了41個(gè)字節(jié)的數(shù)據(jù)
報(bào)（1個(gè)字節(jié)的數(shù)據(jù)，40個(gè)字節(jié)的頭文件）。這4000%的開銷是令人討厭的，但
在輕負(fù)載的網(wǎng)絡(luò)里是可以容忍的。然而，在負(fù)荷過重的網(wǎng)絡(luò)中，由這個(gè)開銷引起
的擁塞能導(dǎo)致數(shù)據(jù)報(bào)的丟失和重傳，以及在交換節(jié)點(diǎn)和網(wǎng)關(guān)中由于擁塞而造成傳
輸時(shí)間過大。事實(shí)上，吞吐量可能降低以致于TCP連接被異常中斷。

    這個(gè)典型的問題在20世紀(jì)60年代下半期在Tymnet網(wǎng)絡(luò)中第一次被提出并
被廣泛認(rèn)識。那里所采用的解決辦法是強(qiáng)行對每單位時(shí)間里所產(chǎn)生的數(shù)據(jù)報(bào)的數(shù)
量給定一個(gè)限制。這個(gè)限制是通過對短數(shù)據(jù)報(bào)延遲一個(gè)短的時(shí)間（200-500ms）
后再傳輸來實(shí)施的，以期可以在定時(shí)器到時(shí)之前另一個(gè)或兩個(gè)字符到來并附加在
同一個(gè)數(shù)據(jù)報(bào)中。為了增加用戶的可接受性，一個(gè)附加的特性是當(dāng)一個(gè)控制字符
（比如回車字符）到來時(shí)，禁止時(shí)間延遲。

    這個(gè)技術(shù)已經(jīng)在NCP Telnet，X.25 PADs 和TCP Telnet中使用。它的優(yōu)點(diǎn)是
易于理解和不難實(shí)現(xiàn)。它的缺點(diǎn)是很難給出一個(gè)使每個(gè)人滿意的時(shí)限。一個(gè)在
10M bps以太網(wǎng)上提供高速應(yīng)答服務(wù)的時(shí)限太短以致于不能防止在有5秒往返時(shí)
間的高負(fù)荷的網(wǎng)絡(luò)上的擁塞崩潰；相反，處理高負(fù)荷的網(wǎng)絡(luò)的時(shí)限太長又會(huì)給以
太網(wǎng)的用戶造成挫折感。
短數(shù)據(jù)報(bào)的解決方案
    顯然,一個(gè)自適應(yīng)的方法是不難想到的。我們期望為自適應(yīng)交互包的時(shí)限提
出一個(gè)建議方案，這個(gè)時(shí)限是在TCP所觀察到的往返時(shí)間延遲的基礎(chǔ)上的。然而
雖然這樣一個(gè)機(jī)制確實(shí)能被實(shí)現(xiàn)，但它是不必要的。我們發(fā)現(xiàn)了一個(gè)簡單且優(yōu)化
的解決方案。

    這個(gè)解決方案是，如果任何先前在連接上傳輸?shù)臄?shù)據(jù)仍沒有被確認(rèn)，那么來
自用戶的輸出數(shù)據(jù)到來時(shí)，禁止傳輸TCP數(shù)據(jù)段。這個(gè)限制是無條件的，沒有定
時(shí)器，不需要測試收到的數(shù)據(jù)的大小，不需要其他條件。典型的實(shí)現(xiàn)只需要TCP
程序中的一兩行程序。

乍看，這個(gè)解決方案好象意味著TCP行為的劇烈改變。但并非如此。最終它
很好地工作。讓我們看看為什么是這樣。

    當(dāng)一個(gè)用戶向一個(gè)TCP連接寫數(shù)據(jù)時(shí),TCP收到一些數(shù)據(jù)。它可以保持這些
數(shù)據(jù)以便以后傳送或者也可以立即送出一個(gè)數(shù)據(jù)包。如果它不立即傳送，它將在
一個(gè)傳入的數(shù)據(jù)包到來且改變了系統(tǒng)狀態(tài)之后傳送數(shù)據(jù)。可以有兩種方式之一來
改變這種狀態(tài)；這個(gè)到來的數(shù)據(jù)包確認(rèn)遠(yuǎn)端主機(jī)收到數(shù)據(jù)，或者通告遠(yuǎn)端主機(jī)為
新數(shù)據(jù)提供的可用緩沖空間大小。（后者指“更新窗口”）。每次，此連接上的數(shù)
據(jù)到來時(shí)，TCP必須重新檢查它的當(dāng)前狀態(tài)并可能會(huì)送出一些數(shù)據(jù)包。這樣，當(dāng)
我們忽略送出來自用戶端的數(shù)據(jù)時(shí)，我們只是簡單地延遲傳輸直到下一個(gè)來自遠(yuǎn)
端的主機(jī)的報(bào)文到來。報(bào)文總是很快就到來，除非這條連接之前是空閑的或者與
另一端的通信丟失。在第一種情況，即空閑連接，我們的方案將使用戶在任何時(shí)
候向TCP連接寫數(shù)據(jù)時(shí)送出數(shù)據(jù)包。這樣，我們就不會(huì)在空閑連接時(shí)死鎖。第二
種情況，遠(yuǎn)端主機(jī)失敗，傳送更多的數(shù)據(jù)都是無效的。注意，我們沒有采取任何
措施來禁止正常的TCP重傳邏輯，因此，丟失報(bào)文不是問題。

    這個(gè)方案在不同條件下的性能測試表明這個(gè)方案可以在所有情況下工作。第
一個(gè)測試的情況是我們想解決面向字符的Telnet連接問題。讓我們想象一下，