作者：Geoff Huston，APNIC
回顧30多年來的互聯網從業經驗，我發現：促使互聯網協議套件成功地成爲全球通信系統首選技術的關鍵，是互聯網協議（IP）本身。作爲一種重疊協 議，它能夠支持幾乎任何類型的通信介質。但是我還想指出IP中另外一個重要的角色，即位於IP之上的可靠傳輸協議－－傳輸控制協議（TCP）。我之所以認 爲它如此重要，是因爲TCP所採用的端到端速率自適應控制算法，與同時代的其他類似協議所使用的可靠網關間虛擬電路流控制系統存在着真正的、根本性的差 異。另一點需要指出的是，TCP並沒有針對任何特定的速度而設計，但是它支持一種能夠平等地使用網絡路徑上所有可用網絡容量的速度。TCP流控制算法的基 本特點在於，它試圖在提供最大限度的效率的同時，保持最大限度的公平性。
關於這個主題，此前發表的文章“TCP性能”[12]和“TCP的未來”[13]主要着眼於TCP的設計原理和性能特徵。TCP的核心特徵是，它試 圖與其他併發進程建立起一種動態的平衡，並且儘量利用各種機會，充分使用所有可用的網絡容量。爲此，它所採用的手段包括：不斷地調節流特性；不斷地檢測網 絡，看其能否支持更高的速度；同時隨時準備在收到的網絡信號發生擁塞時，立即降低當前的發送速率。
在今天的世界中，網絡基礎設施的容量和複雜性與網絡成本息息相關，而所發送的數據則關係到網絡收入，而TCP仍然可以很好地滿足人們在兩方面的要 求。因爲TCP對於網絡組件的功能要求最低，所以讓人們能夠利用簡便的傳輸功能和交換系統構建網絡。“簡便”往往意味着低價和便於擴展，而這裏也不例外。 TCP還試圖通過自適應的端到端流速率控制和謹慎的重發事件管理，最大限度地提高數據傳輸效率。換句話說，TCP是供應商和消費者獲得更加廉價的網絡的重 要手段。對於消費者而言，快速廉價的通信服務將會極大地促進他們對於互聯網服務的需求；而這一直是推動互聯網本身進一步普及的主要動力――其作用遠遠超出 其他因素。“廉價”在當今世界也具有極爲重要的作用，而TCP肯定有助於提高數據通信的效率和降低通信成本。
儘管TCP在很多網絡環境中具有很高的效率，但是這並不意味着它在每個環境中都是如此。例如：
- 在那些存在嚴重無線噪聲的無線環境中，TCP可能會將因爲基於射頻的信號中斷與相應的分組丟棄而造成的後果與網絡擁塞造成的後果相混淆，導致TCP會話過早、過久地降低發送速率。
- 在網絡路由器的緩衝空間不足時，TCP也會過早地降低速率。這種影響較爲隱蔽，但是它關係到TCP算法 的粗糙性和TCP分組隊列的突發性。這些兩倍於網絡容量速率的突發流量可以通過網絡緩衝得到緩解。如果網絡內部的緩衝被消耗殆盡，將會導致分組丟棄，爲當 前的TCP信號產生一箇中斷信號，進而使其發送速率降低一半，或者――在最差情況下――重設會話狀態和重新啓動分組交換。特別是在廣域網中，端到端的延遲 －帶寬產品成爲了一個重要的影響因素，因而TCP會利用網絡緩衝保持與可用網絡容量相符的穩定吞吐率。如果內部緩衝容量不足，就無法保持TCP隊列的平穩 傳輸，也不能讓數據以可用數據速率連續地流過受限節點。
- TCP還需要它的終端主機擁有與轉發和反向路徑上的可用網絡容量相等的本地容量。原因是，TCP不會在遠端發出可靠的確認消息之前丟棄數據，因此發送主機必須在發送數據和遠端發出相應的確認期間，保持數據的一個複本。
即使考慮到這些限制，我們仍然可以肯定地說：TCP在大部分環境中都能發揮重要的作用。雖然如此，我們發現TCP在一個領域面臨着相當艱鉅的挑戰，那就是廣域的、超高速的數據傳輸。
超高速
TCP
目前，終端計算機――即使是筆記本電腦――通常都配備 了千兆以太網接口，並且具有GB級的內存，以及能夠在內存和網絡接口之間每秒傳輸千兆級數據的內部數據通道。目前的IP網絡是利用千兆級通道，高容量交換 機和路由器（假定這兩種分組交換設備之間存在着定量的區別）等構建而成的。如果終端主機和網絡都能夠支持千兆傳輸，那麼TCP會話就應當能夠端到端地以每 秒千兆數據的速度運行，在千兆速度下獲得與百兆速度下相同的效率――是這樣嗎？
事實並非如此！
這個結論並不明顯，特別是在考慮到當今的TCP陸地速度最高記錄時：在3萬公里的網絡距離內，達到大約7Gbps。那麼，事實到底怎樣呢？
下面，讓我們根據TCP的基本原理，瞭解超高速TCP所帶來的一些變化。TCP工作在兩種狀態之下：緩慢啓動和擁塞避免。
- 與“重啓”模式一樣，緩慢啓動模式是TCP在任何會話中的初始工作模式。在這種模式下，TCP會針對推動發送端窗 口的每個ACK分組，發送兩個分組。簡而言之（即使是對於延遲ACK），這種模式讓TCP能夠在每次連續的無丟包往返時間（RTT）間隔中，將發送速率提 升一倍。速率的提升是指數式的，會在每個RTT間隔中有效地增加一倍；速率提升也是突發性的，可以在此期間以兩倍的瓶頸容量將數據發送到網絡。
之所以能夠以兩倍的瓶頸數據速度將數據發送到網絡，是因爲TCP的“ACK時鐘”特性。暫且不考慮複雜的TCP延遲ACK機制，TCP接收端每次在 收到一個分組時會產生一個新的ACK分組。ACK的發送速率實際上與數據分組的接收速率相同。假定採用單向的數據傳輸方式（以確保反向的ACK分組保持最 小的尺寸），而且從接收端到發送端的反向路徑的抖動最小，那麼ACK到達發送端的速率與數據分組到達接收端的速率相當。換句話說，ACK的返回速率與從發 送端到接收端的前向網絡路徑的瓶頸容量相當。因此，通過在每收到一個ACK時發送兩個分組，就能夠有效地以兩倍的瓶頸容量向網絡發送分組。在瓶頸點，交換 設備在一段時間內所收到的數據量，將是它能夠向輸出設備發送的數據量的兩倍。這些數據量將取決於瓶頸鍊路的延遲－帶寬特性。因此可以得出這樣的結論： TCP是一種突發性的協議，尤其是在啓動時。因此，在那些具有充足內存，或者爲每個輸出端口都設有與該端口所連接鏈路的延遲－帶寬特性大約對應的緩衝容量 的網絡交換設備上，TCP可以發揮出更高的效率。
- 另外一種工作模式是擁塞避免。在這種模式下，TCP會在每個無丟包的往返時間間隔發送一段額外的數據。這種提升是附加的，而不是指數式的，會以每個RTT間隔增加一個衡定數據段的方式，提高發送端的傳輸速率。
圖 1 ： TCP行爲
緩慢啓動（在每個RTT間隔中將速率提升一倍）
隊列飽和點
在速率超過可用容量時開始排序
擁塞避免（在每個RTT間隔中以一個固定的幅度提升速率）
時間
但是，如果兩個位於大陸兩端的系統之間存在一條高速的路徑，會發生什麼情況？單個TCP會話需要多長時間才能達到10Gbps的傳輸速率？單個會話能否持續地以10Gbps的速率運行？
下面讓我們來看看這樣一個情況：網絡路徑從位於澳大利亞大陸東側的布里斯班延伸到位於西側的珀斯。網線實際上沿着澳大利亞大陸的南海岸鋪設，因此 RTT延遲爲70ms。這意味着每秒存在14.3個往返間隔。假定所使用的分組大小爲1500字節，即12000比特，而且TCP初始窗口的大小爲單個分 組。另外，假定布里斯班到珀斯的主機間瓶頸容量爲10Gbps。
在簡單的緩慢啓動模式下，發送速率每70ms提升一倍，因此在17個RTT間隔之後（期間發送速率每經過一個間隔就增加一倍），或者在大約1.2秒 鍾之後，傳輸速度就會達到11.2Gbps（假定這個主機擁有足夠快的硬件組件，足夠快的內部數據路徑，以及充足的內存）。在這個階段，假定發送速率超過 了網絡路徑的瓶頸點的緩衝容量。這時將會發生丟包，因爲網絡路徑中的緩衝已經達到了飽和。
在收到一個表示分組丟失的ACK序列時，TCP發送端的擁塞窗口將會減小一半，TCP發送速率也會降低一半，同時TCP將切換到擁塞避免模式。在擁 塞避免模式下，速率提升幅度爲每個RTT增加一個數據段，相當於每個RTT增加12kb；或者，根據上面設定的會話參數，就相當於每個RTT間速率增加 171kbps。那麼，TCP將需要多長時間來恢復正常，將發送速率增加到10Gbps呢？
那麼，我們的10Gbps連接怎麼樣呢？首先要估計的是交換組件中的可用緩衝容量。假定在隊列達到飽和之前，網絡路徑上的可用隊列容量爲 256MB，那麼工作在擁塞避免模式下的TCP會話將會在達到最高傳輸速率（即10Gbps）之後的大約590個RTT間隔（或者大約41秒之後）發生丟 包。這時，處於擁塞避免模式下的TCP的發送速率爲10.1Gbps。在實用情況下，TCP擁塞避免模式會在5.0Gbps到10.1Gbps之間，導致 這種理想的TCP會話產生鋸齒式振盪。單個鋸齒振盪週期長爲2062秒，即34分鐘22秒。這意味着網絡必須在幾十分鐘內（或者在傳輸數十億個分組期 間），在網絡路徑上穩定地保持無丟包運行，而且相應的傳輸比特錯誤率低於10-14。它還意味着這種方式能夠傳輸龐大的數據集，因爲在一個TCP擁塞避免 週期中傳輸的數據量高達1.95TB（即1.95×1012字節）。這也表明，TCP會話無法充分地利用可用的網絡帶寬，因爲在這些情況下的平均數據傳輸 速率爲7.55Gbps，而不是10Gbps（參見圖2）。
圖 2 ： 高速時的TCP行爲
TCP擁塞參數（RTT 700ms，1500 MSS，10Gbps，256Mb隊列）
速率（Gbps） 緩慢啓動（1.2s）
擁塞避免週期（34分鐘）
時間（小時）
顯然，在這種情況下會出現一些意外，因爲要用數據填滿一條遠程的、高容量的線路看起來肯定是一項困難的、漫長的任務，而且TCP無法發揮預期的作用。儘管尋找TCP的傳輸極限本身是一個有趣的研究領域，但是這種高速傳輸的確產生了很多實際的問題。
一個經常被人提及的、令人影響深刻的例子是CERN建造的大型強子對撞機。
“位於瑞士日內瓦的CERN粒子物理實驗室成功地在歐洲的七個國家和美國之間，連續十天以平均每秒600M字節的速度傳輸一個數據流。它是我們對在 CERN建設的大型強子對撞機進行的一項重要的計算基礎設施測試。LHC將成爲有史以來建設的、數據量最大的物理儀器，它會在10年或者更長的時間裏，每 秒鐘產生1500MB的數據。”
――
新科學人雜誌，
2005
年
4
月
30
日
TCP
和陸地速度記錄
TCP 陸地速度紀錄最初是一項爲了在IP網絡中實現破紀錄的TCP傳輸速度而開展的非正式項目。在20世紀80年代末和90年代初，人們取得了很多值得關注的裏 程碑式成果，特別是Van Jacobson曾經設法實現了持續的10Mbps和45Mbps TCP傳輸速度。
這個項目已經被加入到了Internet2計劃之中。該計劃爲TCP陸地速度的測試製定了一些正式的規則。特別需要指出的是，這些規則現在確定了時 間、距離和TCP限制，而且要求使用實際網絡。最近幾年這個紀錄被頻頻打破。截止到2006年5月，IPv4單數據流傳輸的最高紀錄是一個在長達3萬公里 的光纖路徑上，連續30分鐘保持7.21Gbps速率的TCP會話。
TCP的陸地速度紀錄表明，讓TCP在很高的速度下保持持續的間隔肯定是可能的，但是這裏必須要注意一些細節。要想創造一個新的紀錄，必須滿足一些前提條件：
- 首先，將所有網絡路徑歸您個人使用是相當必要的――實際上可以說是非常重要。任何形式的丟包都可能產生嚴重的影響，因此，確保不丟失任何分組的最佳途徑是讓整個網絡路徑完全歸您個人使用。
- 其次，保持固定的延時也是相當必要的――也可以說是非常重要。如果測試的目標是爲了達到穩定的數據傳輸狀態，那麼延遲的任何變化――特別是延遲的減少――都可能會導致在一段時間內發送過多的數據，這可能造成丟包的危險。因此，務必儘可能地保持網絡的穩定性。
- 第三，在底層傳輸介質中保持極低的比特錯誤率相當必要――這一點實際上也非常重要。數據受損會導致校驗和錯誤，進而造成丟包。
- 最後，必須提前獲知往返延時和可用帶寬。
接下來，您可以將這兩個數字（即RTT和帶寬）相乘，除以分組尺寸，向下舍入，再讓發送TCP會話將該值設爲緩衝尺寸，而接收端設置較大的緩衝值。之後，就可以啓動會話。
這樣做的目的是讓TCP在發送端用完緩衝空間之前使用緩慢啓動。一旦緩衝空間用完，只要發送端、接收端和網絡路徑全部處於穩定狀態，TCP將繼續保 持這種緩衝速度。對於使用70ms RTT的10Gbps系統而言，如果將緩衝極限設爲11.6萬個分組，那麼TCP會話將以9.94Gbps的速度運行。只要延時保持穩定（即沒有抖動）， 而且沒有比特錯誤和不存在其他的交叉流量，那麼在理論上這樣的發送速率將能夠無限地保持下去，並具有穩定的數據分組流和穩定的ACK分組流。
當然，這種情況會受到很多實際條件的限制。TCP協議面臨的實際問題是，它與很多其他的會話共享網絡路徑的方式和它佔據可用網絡容量的能力。換句話 說，人們希望看到的是一個高速、高容量的TCP版本，它應當能夠在網絡上與其他類型的流量共存。人們更希望，高速的TCP版本能夠在平等地與其他流量會話 共享網絡資源的同時，最大限度地利用網絡資源。TCP目前存在的問題是，在運行於高速的跨大陸級網絡路徑中時，它爲了恢復持續的運行操作而在定量遞增模式 （即擁塞避免模式）下花費了過長的時間。如果我們想要獲得高效率的超高速TCP，就需要設法改變TCP的高速運行方式。
高速
TCP
目前，可以通過兩種方法實現高速TCP：現有TCP的並行化，或者通過改變TCP特性，在單個TCP流中允許更快的加速速率。
利用並行TCP流提高TCP性能的方法已經存在了相當長的時間。例如，最初的HTTP規範允許使用並行的TCP會話下載網頁的各個部分（不過 HTTP 1.1改用了連續下載模式，因爲在這種情況下，會話啓動的開銷似乎超過了並行TCP會話所帶來的好處）。另外一種通過並行化實現高速文件傳輸的方法是網格 FTP（GRID FTP）。它的基本原理是將通信載荷分解爲大量獨立的部分，並同時發送所有這些部分。每個傳輸部分可以位於兩個終端之間（例如網格FTP），也可以分散在 多個終端之間（例如BitTorrent）。
但是，爲了讓並行TCP正確運行，我們需要事先彙總所有數據（或者至少知道所有數據部分所在的位置）。在實時產生大量數據的情況下（例如天文臺或者 粒子對撞機），只能將數據集視爲一個連續的數據流，並利用一個高速的傳輸協議來分發它。這時的任務將是調節TCP的基本控制算法，讓其不僅能夠以高速運 行，還能夠“公平地”在一個存在多種流量的高速網絡中運行。
並行
TCP
利用並行技術提高速度是一種常見的計算技術，並且存在於 很多超級計算機架構之中。它也可以用於數據傳輸，即將一個數據集劃分爲大量較小的數據塊，每個數據塊通過單獨的TCP會話發送。這時的基本機制是，在使用 一定數量（例如N個）並行TCP會話時，單個丟包事件很可能會導致N個會話中最快會話的速率降低一半，這是因爲最快的會話在網絡中傳輸的數據較多，因而最 有可能受到丟包事件的影響。該會話隨後將利用擁塞避免速率提升方法來進行恢復，這意味着單個丟包事件會導致發送速率最高降低1/(2N)。例如，在使用五 個並行會話時，單個丟包事件會導致總髮送速率降低1/(2×5)，即1/10；相比之下，在使用單個TCP會話時，單個丟包事件會將發送速率降低1/2。
圖3顯示了在一個10Gbps會話中模擬五個並行會話的情況。
圖 3 ： 並行TCP模擬：單個與多個數據流的對比
速率（Gbps） 並行數據流的總和
單個數據流
各個數據流
時間（小時）
彙總數據流的本質特徵是，在無丟包情況下，N個並行會話的數據流的速率提升速度會比處於擁塞避免模式的單個會話高N倍。對於孤立丟包事件的響應爲單 個數據流的速率降低一半，因此在理想條件下的總體數據流速率介於R和R×（2N-1）/2N之間，或者長期平均吞吐率爲R×（2N-1）/2N。對於理想 的10Gbps連接，可能會實際工作在9.9Gbps。
當然，實踐與理論存在偏差。人們已經對並行TCP在不同條件下的性能進行了大量的研究，嘗試採用最大限度提高吞吐率和選擇最有效的並行有效數據流數 量等手段進行優化。一部分問題在於，儘管簡單的模擬――例如用以生成圖4的模擬――可能會通過均分每個並行會話來獲得最大限度的吞吐率，但是各個會話很有 可能是自動同步的。因爲並行會話存在類似的窗口尺寸範圍，所以在某個特定的時間點，每個數據流在網絡路徑中發送的分組數可能會十分接近。如果丟包事件是一 個多包丟失事件，例如一個尾部丟棄隊列，那麼很有可能發生多個並行數據流同時丟包的情況，這樣數據流可能會變得同步。
圖4顯示了兩種極端情況――多個數據流完全均分和嚴格同步。同步的並行數據流的平均吞吐率與單個數據流在模擬期間的平均吞吐率相同，但是兩者都遠遠低於一組均分的並行數據流。
圖 4 ： 並行TCP的對比：同步和均分的數據流
速率（Gbps） 均分並行數據流的彙總
同步並行數據流的彙總 單個數據流
時間（小時）
解決這個問題的方法之一是重新將這些並行數據流彙集成一個受控的數據流，而且這個數據流具有與等分的並行數據流相同的特性。下一節將探討這種名爲MulTCP的方法。
如果上面這些對並行TCP流的討論有些偏理論化，似乎與今天的網絡缺乏聯繫，那麼有必要指出，很多互聯網服務供應商（ISP）目前都將 BitTorrent流量視爲他們的最高量應用。BitTorrent是一種點對點應用，利用一種高度並行的傳輸技術進行數據集的傳輸。在 BitTorrent中，原始的數據集會被分解爲多個數據塊，每個數據塊都能夠並行下載。它的獨特之處在於，各個會話並不需要具有相同的來源，而主機能夠 同時從多個不同的來源獲取“種子”，以及將其自身作爲它已經下載的數據塊的供應點。這種機制充分發揮了這些網絡在點對點方面的潛力，不僅能夠通過並行 TCP會話提高速度，還能夠藉助不同的數據路徑和數據源，避免單個路徑發生擁塞。考慮到BitTorrent在最大限度提高高量數據集傳輸速度方面的效 率，以及它在真正發掘點對點網絡潛力方面所取得的成功，以及人們對BitTorrent的廣泛接受和它的普及，BitTorrent可能很值得我們進行進 一步的研究，但是我們將在一篇單獨的文章中加以探討。
超高速串行
TCP
另外一種通用的方法是重新分析現有的TCP控制算 法，看看能否通過修改參數或者算法，讓TCP在這些高容量、長延遲的網絡路徑中獲得更高的速率。這樣做的目的是實現一種出色的擁塞處理算法，它不僅不會加 劇持續故障區域的暫時擁塞，而且還能夠支持高速的數據傳輸，從而有效地使用所有可用的網絡容量。
我們還希望TCP能夠在面臨其他TCP會話時採取適當的對策，從而平等地與其他TCP會話共享網絡資源。
MulTCP
第一種這樣的方法是MulTCP，即採用行爲類似於N個並行TCP會話的單個TCP數據 流。它通過均分虛擬會話，實現最優的吞吐率。它對TCP的實質改動體現在擁塞避免模式和丟包事件的處理方面。在擁塞避免模式下，MulTCP會以每個 RTT增加N個數據段的方式擴大擁塞窗口，而不是像缺省設置那樣只增加單個數據段。在發生丟包時，MulTCP會將它的窗口縮小W/(2N)，而不是缺省 的W/2。MulTCP採用的緩慢啓動模式也與缺省模式有所不同――它會在每收到一個ACK時爲窗口增加三個數據段，而不是缺省的兩個。
MulTCP只對TCP進行了簡單的改動，並沒有徹底地改變TCP的擁塞控制算法。當然，選擇最佳的N值時，對網絡特性 有所瞭解將會有所幫助。如果N值過高，MulTCP會話可能會佔據過高的網絡容量；但是如果該值過低，該會話可能就無法充分利用可用的網絡容量。圖5對比 了同等數量的並行TCP數據流和單個TCP數據流的速率（在這個模擬中，N=5）。
圖
5
：
MulTCP
MulTCP模擬（N=5）
速率（Gbps） MulTCP 單個TCP數據流
時間（小時）
儘管如此，我們仍然會覺得存在進一步改進的空間：最好不需要設置虛擬並行會話的數量；最好能在多種帶寬上，在與其他併發TCP會話競爭時支持公平的資源分配；最好能夠擁有豐富的擴展屬性。
目前在爲滿足這些需要而調節TCP的不同特性方面，存在着多種不同的手段――從修改TCP的速率控制機制，到將網絡負荷視爲功率譜問題。
高速
TCP
“針對大型擁塞窗口的高速TCP”[2]一文提出的另外一種方法是從TCP速率機制的角度解決這個問題。這種方法是由ICIR的Sally Floyd發明的。
當TCP以平均每個RTT傳輸W個分組的速度工作於擁塞避免模式時，每個RTT的分組數會在(2/3)W和(4/3)W之間波動。因爲每個週期包含 (2/3)W個RTT間隔，所以每個週期的分組數就爲(2/3)W2個分組。這個結果意味着只要丟包率爲每個週期丟失一個分組，那麼速率就能保持爲每個 RTT W個分組，即丟包率
。求解這個公式中的W，就能達到每個RTT的平均分組速率爲：
。因此，TCP的通用速率公式爲：
，其中MSS是TCP分組的尺寸。
對N個並行數據流採取同樣的速率公式，會得到什麼結果？理想的結果是，在丟包率相同的情況下，並行數據流的速度要快N倍；或者，用速率公式表示每個RTT的分組數WN，那麼可以得到：
，而每個TCP週期縮短爲一個值爲
的間隔。
但 是，用戶所需要的可能並不是將TCP的速率提升固定的倍數（N）――就像MulTCP所做的那樣，而是在丟包率下降時，通過提高N值自動地提高發送速率。 高速TCP的目的是利用一個TCP響應函數，保持發送速率的對數與丟包率的對數之間的固定關係，但是改變函數的斜率，以便讓TCP能夠在丟包率下降時提高 它的擁塞避免增量。圖6顯示了這種關係，它對比了發送速率的對數和丟包率的對數。MulTCP在發送速率的對數和丟包率的對數之間保持了相同的關係，但是 改變了函數的截距；不過，丟包率指數值的變化會在速率等式中產生不同的斜率。
圖 6 ： TCP響應函數
發送速率，每秒分組數
高速TCP
丟包率 高速TCP方案的工作機理類似於引擎中的渦輪增壓器；引擎的運轉速度越快，渦輪增壓器對引擎正常性能的提升幅度越高。在某個特定的閾值以下，TCP擁塞避 免函數不會發生變化。但是當丟包率降低到某個特定閾值以下時，就會調用速度更快的擁塞避免算法。高速TCP方案所提出的高速數據等式建立在以下基礎上：以 1000萬個分組丟失一個分組的丟包率，在100ms延遲路徑上實現10Gbps的傳輸速率。通過這些參數逆推，可以得到W（即每個RTT間隔的分組數） 的速率等式：
，其效果近似等於一個並行會話數量（N）隨着TCP速率提升而增加的MulTCP會話。二分提升擁塞控制（BIC）[4]採用了一種獨特的方法，即假定TCP在主動搜索一個處於丟包觸發閾值上的分組發送速率，再利用一個二分搜索算法有效地達到這個速率。
在BIC因爲發生丟包事件而縮小窗口時，它會遵循以前的最大窗口尺寸和當前的窗口設置。在每個無丟包RTT週期中， BIC都會試圖用當前窗口尺寸和過去最大窗口尺寸之間差額的一半，擴充擁塞窗口。通過這種方式，BIC能夠迅速地從此前縮小的窗口尺寸進行恢復。當BIC 接近原先的最大值時，它會減慢窗口擴充速度，在每個RTT中將窗口擴充速率降低一半。這個過程並不像聽起來那樣劇烈，因爲BIC還採用了一個最大擴充常數 來限制速率在任何一個RTT間隔中的變化幅度。這樣做的結果是，最終的響應兼具線性和非線性特徵，即在窗口縮小之後進行的初步窗口擴充是線性增長；但是當 窗口尺寸達到此前發生丟包時的尺寸時，窗口擴充速率就會減緩。在當前窗口尺寸超過以前發生丟包時的尺寸時，BIC會利用補充的方法擴充窗口。起初，窗口擴 充幅度較小，窗口擴充幅度值會在每個RTT中增加一倍，達到一個限值；在超過該限值時，窗口擴充將更加線性化。
在低RTT網絡和低速環境中，BIC可能會過於“積極”，因而人們對BIC進行了進一步的改進，即CUBIC[5]。 CUBIC採用了一個三次多項式函數來支配窗口擴充算法，而不是像BIC那樣使用指數函數。三次函數中將從上次縮小窗口以來經過的時間作爲變量，而不是像 BIC那樣使用一個RTT計數器，這樣CUBIC能夠在存在多個具有不同RTT的數據流時產生更加公平的結果。CUBIC還會爲任何一個RTT間隔中可以 進行的窗口調節幅度設置一個上限，這樣在窗口縮小之後進行的窗口尺寸調整將是線性的。在這裏，新的窗口尺寸W的計算方法爲：
。其中，C是一個恆定擴展參數，t是從上次窗口縮小事件到當前經過的時間；Wmax
表示最近一次縮小前的窗口尺寸。K的計算公式爲：
。當窗口尺寸接近過去的窗口尺寸Wmax
時，這個函數會變得更加穩定。在調整窗口尺寸時使用時間間隔而不是RTT計數器的目的是讓CUBIC對當前TCP會話更加敏感，特別是在RTT較短的環境中。
圖9對比了在相同時間內BIC和CUBIC的調整幅度。這兩種算法之間的實質區別在圖中表現得非常明顯：CUBIC算法在接近過去發生丟包事件的值時，試圖減小窗口尺寸的變化幅度。
圖 9 ： BIC和CUBIC的窗口調節幅度
窗口尺寸 時間
Westwood
TCP操作的“穩定狀態”模式的一個重要特徵是速率振盪的“鋸齒”模式。加法遞增方法的目的是在尋找可行的發送速率的同時，避免因爲過快地提高發送速率而導致暫時擁塞事件。TCP在發生丟包事件時採用的倍數遞減方法則可以避免在發送路徑上發生網絡擁塞。
BIC和CUBIC的調整手段都集中於速率提升函數，試圖在TCP會話收斂到某個長期可用的發送速率的過程中提供更高的穩定性。另外一個手段是改進倍數遞減函數，研究能否讓TCP會話利用進一步的信息修改速率遞減函數。
Westwood[6]所採取的方法和一種相應的改進方法Westwood+[7]則試圖在發生丟包事件（表現爲三個重 復的ACK）時，將TCP的擁塞窗口減小一半。通過觀察發現，返回的ACK分組流實際上表明瞭網絡路徑的當前瓶頸容量。這個結論可以改進傳統TCP算法對 擁塞窗口減小一半的方法，並且不斷地調整網絡路徑中的最小RTT。Westwood算法會通過跟蹤TCP確認值和ACK分組到達時間間隔，估計網絡帶寬， 進而估計當前網絡路徑的瓶頸帶寬。這種技術類似於“分組對”方法，在TCP Vegas中得到了應用。就Westwood方法而言，對帶寬的估計建立在接收ACK速率的基礎上，可以被用於設置擁塞窗口，而不是TCP發送窗口。 Westwood發送端會跟蹤最小的RTT間隔，以及根據返回的ACK數據流預測出的帶寬。在發生丟包事件時，Westwood不會將擁塞窗口縮減一半， 而是會將其設爲估計帶寬與最低RTT值的乘積。
如果當前RTT等於最小RTT，那麼就意味着整個網絡路徑上不存在隊列延遲，因而發送速率就會被設置爲網絡路徑的帶寬。如果當前RTT大於最小RTT，那麼發送速率就會被設置爲一個低於估計帶寬的值，並允許在發生丟包時通過加法遞增尋找發送速率閾值。
這裏存在的一個重要問題是，ACK間隔時間可能會發生變化，但是Westwood會利用所有可用的數據和ACK對提高對 當前帶寬的預測精度。該方法還採用了一個低通濾波器，確保估計帶寬在一段時間內保持相對的穩定性。實際的結果是，接收端可能會發生某種形式的ACK失真 （例如延遲的ACK響應），而網絡路徑會在正向和反向含有抖動組件，這樣ACK隊列在抵達發送端時，ACK間隔時間存在較大的波動。Westwood+利 用最低測量間隔（選取RTT或者50毫秒之間的較大者）進一步改進了這項技術，以解決因爲ACK壓縮而導致估計帶寬過高的問題。
這樣做的目的是確保TCP在縮小擁塞窗口時不會矯枉過正，從而使得與窗口的緩衝擴充速率有關的問題不會影響總體的TCP 性能。這裏的關鍵在於過濾技術，即獲取一個存在噪聲的測量樣本序列，先後用一個抗鋸齒濾波器和一個低通離散時間濾波器對該數據流進行濾波，從而得到足夠精 確的帶寬估計值。這個估計值可以與最小RTT測量值結合，在檢測到丟包和對數據流進行快速重發時，設置TCP擁塞窗口尺寸的下限。如果丟包是由網絡擁塞導 致的，那麼新的設置將低於帶寬閾值（按照比例RTTmin/RTTcurrent縮小），以便新的發送速率可以清理在路徑上排序的累積流量。如果丟包是因 爲介質受損而引起的，那麼RTT值將接近最小RTT值。在這種情況下，TCP會話速率的降低幅度就會較小，以便迅速地恢復到以前的數據速率。
但是，這種方法在頻繁發生比特級損壞的環境中（例如經常連接無線系統）具有重要的作用。它還適用於長延遲的、高速的 TCP環境。TCP Westwood的速率降低幅度取決於RTTmin/RTTcurrent比例，而不是像傳統TCP那樣直接降低一半，或者像MulTCP那樣採用一個固 定的比例，這使得TCP會話可以使其發送速率達到更加接近可實現帶寬的水平，而不是針對每個丟包事件進行影響相對較大的速率降低操作。
H-TCP
H-TCP[9]支持者們發現，通過調整TCP行爲，縮短擁塞事 件之間的時間間隔，能夠提高TCP在高速網絡上的性能。擁塞事件標誌着TCP已經用完了它的可用帶寬。通過提高這些事件的頻率，TCP將能夠更加準確地跟 蹤這個資源指標。爲了實現這種跟蹤，H-TCP的支持者認爲窗口擴充和縮小函數都可以進行修改，但是在決定以何種方式修改這些函數方面，他們認爲關鍵在於 對其他併發網絡數據流的敏感程度，以及向不同的併發數據流穩定分配資源的能力。
“雖然這些改動看起來比較簡單，但是實踐表明，它們往往會對TCP數據流的網絡行爲產生不利的影響。高速TCP和BIC -TCP會在網絡擾動――例如啓動新的數據流――之後表現出極低的收斂速度；可擴展TCP採取了一種倍數遞增、倍數遞減的策略，因此它在尾部丟棄網絡中無 法進行公平的收斂。”
正在開展的工作：draft-leith-tcp-htcp-01.txt
H-TCP主張對窗口控制函數進行最低限度的改動。它認爲，爲了實現公平性，具有較大擁塞窗口的數據流縮減窗口的絕對幅度應當大於窗口較小的數據流，從而在已經建立的TCP數據流和進入同一條網絡路徑的新數據流之間建立起動態的平衡。
H-TCP爲窗口擴充提出了一種基於計時器的響應函數，即在初期保持現有值（即每個RTT遞增一個數據段），但是之後，擴充函數將變爲一個二次多項式函數，將從最近一次擁塞事件到當前的時間作爲變量。其中，每個RTT間隔的窗口增量的計算公式爲：
，其中T表示從最近一次丟包事件到當前的時間。這個公式可以利用當前窗口縮減係數
進行進一步的改進，即：
。
窗口縮減倍數
建立在RTT間隔的變化幅度的基礎上。如果RTT的變化幅度不超過20%，那麼
的值就被設爲上個擁塞週期的RTTmin/RTTmax，否則
設爲1/2。
H-TCP在TCP的改進方面又向前邁進了一步。它採用了高速TCP的自適應窗口擴充函數，像可擴展TCP那樣將經過的時間作爲一個控制參數，並將RTT比例作爲修改窗口縮減值的基礎（這種做法與Westwood類似）。
FAST
FAST[10]是實現高速TCP的另外一種方法。FAST的作用可以通過比較不同高速TCP方法的每分組響應得到充分的體現，如下面的控制和響應表所示：
|
類型 |
控制方法 |
觸發器 |
響應 |
|
TCP |
AIMD(1,0.5) |
ACK 響應 |
W = W + 1/W |
|
MulTCP |
AIMD(N,1/2N) |
ACK 響應 |
W = W + N/W |
|
高速TCP |
AIMD(a(w), b(w)) |
ACK 響應 |
W = W + a(W)/W |
|
可擴展 TCP |
MIMD(1/100, 1/8) |
ACK 響應 |
W = W + 1/100 |
|
FAST |
RTT 波動 |
RTT |
W = W × (基本 RTT/RTT) + |
所有這些方法都具有相同的窗口調整結構，其中發送端的窗口根據一個控制函數和數據流增益進行調節。TCP、 MulTCP、高速TCP、可擴展TCP、BIC、CUBIC、WestWood和H-TCP都採用了基於ACK時鐘和丟包觸發器的擁塞處理措施。在這些 模式下發生的情況是，網絡路徑的瓶頸點達到了一定程度的飽和，使得瓶頸隊列排滿和發生丟包。值得一提的是，在丟包之前建立隊列會對RTT產生不利的影響。
這種情況使得FAST得出了這樣的判斷：另外一種擁塞信令方法可以建立在RTT波動或者累計隊列延遲波動的基礎上。FAST建立在後一種擁塞信令方法的基礎上。
FAST試圖在調整窗口的基礎上，在穩定分組流的同時保持隊列延遲的穩定，從而保持發送速率的穩定。這樣，RTT間隔也 可以保持穩定。窗口響應函數建立在按照當前RTT與平均RTT測量值的偏差，調節窗口尺寸的基礎上。如果當前RTT低於平均值，那麼窗口尺寸就會增大；如 果當前RTT高於平均值，窗口尺寸就會減小。窗口調整幅度通過將兩數值之差乘以一定係數得到，這將使得FAST以指數方式收斂到基本的RTT數據流狀態。 相比之下，傳統TCP不存在收斂狀態，而是會在發生丟包的速率和某個較低速率之間保持振盪（參見圖10）。
圖 10 ： TCP的響應函數和FAST
隊列延遲 TCP速率振盪 丟包
延遲
窗口尺寸
FAST會記錄一個指數加權平均RTT測試值，並根據當前RTT測量值與加權平均RTT測量值的差值，按比例地調節窗口尺寸。與其他TCP方法相比，FAST的模擬圖較難獲得。我們已經從一些使用FAST的實驗中獲得了具有指導意義的資料。
XCP――
端到端和網絡擴展
借 助網絡路徑上的路由器，還可以爲分組標記與當前擁塞等級相關的信令信息。這種方法最初以ECN（即明確擁塞通知）的概念提出，現在已經發展成爲一種名爲 XCP的傳輸流控制協議[11]。通過路由器根據相對可持續負荷等級提供的明確信號，可以得到與網絡負荷相關的反饋信息。有趣的是，這種方式不同於TCP 的原始設計方法，即TCP信令是有效地通過與最終系統交換一個心跳信號而建立的，而TCP流控制流程則是通過分析這個心跳信號因爲網絡環境而發生的變化進 行。
XCP促成了一種新的設計方法，即網絡交換組件可以通過有效地向終端系統通報網絡路徑上的當前可用容量，在端到端流控制 中扮演一個重要的角色。這種方式使得終端系統能夠通過將分組速率提升到路徑中的路由表宣佈沒有任何可用容量時的水平，迅速地響應可用容量；或者在路徑中的 路由表宣佈發生暫時擁塞時，降低發送速率。
但是，至於這種利用明確的路由－終端主機信號的方法能否有效地實現高速的傳輸協議，目前還沒有一個明確的結論。
下一步
現在我們面臨的基本問題是，我們是否對基於窗口的TCP擁塞控制協議進行了某種最根本的限制，或者基於窗口的控制系統能否在這些速度和距離上繼續保持效用，而且這種控制信令將會繼續適應這種環境中不斷擴大的速度範圍。
FAST所使用的、基於速率的調整幅度肯定有助於解決尋求“安全的”窗口擴充和縮減幅度的問題，但是在是否有必要使用一 個窗口擴充和縮減算法，或者是否應當轉向其他方向（例如速率控制，RTT穩定性控制，或者在高速控制環中加入網絡生成的其他信息）方面，目前還沒有肯定的 答案。基於路由器的明確信令（如XCP所採用的方法）可以對TCP會話進行相當準確的控制，但是它不具備在任何現有網絡上部署控制系統的適應能力。
但是，對於所有這些方法，基本的TCP目標仍然是一樣的：我們需要的是一個能夠儘可能有效地――快速地――利用可用網絡容量的傳輸協議，最大限度地減少重發次數和提高有效的數據吞吐率。
我們還需要一種能夠適應其他網絡用戶要求，與其他應用平等分配網絡資源的協議。
到目前爲止，我們研究的所有方法都是針對實際應用所做的某種形式的妥協。在試圖優化即時傳輸速率時，擁塞控制算法可能無 法響應同一條路徑上同時發生的其他傳輸會話。或者，在試圖加強與其他併發會話的公平關係時，控制算法可能會無法響應可用的網絡路徑容量。控制算法可能會無 法響應會話期間因爲網絡路徑的路由變化而產生的RTT動態變化。至於在一個混合性的網絡環境中，哪些TCP性能指標最爲重要，我們還沒有從這些不同領域的 研究工作中得到一個明確的共識。
但是，我們已經瞭解到了很多關於TCP的信息。在此基礎上，我們可以考慮TCP在這個超高速時代的發展方向時，制定出幾個設計原則：
- 第一個原則是，TCP在保持總體網絡性能和確保各方的公平性方面相當有效，因爲每個人使用的都是某種形式的 TCP，它們都具有類似的響應特性。如果我們全部都選擇在我們的TCP協議中使用截然不同的控制方式，那麼我們的網絡很可能會陷入混亂之中，網絡可能會產 生嚴重的過載和極低的使用效率。
- 第二個原則是，傳輸協議並不需要解決介質等級或者應用問題。最通用的傳輸協議不應當依賴於特定介質的特徵，而是應當使用來自於協議堆棧較低層的響應，正確地發揮傳輸系統的作用。
- 第三個關於TCP的原則是，傳輸協議可以保持出色的一致性，在原先設計時沒有考慮的環境中使用。這樣，任何方案都應當審慎地進行設計，以便允許各種不同的使用條件。
- 最後一個原則是，傳輸協議需要在競爭中保持公平的健壯性。協議能否在面臨其他併發傳輸流對資源的要求時，平等地分享低層網絡資源？
在所有這些結論中，第一個原則是最重要的，也可能是最難以付諸實踐的。互聯網之所以能夠像今天這樣正常工作，是因爲我們都使用了相同的傳輸控制協 議。如果我們希望爲了在增加延遲的同時實現高速的數據傳輸而對該控制協議進行一些改進，那麼就有必要考慮，是否存在一種讓我們都能使用的、統一的控制結構 和協議。
因此，爲在高速互聯網中實現高速傳輸選擇一種統一的方法可能是整個改進計劃中最關鍵的一環。雖然我們能夠在一個千兆網絡上，支持一組使用不同控制方 法的、速率爲每秒數Mb的分組流，但是如果在同一個千兆網絡上使用各種不同類型的、速率爲每秒數Gb的分組流，可能會產生非常嚴重的混亂和破壞。如果我們 不能在如何選擇統一的高速TCP控制算法方面取得共識，那麼所有這些方法可能都無法在高度多樣化的、高速的網絡環境中有效地發揮作用。
致謝
Larry Dunn耐心地、反覆地閱讀了本文，糾正了一些文字錯誤，並對我的一些不夠嚴謹的論斷提出了質疑。在此致以我誠摯的謝意。
但是，無論本文中存在什麼錯誤，無疑都是我個人的責任。
深入閱讀
圍繞這個問題，目前有很多可供閱讀的資料。您可以通過任 何一個正式的搜索引擎找到這些資料。但是，如果您對這個問題很感興趣，而且希望找到一個以非常詳細的、有組織的方式探討這一問題的文獻，我願意向您推薦下 面這兩個資料來源。您可以藉助它們研究這個問題，瞭解這個領域目前的發展狀況：
- “HighSpeed TCP for Large Congestion Windows,” S. Floyd, RFC 3649, December 2003.
Floyd在文中深入、全面、準確地探討了這個問題。希望所有的RFC都能達到這樣的寫作質量。
- 關於適用於快速遠程網絡的協議的研討會文集
這些研討會的網址分別是：
2003:http://datatag.web.cern.ch/datatag/pfldnet2003/
2004:http://www-didc.lbl.gov/PFLDnet2004/program.htm
2005: http://www.ens-lyon.fr/LIP/RESO/pfldnet2005/
參考文獻
[1] “Differentiated End-to-End Internet Services Using a Weighted Proportional Fair Sharing TCP,” J. Crowroft and P. Oechcslin, ACM SIGCOMM Computer Communication Review, Volume 28, No. 3, pp. 53–69, July 1998.
[2] “HighSpeed TCP for Large Congestion Windows,” S. Floyd, RFC 3649, December 2003.
[3] “Scalable TCP: Improving Performance in High-Speed Wide Area Networks,” T. Kelly, ACM SIGCOMM Computer Communication Review, Volume 33, No. 2, pp. 83–91, April 2003.
[4] “Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks,” L. Xu, K. Harfoush, and I. Rhee, Proceedings of IEEE INFOCOMM 2004, March 2004.
[5] “CUBIC: A New TCP-Friendly High-Speed TCP Variant,” I. Rhee, L. Xu, http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ cubic-paper.pdf, February 2005.
[6] “TCP Westwood: Congestion Window Control Using Bandwidth Estimation,” M. Gerla, M. Y. Sanadidi, R. Wang, A. Zanella, C. Casetti, and S. Mascolo, Proceedings of IEEE Globecom 2001, Volume 3, pp. 1698–1702, November 2001.
[7] “Linux 2.4 Implementation of Westwood+ TCP with Rate- Halving: A Performance Evaluation over the Internet,” A. Dell’Aera, L. A. Greco, and S. Mascolo, Tech. Rep. No. 08/03/S, Politecnico di Bari, http://deecal03.poliba.it/mascolo/ tcp%20westwood/Tech_Rep_08_03_S.pdf
[8] “End-to-end Internet packet dynamics,” V. Paxson, Proceedings of ACM SIGCOMM 97, pp. 139–152, 1997.
[9] “H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths,” D. Leith, R. Shorten, Work in Progress, June 2005. Internet Draft: draft-leith-tcp-htcp-00.txt
[10] “FAST TCP: Motivation, Architecture, Algorithms, Performance,” C. Jin, X. Wei, and S. H. Low, Proceedings of IEEE INFOCOM 2004, March 2004.
[11] “Congestion Control for High Bandwidth-Delay Product Networks,” D. Katabi, M. Handley, and C. Rohrs, ACM SIGCOMM Computer Communication Review, Volume 32, No. 4, pp. 89–102, October 2002.
[12] “TCP Performance,” Geoff Huston, The Internet Protocol Journal, Volume 3, No. 2, June 2000.
[13] “The Future for TCP,” Geoff Huston, The Internet Protocol Journal, Volume 3, No. 3, September 2000.
Geoff Huston在澳大利亞國立大學獲得了學士和碩士學位。近二十年來，他廣泛地參與了互聯網的發展工作，特別是在澳大利亞，他負責澳大利亞學術和科研網絡的 前期建設工作，並曾經在Telstra的互聯網部門擔任首席科學家。Geoff目前是亞太地區網絡信息中心（APNIC）的互聯網研究科學家。他是互聯網 架構委員會的成員，目前還擔任着IETF中的三個工作組的聯合主席。他曾撰寫多本與互聯網有關的書籍。他的電子郵件地址爲：[email protected] 。