【摘要】對多種TCP擁塞控制演算法進行簡要說明，指出它們的優缺點、以及它們的適用環境。

【關鍵字】TCP擁塞控制演算法 優點    缺點   適用環境公平性

公平性

公平性是在發生擁塞時各源端（或同一源端建立的不同TCP連線或UDP資料報）能公平地共享同一網路資源（如頻寬、快取等）。處於相同級別的源端應該得到相同數量的網路資源。產生公平性的根本原因在於擁塞發生必然導致資料包丟失，而資料包丟失會導致各資料流之間為爭搶有限的網路資源發生競爭，爭搶能力弱的資料流將受到更多損害。因此，沒有擁塞，也就沒有公平性問題。

TCP層上的公平性問題表現在兩方面：

(1) 面向連線的TCP和無連線的UDP在擁塞發生時對擁塞指示的不同反應和處理，導致對網路資源的不公平使用問題。在擁塞發生時，有擁塞控制反應機制的TCP資料流會按擁塞控制步驟進入擁塞避免階段，從而主動減小發送入網路的資料量。但對無連線的資料報UDP，由於沒有端到端的擁塞控制機制，即使網路發出了擁塞指示（如資料包丟失、收到重複ACK等），UDP也不會像TCP那樣減少向網路傳送的資料量。結果遵守擁塞控制的TCP資料流得到的網路資源越來越少，沒有擁塞控制的UDP則會得到越來越多的網路資源，這就導致了網路資源在各源端分配的嚴重不公平。

網路資源分配的不公平反過來會加重擁塞，甚至可能導致擁塞崩潰。因此如何判斷在擁塞發生時各個資料流是否嚴格遵守TCP擁塞控制，以及如何“懲罰”不遵守擁塞控制協議的行為，成了目前研究擁塞控制的一個熱點。在傳輸層解決擁塞控制的公平性問題的根本方法是全面使用端到端的擁塞控制機制。

(2) 一些TCP連線之間也存在公平性問題。產生問題的原因在於一些TCP在擁塞前使用了大視窗尺寸，或者它們的RTT較小，或者資料包比其他TCP大，這樣它們也會多佔頻寬。

RTT不公平性

AIMD擁塞視窗更新策略也存在一些缺陷，和式增加策略使傳送方傳送資料流的擁塞視窗在一個往返時延(RTT)內增加了一個數據包的大小，因此，當不同的資料流對網路瓶頸頻寬進行競爭時，具有較小RTT的TCP資料流的擁塞視窗增加速率將會快於具有大RTT的TCP資料流，從而將會佔有更多的網路頻寬資源。

附加說明

中美之間的線路質量不是很好，rtt較長且時常丟包。TCP協議是成也丟包，敗也丟包；TCP的設計目的是解決不可靠線路上可靠傳輸的問題，即為了解決丟包，但丟包卻使TCP傳輸速度大幅下降。HTTP協議在傳輸層使用的是TCP協議，所以網頁下載的速度就取決於TCP單執行緒下載的速度（因為網頁就是單執行緒下載的）。
丟包使得TCP傳輸速度大幅下降的主要原因是丟包重傳機制，控制這一機制的就是TCP擁塞控制演算法。
Linux核心中提供了若干套TCP擁塞控制演算法，已載入進核心的可以通過核心引數net.ipv4.tcp_available_congestion_control看到。

1. Vegas

1994年，Brakmo提出了一種新的擁塞控制機制TCP Vegas，從另外的一個角度來進行擁塞控制。從前面可以看到，TCP的擁塞控制是基於丟包的，一旦出現丟包，於是調整擁塞視窗，然而由於丟包不一定是由於網路進入了擁塞，但是由於RTT值與網路執行情況有比較密切的關係，於是TCP Vegas利用RTT值的改變來判斷網路是否擁塞，從而調整擁塞控制視窗。如果發現RTT在增大，Vegas就認為網路正在發生擁塞，於是開始減小擁塞視窗，如果RTT變小，Vegas認為網路擁塞正在逐步解除，於是再次增加擁塞視窗。由於Vegas不是利用丟包來判斷網路可用頻寬，而是利用RTT變化來判斷，因而可以更精確的探測網路的可用頻寬，從而效率更好。然而Vegas的有一個缺陷，並且可以說致命的，最終影響TCP Vegas並沒有在網際網路上大規模使用。這個問題就是採用TCP Vegas的流的頻寬競爭力不及未使用TCP Vegas的流，這是因為網路中路由器只要緩衝了資料，就會造成RTT的變大，如果緩衝區沒有溢位的話，並不會發生擁塞，但是由於快取資料就會導致處理時延，從而RTT變大，特別是在頻寬比較小的網路上，只要一開始傳輸資料，RTT就會急劇增大，這個在無線網路上特別明顯。在這種情況下，TCP Vegas降低自己的擁塞視窗，但是隻要沒有丟包的話，從上面看到標準的TCP是不會降低自己的視窗的，於是兩者開始不公平，再這樣迴圈下去，TCP Vegas的效率就非常低了。其實如果所有的TCP都採用Vegas擁塞控制方式的話，流之間的公平性會更好，競爭能力並不是Vegas演算法本身的問題。

適用環境：很難在網際網路上大規模適用（頻寬競爭力低）

2. Reno

Reno是目前應用最廣泛且較為成熟的演算法。該演算法所包含的慢啟動、擁塞避免和快速重傳、快速恢復機制，是現有的眾多演算法的基礎。從Reno執行機制中很容易看出，為了維持一個動態平衡，必須週期性地產生一定量的丟失，再加上AIMD機制--減少快，增長慢，尤其是在大視窗環境下，由於一個數據報的丟失所帶來的視窗縮小要花費很長的時間來恢復，這樣，頻寬利用率不可能很高且隨著網路的鏈路頻寬不斷提升，這種弊端將越來越明顯。公平性方面，根據統計資料，Reno的公平性還是得到了相當的肯定，它能夠在較大的網路範圍內理想地維持公平性原則。

Reno演算法以其簡單、有效和魯棒性成為主流，被廣泛的採用。

但是它不能有效的處理多個分組從同一個資料視窗丟失的情況。這一問題在New Reno演算法中得到解決。

基於丟包反饋的協議

近幾年來，隨著高頻寬延時網路（High Bandwidth-Delay product network）的普及，針對提高TCP頻寬利用率這一點上，又湧現出許多新的基於丟包反饋的TCP協議改進，這其中包括HSTCP、STCP、BIC-TCP、CUBIC和H-TCP。

總的來說，基於丟包反饋的協議是一種被動式的擁塞控制機制，其依據網路中的丟包事件來做網路擁塞判斷。即便網路中的負載很高時，只要沒有產生擁塞丟包，協議就不會主動降低自己的傳送速度。這種協議可以最大程度的利用網路剩餘頻寬，提高吞吐量。然而，由於基於丟包反饋協議在網路近飽和狀態下所表現出來的侵略性，一方面大大提高了網路的頻寬利用率；但另一方面，對於基於丟包反饋的擁塞控制協議來說，大大提高網路利用率同時意味著下一次擁塞丟包事件為期不遠了，所以這些協議在提高網路頻寬利用率的同時也間接加大了網路的丟包率，造成整個網路的抖動性加劇。

友好性

BIC-TCP、HSTCP、STCP等基於丟包反饋的協議在大大提高了自身吞吐率的同時，也嚴重影響了Reno流的吞吐率。基於丟包反饋的協議產生如此低劣的TCP友好性的組要原因在於這些協議演算法本身的侵略性擁塞視窗管理機制，這些協議通常認為網路只要沒有產生丟包就一定存在多餘的頻寬，從而不斷提高自己的傳送速率。其傳送速率從時間的巨集觀角度上來看呈現出一種凹形的發展趨勢，越接近網路頻寬的峰值傳送速率增長得越快。這不僅帶來了大量擁塞丟包，同時也惡意吞併了網路中其它共存流的頻寬資源，造成整個網路的公平性下降。

3. HSTCP(High Speed TCP)

HSTCP(高速傳輸控制協議)是高速網路中基於AIMD(加性增長和乘性減少)的一種新的擁塞控制演算法,它能在高速度和大時延的網路中更有效地提高網路的吞吐率。它通過對標準TCP擁塞避免演算法的增加和減少引數進行修改，從而實現了視窗的快速增長和慢速減少，使得視窗保持在一個足夠大的範圍，以充分利用頻寬，它在高速網路中能夠獲得比TCP Reno高得多的頻寬，但是它存在很嚴重的RTT不公平性。公平性指共享同一網路瓶頸的多個流之間佔有的網路資源相等。

TCP傳送端通過網路所期望的丟包率來動態調整HSTCP擁塞視窗的增量函式。

擁塞避免時的視窗增長方式： cwnd = cwnd + a(cwnd) / cwnd

丟包後窗口下降方式：cwnd = (1-b(cwnd))*cwnd

其中，a(cwnd)和b(cwnd)為兩個函式，在標準TCP中，a(cwnd)=1，b(cwnd)=0.5，為了達到TCP的友好性，在視窗較低的情況下，也就是說在非BDP的網路環境下，HSTCP採用的是和標準TCP相同的a和b來保證兩者之間的友好性。當視窗較大時（臨界值LowWindow=38），採取新的a和b來達到高吞吐的要求。具體可以看RFC3649文件。

4. westwood

無線網路中，在大量研究的基礎上發現tcpwestwood是一種較理想的演算法，它的主要思想是通過在傳送端持續不斷的檢測ack的到達速率來進行頻寬估計，當擁塞發生時用頻寬估計值來調整擁塞視窗和慢啟動閾值，採用aiad(additive increase and adaptive decrease)擁塞控制機制。它不僅提高了無線網路的吞吐量,而且具有良好的公平性和與現行網路的互操作性。存在的問題是不能很好的區分傳輸過程中的擁塞丟包和無線丟包，導致擁塞機制頻繁呼叫。

5. H-TCP

高效能網路中綜合表現比較優秀的演算法是：h-tcp，但它有rtt不公平性和低頻寬不友好性等問題。

6. BIC-TCP

BIC-TCP的缺點：首先就是搶佔性較強，BIC-TCP的增長函式在小鏈路頻寬時延短的情況下比起標準的TCP來搶佔性強，它在探測階段相當於是重新啟動一個慢啟動演算法，而TCP在處於穩定後窗口就是一直是線性增長的，不會再次執行慢啟動的過程。其次，BIC-TCP的的視窗控制階段分為binary search increase、max probing，然後還有Smax和Smin的區分，這幾個值增加了演算法上的實現難度，同時也對協議效能的分析模型增加了複雜度。在低RTT網路 和低速環境中，BIC可能會過於“積極”，因而人們對BIC進行了進一步的改進，即CUBIC。是Linux在採用CUBIC之前的預設演算法。

7. CUBIC

CUBIC在設計上簡化了BIC-TCP的視窗調整演算法，在BIC-TCP的視窗調整中會出現一個凹和凸(這裡的凹和凸指的是數學意義上的凹和凸，凹函式/凸函式)的增長曲線，CUBIC使用了一個三次函式(即一個立方函式)，在三次函式曲線中同樣存在一個凹和凸的部分，該曲線形狀和BIC-TCP的曲線圖十分相似，於是該部分取代BIC-TCP的增長曲線。另外，CUBIC中最關鍵的點在於它的視窗增長函式僅僅取決於連續的兩次擁塞事件的時間間隔值，從而視窗增長完全獨立於網路的時延RTT，之前講述過的HSTCP存在嚴重的RTT不公平性，而CUBIC的RTT獨立性質使得CUBIC能夠在多條共享瓶頸鍊路的TCP連線之間保持良好的RTT公平性。

CUBIC is a congestion control protocol for TCP (transmission control protocol) and thecurrent default TCP algorithm in Linux. The protocol modifies the linear window growth function of existing TCP standards to be a cubic function in order to improve the scalability of TCP over fast and long distance networks. It also achieves more equitable bandwidth allocations among flows with different RTTs (round trip times) by making the window growth to be independent of RTT – thus those flows grow their congestion window at the same rate. During steady state, CUBIC increases the window size aggressively when the window is far from the saturation point, and the slowly when it is close to the saturation point.This feature allows CUBIC to be very scalable when the bandwidth and delay product of the network is large, and at the same time, be highly stable and also fair to standard TCP flows.

8. STCP

STCP，Scalable tcp。

STCP演算法是由 Tom Kelly於 2003年提出的 ,通過修改 TCP的視窗增加和減少引數來調整發送視窗大小 ,以適應高速網路的環境。該演算法具有很高的鏈路利用率和穩定性，但該機制視窗增加和 RTT成反比 ,在一定的程度上存在著 RTT不公平現象 ,而且和傳統 TCP流共存時 ,過分佔用頻寬 ,其 TCP友好性也較差。