組織：中國互動出版網（http://www.china-pub.com/） RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：[email protected] 譯者：（ ） 譯文發佈時間：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輸出一個新的字符，並且這個連接要經過以太網，此以太網 的往返時間包括了50ms的軟件處理時間。如果沒有任何機制來防止短數據報的 擁塞，與 每個字符對應的數據包將被送出，響應是最佳的。開銷將是4000%， 但在以太網上可以接受的。而典型的定時器方案，每秒兩個數據包的限制，將使 兩個或三個字符在一個數據包中被傳送。響應性能將降低，即使在高帶寬的以太 網上也是沒有用的。開銷降到1500%，但在以太網上這是個不太好的替換方案。 而我們的方案，用戶所敲擊的每個字符將找到一條空閒的TCP連接，字符將立刻 被傳送，正如在無控制的情況一樣。用戶將不會感覺到延遲。這樣，我們的方案 既可作爲無控制的方案運行又可以提供比定時器方案更好的響應。 第二個測試的情況是同樣的Telnet測試，但是測試是在有5秒往返時間的 長距離連接上。如果沒有任何機制防止短數據包擁塞，25個數據包將在5秒內 被送出。這兒開銷是4000% 。用典型的定時器方案且同樣是每秒2個數據包的限 制，將仍有10 個數據包不能處理並引起擁塞。當然往返時間將不會因傳送很多 的數據包而得到改善；通常，它會因數據包競爭行時間而變得更糟。這時開銷降 到了1500%。然而，用我們的方案，來自用戶的第一個字符將發現空閒的TCP連 接且立即傳送。接下來的24個字符，以200ms的間隔從用戶端到來，將等待遠 端主機來的報文。當一個對第一個數據報的確認ACK在5秒末到來時，這24個 等待的字符封裝到數據包中被傳送出去。這樣，我們的方案導致了在沒有損失響 應時間的情況下開銷減少到320%。用我們的方案響應時間通常因爲數據包開銷 減少而得到改善。擁塞將減少且往返時間延遲將顯著下降。在這個情況中，我們 的方案明顯優於其他方法。 我們對所有的TCP連接使用我們的方案，不僅僅是Telnet連接。讓我們看 看用我們的方法爲文件傳輸建立數據連接時將會發生什麼。我們將再一次考慮到 這兩個極端的情況。 象前面所提的一樣，我們首先考慮以太網的情況。用戶現在以512字節塊的 大小按TCP所能接受的速度向TCP寫數據。用戶第一次向TCP寫的數據啓動傳輸； 我們的第一個數據報的大小將是512+40字節或552字節。用戶的第二次寫數據 不會引起傳送但會使這個塊被緩衝。設想用戶在第一個確認到來之前填充TCP的 輸出緩衝區。然後，當ACK到來時，滿足窗口大小的所有排隊數據將被送出，從 那時起，窗口保持爲滿，每個ACK開始一個傳送循環，等待的數據被送出。這樣, 在一個往返時間初始週期以後，只有一個塊要傳送時，我們的方案解決了最大吞 吐量的情況。由於啓動延遲在以太網上只有50ms，因此，啓動的瞬時延遲是無 關重要的。三種方案都對這種情況提供了等價的性能。 最後，讓我們看看在有5秒往返時間的連接上的文件傳輸。在第一個確認回 來之前只有一個數據包被髮送；窗口將被填充並填滿。因爲往返時間是5秒，只 有512字節的數據在第一個5秒被髮送。假定有一個2k的窗口，一旦第一個確 認來到，2K的數據將被髮送，之後，將保持每5秒2K的穩定速率。只有在這種 情況下我們的方案才比定時器方案差，差別只在啓動瞬時。穩定狀態下的吞吐量 是相同的。樸素的方案和定時器方案在上面所提的情況下都要花250秒來傳輸 100K字節的文件，我們的方案將花254秒，1.6%的差別。 帶ICMP的擁塞控制 解決了短數據報問題以及在我們自己網絡中的極端的短數據報擁塞問題，我 們把注意力轉向通常的擁塞控制。既然我們的網絡是沒有點對點流量控制的純數 據報網絡，對我們而言，在IP標準下可獲得的唯一機制是ICMP源抑制報文。在 精心的控制下，我們發現這足以防止嚴重的擁塞問題。我們發現留心主機或交換 節點對源抑制報文的行爲是必要的。 何時發ICMP源抑制報文 當前的ICMP標準 規定，無論何時包丟失，ICMP源抑制報文就應該被髮送， 此外，當網關發現自己資源不足時也應發送源抑制報文。這裏有些二義性，但很 明顯,沒有送ICMP報文而丟棄數據包違背了的標準。 我們的基本假設是，在網絡正常運行時數據包不應該被丟棄。因此我們想在 發送方使交換節點和網關超負荷之前抑制發送方重發。我們的交換節點在緩衝區 耗盡之前能很好地發送ICMP源抑制報文；直到它們在發送ICMP源抑制報文之前 必須丟棄報文時纔等待。正如我們在短數據報問題的分析中演示的，僅僅提供大 量的緩衝是不能解決問題的。通常，我們的經驗是，當用了緩衝區的一半左右， 源抑制報文就應該發送了；這不是基於廣泛的實驗，但似乎是個合理的技術決定。 可以討論一個自適應方案，這個方案可以調整基於近期經驗的抑制產生邊界；到 目前爲止我們還沒有發現這個必要性。 還有其他的網關實現算法，僅在不只一個包被丟棄之後才產生源抑制報文。 我們認爲這種方法是不好的，因爲任何基於包丟棄的擁塞控制系統浪費帶寬，且 可能在負荷重時容易受擁塞崩潰的影響。我們理解的是，被動地產生源抑制報文 的方案基於這樣的擔心，害怕確認傳輸將被抑制以及這將導致連接失敗。正如下 面將要展示的，在主機實現中的恰當的源抑制控制排除了這種可能性。 在收到ICMP源抑制報文時做什麼 當ICMP收到一個源抑制報文時我們通知TCP或者該層上的任意其他協議。 我們的TCP具體實現的基本行爲是減少與源抑制報文中所指出的主機的連接上 未處理的數據的數量。使發送端TCP的反應就象遠端主機窗口大小已經減少,從 而實施這個控制。我們的第一個實現過於簡單化但卻有效；一旦收到源抑制報文， 只要窗口不爲空，我們的TCP就認爲窗口大小爲0並做相應處理。這個行爲將持 續到收到一定數量（現在是10）的ACK爲止，到那時，TCP回到正常的運行狀態 。Linkabit公司的David Mills 在他的DCN系統中實現了一個類似的但更詳細 的對未處理的數據包的節流控制。這個附加的複雜性好象提供了一個獲得吞吐量 的方式，但我們沒有做過正式的測試。兩個實現都有效地防止了交換節點的擁塞 崩潰。 這樣，源抑制方法有效地限制了到有限數量（可能爲1）的未處理報文的連 接。因此，通信能繼續但是速率降低，那正是期望的效果。 這個方案有個重要的性質，源抑制不能禁止確認和重傳的發送。源抑制在 IP層上的完全實現通常是不成功的，因爲IP缺少足夠的信息來正確地控制一個 連接的流量。抑制確認信息往往產生重傳和不必要的傳輸。抑制重傳可能因重傳 超時而使連接丟失。我們的方案將在服務器超負荷下保持活動連接但減少每個連 接的帶寬。 在同一層與TCP一樣的其他協議也應該響應源抑制。在每種情況下，我們建 議應該控制新的傳輸流量但正常對待確認。唯一嚴重的問題來自於用戶數據報協 議，而通常不的主要傳輸發生器。我們仍未在這些協議中實現任何流量控制。 網關的自防禦 正如我們已經顯示的，網關易受擁塞管理不善的主機的攻擊。由於產生過多 通信量而引起的主機錯誤行爲不僅防止了主機自身的傳輸而且能影響了其他不 相關的傳輸。這個問題可以在主機級處理，但既然一臺有故障的主機能影響其他 主機，將來的網關應該有防禦能力使它們自己不被那些可惡可憎的主機的這種行 爲所影響。我們提供了一些基本的自防禦技術。 曾經在1983年下半年，一個在ARPANT主機中的TCP故障使主機以ARPANET 所能接受的速度瘋狂地產生相同數據報的重發報文。通過ARPANET連接到我們網 絡的網關飽和，既然這個網關到ARPANET的帶寬比到我們網絡的要寬，少量有用 的傳輸能通過。網關忙於發送源抑制報文但故障主機忽略它們。這持續了幾個小 時，直到故障主機崩潰。在這期間，我們的網絡有效地從ARPANET上斷開。 當網關被迫丟棄一個數據包時，網關慎重地選擇要丟棄的數據包。做這個決 定的典型技術是丟棄最近收到的數據包，或者數據包在最長的輸出隊列的末端。 我們提出一個值得的實用方法是，丟棄在網關中產生最多數據包的隊列的對應主 機所產生的最近的數據包，這種策略有助於平衡使用這個網關的各主機間的吞吐 量。我們還沒有嘗試過這個策略，但它似乎是網關自保護的一個合理開始點。 另一個策略是丟棄新到來的數據包，如果這個數據包已經在隊列中做了一個 拷貝。如果使用哈希技術，爲實現這一檢查的計算負荷就不是問題。這個檢查不 能防止惡毒主機的攻擊，但提供了一些保護措施來防止帶低劣重傳控制的TCP實 現。如果本地主機與本地網絡很好地協調工作，那麼在快速本地網與慢速長距離 網絡之間的網關可以發現這個檢查是有價值的。 理想的情況是網關應該檢測出故障主機並抑制它們；這樣的檢測在純數據報 系統中是困難的。雖然，對ICMP源抑制報文的響應失敗應該被認爲是網關與主 機斷開的依據。檢測這樣的失效是重不尋常的但它是一個值得進一步研究的領 域。 結論 與純數據報網絡相關的擁塞控制問題是困難的，但有效的解決辦法是存在 的。如果TCP/IP在重負荷下運行，TCP實現算法必須以至少和這裏描述過的解 決方法一樣有效的方式來解決這幾個關鍵的問題。 在純ARPANET網中沒有這個問題，因爲當沒有處理的數據包過多時，IMP機制將封鎖主 機，但在這種情況下，涉及到純數據報本地網（比如以太網）或者一個純數據報網關（比如 ARPANET/MILNET 網關），有大量的小數據報未處理是有可能的。 ARPANET RFC 792 是當前的標準。國防通訊部門通告我們，在MIL-STD-1777 中的ICMP描述是不完全的，且在這個標準將來的修訂版中將被刪除。 這點遵從控制學的觀點“不要受比例控制的干擾除非它不工作了。” RFC896——Congestion Control in IP/TCP Internetworks TCP/IP互聯網上的擁塞控制 1 RFC文檔中文翻譯計劃
RFC896_在IPTCP internet網絡中的擁塞控制
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章