用戶每200ms向TCP輸出一個(gè)新的字符，并且這個(gè)連接要經(jīng)過以太網(wǎng)，此以太網(wǎng)
的往返時(shí)間包括了50ms的軟件處理時(shí)間。如果沒有任何機(jī)制來防止短數(shù)據(jù)報(bào)的
擁塞，與 每個(gè)字符對應(yīng)的數(shù)據(jù)包將被送出，響應(yīng)是最佳的。開銷將是4000%，
但在以太網(wǎng)上可以接受的。而典型的定時(shí)器方案，每秒兩個(gè)數(shù)據(jù)包的限制，將使
兩個(gè)或三個(gè)字符在一個(gè)數(shù)據(jù)包中被傳送。響應(yīng)性能將降低，即使在高帶寬的以太
網(wǎng)上也是沒有用的。開銷降到1500%，但在以太網(wǎng)上這是個(gè)不太好的替換方案。
而我們的方案，用戶所敲擊的每個(gè)字符將找到一條空閑的TCP連接，字符將立刻
被傳送，正如在無控制的情況一樣。用戶將不會(huì)感覺到延遲。這樣，我們的方案
既可作為無控制的方案運(yùn)行又可以提供比定時(shí)器方案更好的響應(yīng)。

    第二個(gè)測試的情況是同樣的Telnet測試，但是測試是在有5秒往返時(shí)間的
長距離連接上。如果沒有任何機(jī)制防止短數(shù)據(jù)包擁塞，25個(gè)數(shù)據(jù)包將在5秒內(nèi)
被送出。這兒開銷是4000% 。用典型的定時(shí)器方案且同樣是每秒2個(gè)數(shù)據(jù)包的限
制，將仍有10 個(gè)數(shù)據(jù)包不能處理并引起擁塞。當(dāng)然往返時(shí)間將不會(huì)因傳送很多
的數(shù)據(jù)包而得到改善；通常，它會(huì)因數(shù)據(jù)包競爭行時(shí)間而變得更糟。這時(shí)開銷降
到了1500%。然而，用我們的方案，來自用戶的第一個(gè)字符將發(fā)現(xiàn)空閑的TCP連
接且立即傳送。接下來的24個(gè)字符，以200ms的間隔從用戶端到來，將等待遠(yuǎn)
端主機(jī)來的報(bào)文。當(dāng)一個(gè)對第一個(gè)數(shù)據(jù)報(bào)的確認(rèn)ACK在5秒末到來時(shí)，這24個(gè)
等待的字符封裝到數(shù)據(jù)包中被傳送出去。這樣，我們的方案導(dǎo)致了在沒有損失響
應(yīng)時(shí)間的情況下開銷減少到320%。用我們的方案響應(yīng)時(shí)間通常因?yàn)閿?shù)據(jù)包開銷
減少而得到改善。擁塞將減少且往返時(shí)間延遲將顯著下降。在這個(gè)情況中，我們
的方案明顯優(yōu)于其他方法。

    我們對所有的TCP連接使用我們的方案，不僅僅是Telnet連接。讓我們看
看用我們的方法為文件傳輸建立數(shù)據(jù)連接時(shí)將會(huì)發(fā)生什么。我們將再一次考慮到
這兩個(gè)極端的情況。

    象前面所提的一樣，我們首先考慮以太網(wǎng)的情況。用戶現(xiàn)在以512字節(jié)塊的
大小按TCP所能接受的速度向TCP寫數(shù)據(jù)。用戶第一次向TCP寫的數(shù)據(jù)啟動(dòng)傳輸；
我們的第一個(gè)數(shù)據(jù)報(bào)的大小將是512+40字節(jié)或552字節(jié)。用戶的第二次寫數(shù)據(jù)
不會(huì)引起傳送但會(huì)使這個(gè)塊被緩沖。設(shè)想用戶在第一個(gè)確認(rèn)到來之前填充TCP的
輸出緩沖區(qū)。然后，當(dāng)ACK到來時(shí)，滿足窗口大小的所有排隊(duì)數(shù)據(jù)將被送出，從
那時(shí)起，窗口保持為滿，每個(gè)ACK開始一個(gè)傳送循環(huán)，等待的數(shù)據(jù)被送出。這樣,
在一個(gè)往返時(shí)間初始周期以后，只有一個(gè)塊要傳送時(shí)，我們的方案解決了最大吞
吐量的情況。由于啟動(dòng)延遲在以太網(wǎng)上只有50ms，因此，啟動(dòng)的瞬時(shí)延遲是無
關(guān)重要的。三種方案都對這種情況提供了等價(jià)的性能。

    最后，讓我們看看在有5秒往返時(shí)間的連接上的文件傳輸。在第一個(gè)確認(rèn)回
來之前只有一個(gè)數(shù)據(jù)包被發(fā)送；窗口將被填充并填滿。因?yàn)橥禃r(shí)間是5秒，只
有512字節(jié)的數(shù)據(jù)在第一個(gè)5秒被發(fā)送。假定有一個(gè)2k的窗口，一旦第一個(gè)確
認(rèn)來到，2K的數(shù)據(jù)將被發(fā)送，之后，將保持每5秒2K的穩(wěn)定速率。只有在這種
情況下我們的方案才比定時(shí)器方案差，差別只在啟動(dòng)瞬時(shí)。穩(wěn)定狀態(tài)下的吞吐量
是相同的。樸素的方案和定時(shí)器方案在上面所提的情況下都要花250秒來傳輸
100K字節(jié)的文件，我們的方案將花254秒，1.6%的差別。
     			
帶ICMP的擁塞控制

    解決了短數(shù)據(jù)報(bào)問題以及在我們自己網(wǎng)絡(luò)中的極端的短數(shù)據(jù)報(bào)擁塞問題，我
們把注意力轉(zhuǎn)向通常的擁塞控制。既然我們的網(wǎng)絡(luò)是沒有點(diǎn)對點(diǎn)流量控制的純數(shù)
據(jù)報(bào)網(wǎng)絡(luò)，對我們而言，在IP標(biāo)準(zhǔn)下可獲得的唯一機(jī)制是ICMP源抑制報(bào)文。在
精心的控制下，我們發(fā)現(xiàn)這足以防止嚴(yán)重的擁塞問題。我們發(fā)現(xiàn)留心主機(jī)或交換
節(jié)點(diǎn)對源抑制報(bào)文的行為是必要的。
何時(shí)發(fā)ICMP源抑制報(bào)文    
    當(dāng)前的ICMP標(biāo)準(zhǔn) 規(guī)定，無論何時(shí)包丟失，ICMP源抑制報(bào)文就應(yīng)該被發(fā)送，
此外，當(dāng)網(wǎng)關(guān)發(fā)現(xiàn)自己資源不足時(shí)也應(yīng)發(fā)送源抑制報(bào)文。這里有些二義性，但很
明顯,沒有送ICMP報(bào)文而丟棄數(shù)據(jù)包違背了的標(biāo)準(zhǔn)。

    我們的基本假設(shè)是，在網(wǎng)絡(luò)正常運(yùn)行時(shí)數(shù)據(jù)包不應(yīng)該被丟棄。因此我們想在
發(fā)送方使交換節(jié)點(diǎn)和網(wǎng)關(guān)超負(fù)荷之前抑制發(fā)送方重發(fā)。我們的交換節(jié)點(diǎn)在緩沖區(qū)
耗盡之前能很好地發(fā)送ICMP源抑制報(bào)文；直到它們在發(fā)送ICMP源抑制報(bào)文之前
必須丟棄報(bào)文時(shí)才等待。正如我們在短數(shù)據(jù)報(bào)問題的分析中演示的，僅僅提供大
量的緩沖是不能解決問題的。通常，我們的經(jīng)驗(yàn)是，當(dāng)用了緩沖區(qū)的一半左右，
源抑制報(bào)文就應(yīng)該發(fā)送了；這不是基于廣泛的實(shí)驗(yàn)，但似乎是個(gè)合理的技術(shù)決定。
可以討論一個(gè)自適應(yīng)方案，這個(gè)方案可以調(diào)整基于近期經(jīng)驗(yàn)的抑制產(chǎn)生邊界；到
目前為止我們還沒有發(fā)現(xiàn)這個(gè)必要性。

    還有其他的網(wǎng)關(guān)實(shí)現(xiàn)算法，僅在不只一個(gè)包被丟棄之后才產(chǎn)生源抑制報(bào)文。
我們認(rèn)為這種方法是不好的，因?yàn)槿魏位诎鼇G棄的擁塞控制系統(tǒng)浪費(fèi)帶寬，且
可能在負(fù)荷重時(shí)容易受擁塞崩潰的影響。我們理解的是，被動(dòng)地產(chǎn)生源抑制報(bào)文
的方案基于這樣的擔(dān)心，害怕確認(rèn)傳輸將被抑制以及這將導(dǎo)致連接失敗。正如下
面將要展示的，在主機(jī)實(shí)現(xiàn)中的恰當(dāng)?shù)脑匆种瓶刂婆懦诉@種可能性。


在收到ICMP源抑制報(bào)文時(shí)做什么
  
     當(dāng)ICMP收到一個(gè)源抑制報(bào)文時(shí)我們通知TCP或者該層上的任意其他協(xié)議。
我們的TCP具體實(shí)現(xiàn)的基本行為是減少與源抑制報(bào)文中所指出的主機(jī)的連接上
未處理的數(shù)據(jù)的數(shù)量。使發(fā)送端TCP的反應(yīng)就象遠(yuǎn)端主機(jī)窗口大小已經(jīng)減少,從
而實(shí)施這個(gè)控制。我們的第一個(gè)實(shí)現(xiàn)過于簡單化但卻有效；一旦收到源抑制報(bào)文，
只要窗口不為空，我們的TCP就認(rèn)為窗口大小為0并做相應(yīng)處理。這個(gè)行為將持
續(xù)到收到一定數(shù)量（現(xiàn)在是10）的ACK為止，到那時(shí)，TCP回到正常的運(yùn)行狀態(tài)
 。Linkabit公司的David Mills 在他的DCN系統(tǒng)中實(shí)現(xiàn)了一個(gè)類似的但更詳細(xì)
的對未處理的數(shù)據(jù)包的節(jié)流控制。這個(gè)附加的復(fù)雜性好象提供了一個(gè)獲得吞吐量
的方式，但我們沒有做過正式的測試。兩個(gè)實(shí)現(xiàn)都有效地防止了交換節(jié)點(diǎn)的擁塞
崩潰。

    這樣，源抑制方法有效地限制了到有限數(shù)量（可能為1）的未處理報(bào)文的連
接。因此，通信能繼續(xù)但是速率降低，那正是期望的效果。

    這個(gè)方案有個(gè)重要的性質(zhì)，源抑制不能禁止確認(rèn)和重傳的發(fā)送。源抑制在
IP層上的完全實(shí)現(xiàn)通常是不成功的，因?yàn)镮P缺少足夠的信息來正確地控制一個(gè)
連接的流量。抑制確認(rèn)信息往往產(chǎn)生重傳和不必要的傳輸。抑制重傳可能因重傳
超時(shí)而使連接丟失。我們的方案將在服務(wù)器超負(fù)荷下保持活動(dòng)連接但減少每個(gè)連
接的帶寬。

    在同一層與TCP一樣的其他協(xié)議也應(yīng)該響應(yīng)源抑制。在每種情況下，我們建
議應(yīng)該控制新的傳輸流量但正常對待確認(rèn)。唯一嚴(yán)重的問題來自于用戶數(shù)據(jù)報(bào)協(xié)
議，而通常不的主要傳輸發(fā)生器。我們?nèi)晕丛谶@些協(xié)議中實(shí)現(xiàn)任何流量控制。
網(wǎng)關(guān)的自防御
    正如我們已經(jīng)顯示的，網(wǎng)關(guān)易受擁塞管理不善的主機(jī)的攻擊。由于產(chǎn)生過多
通信量而引起的主機(jī)錯(cuò)誤行為不僅防止了主機(jī)自身的傳輸而且能影響了其他不
相關(guān)的傳輸。這個(gè)問題可以在主機(jī)級處理，但既然一臺(tái)有故障的主機(jī)能影響其他
主機(jī)，將來的網(wǎng)關(guān)應(yīng)該有防御能力使它們自己不被那些可惡可憎的主機(jī)的這種行
為所影響。我們提供了一些基本的自防御技術(shù)。

    曾經(jīng)在1983年下半年，一個(gè)在ARPANT主機(jī)中的TCP故障使主機(jī)以ARPANET
所能接受的速度瘋狂地產(chǎn)生相同數(shù)據(jù)報(bào)的重發(fā)報(bào)文。通過ARPANET連接到我們網(wǎng)
絡(luò)的網(wǎng)關(guān)飽和，既然這個(gè)網(wǎng)關(guān)到ARPANET的帶寬比到我們網(wǎng)絡(luò)的要寬，少量有用
的傳輸能通過。網(wǎng)關(guān)忙于發(fā)送源抑制報(bào)文但故障主機(jī)忽略它們。這持續(xù)了幾個(gè)小
時(shí)，直到故障主機(jī)崩潰。在這期間，我們的網(wǎng)絡(luò)有效地從ARPANET上斷開。

    當(dāng)網(wǎng)關(guān)被迫丟棄一個(gè)數(shù)據(jù)包時(shí)，網(wǎng)關(guān)慎重地選擇要丟棄的數(shù)據(jù)包。做這個(gè)決
定的典型技術(shù)是丟棄最近收到的數(shù)據(jù)包，或者數(shù)據(jù)包在最長的輸出隊(duì)列的末端。
我們提出一個(gè)值得的實(shí)用方法是，丟棄在網(wǎng)關(guān)中產(chǎn)生最多數(shù)據(jù)包的隊(duì)列的對應(yīng)主
機(jī)所產(chǎn)生的最近的數(shù)據(jù)包，這種策略有助于平衡使用這個(gè)網(wǎng)關(guān)的各主機(jī)間的吞吐
量。我們還沒有嘗試過這個(gè)策略，但它似乎是網(wǎng)關(guān)自保護(hù)的一個(gè)合理開始點(diǎn)。

    另一個(gè)策略是丟棄新到來的數(shù)據(jù)包，如果這個(gè)數(shù)據(jù)包已經(jīng)在隊(duì)列中做了一個(gè)
拷貝。如果使用哈希技術(shù)，為實(shí)現(xiàn)這一檢查的計(jì)算負(fù)荷就不是問題。這個(gè)檢查不
能防止惡毒主機(jī)的攻擊，但提供了一些保護(hù)措施來防止帶低劣重傳控制的TCP實(shí)
現(xiàn)。如果本地主機(jī)與本地網(wǎng)絡(luò)很好地協(xié)調(diào)工作，那么在快速本地網(wǎng)與慢速長距離
網(wǎng)絡(luò)之間的網(wǎng)關(guān)可以發(fā)現(xiàn)這個(gè)檢查是有價(jià)值的。

    理想的情況是網(wǎng)關(guān)應(yīng)該檢測出故障主機(jī)并抑制它們；這樣的檢測在純數(shù)據(jù)報(bào)
系統(tǒng)中是困難的。雖然，對ICMP源抑制報(bào)文的響應(yīng)失敗應(yīng)該被認(rèn)為是網(wǎng)關(guān)與主
機(jī)斷開的依據(jù)。檢測這樣的失效是重不尋常的但它是一個(gè)值得進(jìn)一步研究的領(lǐng)
域。
 
結(jié)論
     
    與純數(shù)據(jù)報(bào)網(wǎng)絡(luò)相關(guān)的擁塞控制問題是困難的，但有效的解決辦法是存在
的。如果TCP/IP在重負(fù)荷下運(yùn)行，TCP實(shí)現(xiàn)算法必須以至少和這里描述過的解
決方法一樣有效的方式來解決這幾個(gè)關(guān)鍵的問題。
   在純ARPANET網(wǎng)中沒有這個(gè)問題，因?yàn)楫?dāng)沒有處理的數(shù)據(jù)包過多時(shí)，IMP機(jī)制將封鎖主
機(jī)，但在這種情況下，涉及到純數(shù)據(jù)報(bào)本地網(wǎng)（比如以太網(wǎng)）或者一個(gè)純數(shù)據(jù)報(bào)網(wǎng)關(guān)（比如
ARPANET/MILNET 網(wǎng)關(guān)），有大量的小數(shù)據(jù)報(bào)未處理是有可能的。
  ARPANET RFC 792 是當(dāng)前的標(biāo)準(zhǔn)。國防通訊部門通告我們，在MIL-STD-1777
中的ICMP描述是不完全的，且在這個(gè)標(biāo)準(zhǔn)將來的修訂版中將被刪除。
  這點(diǎn)遵從控制學(xué)的觀點(diǎn)“不要受比例控制的干擾除非它不工作了。”

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


1
RFC文檔中文翻譯計(jì)劃