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