1988年Van Jacobson指出了TCP在控制網路擁塞方面的不足，並提出了“慢啟動”（Slow Start）、“擁塞避免”（Congestion Avoidance）的演算法。1990年出現的TCP Reno版本增加了“快速重傳 ”（Fast Retransmit）、“快速恢復”（Fast Recovery）演算法，避免了網路擁塞不嚴重時採用“慢啟動”演算法而造成過大的減小發送視窗尺寸的現象。這樣TCP的擁塞控制就由這4個核心部分組成。最近幾年又出現了TCP的改進版本，如New-Reno、SACK等。

主要引數

TCP擁塞控制是通過控制一些重要引數的改變而實現的。TCP用於擁塞控制的引數主要有：

(1) 擁塞視窗（cwnd）:擁塞控制的關鍵引數，它描述源端在擁塞控制情況下一次最多能傳送的資料包的數量。

(2) 通告視窗（awin）:接收端給源端預設的傳送視窗大小，它只在TCP連線建立的初始階段發揮作用。

(3) 傳送視窗（win）:源端每次實際傳送資料的視窗大小。

(4) 慢啟動閾值（ssthresh）:擁塞控制中慢啟動階段和擁塞避免階段的分界點。初始值通常設為65535byte。

(5) 迴路響應時間（RTT）:一個TCP資料包從源端傳送到接收端，源端收到接收端確認的時間間隔。

(6) 超時重傳計數器（RTO）:描述資料包從傳送到失效的時間間隔，是判斷資料包丟失與否及網路是否擁塞的重要引數。通常設為2RTT或5RTT。

(7) 快速重傳閾值(tcprexmtthresh):：能觸發快速重傳的源端收到重複確認包ACK的個數。當此個數超過tcprexmtthresh時，網路就進入快速重傳階段。tcprexmtthresh預設值為3。

四個階段

1．慢啟動階段

舊的TCP在啟動一個連線時會向網路傳送許多資料包,由於一些路由器必須對資料包進行排隊，因此有可能耗盡儲存空間，從而導致TCP連線的吞吐量（throughput）急劇下降。避免這種情況發生的演算法就是慢啟動。當建立新的TCP連線時，擁塞視窗被初始化為一個數據包大小（一個數據包預設值為536或512byte）。源端按cwnd大小發送資料，每收到一個ACK確認，cwnd就增加一個數據包傳送量。顯然，cwnd的增長將隨RTT呈指數級(exponential)增長：1個、2個、4個、8個……。源端向網路中傳送的資料量將急劇增加。

2．擁塞避免階段

當發現超時或收到3個相同ACK確認幀時，網路即發生擁塞（這一假定是基於由傳輸引起的資料包損壞和丟失的概率小於1%)。此時就進入擁塞避免階段。慢啟動閾值被設定為當前cwnd的一半；超時時，cwnd被置為1。如果cwnd≤ssthresh,則TCP重新進入慢啟動過程;如果cwnd>ssthresh，則TCP執行擁塞避免演算法，cwnd在每次收到一個ACK時只增加1/cwnd個數據包（這裡將資料包大小segsize假定為1）。

3．快速重傳和恢復階段

當資料包超時時，cwnd被設定為1，重新進入慢啟動，這會導致過大地減小發送視窗尺寸，降低TCP連線的吞吐量。因此快速重傳和恢復就是在源端收到3個或3個以上重複ACK時，就斷定資料包已經被丟失，並重傳資料包，同時將ssthresh設定為當前cwnd的一半，而不必等到RTO超時。圖2和圖3反映了擁塞控制視窗隨時間在四個階段的變化情況。

效率和公平性

除了TCP擁塞控制的自相似性外，TCP擁塞控制的效率和公平性問題目前也受到了廣泛的關注。

1. 效率

網路資源的使用效率是由源端要求的總資源與網路資源的接近程度決定的。如果源端總資源接近或等於網路所能提供的資源，那麼這種演算法的效率就是高的。超載或負載不足都是效率不高的表現。顯然，效率只與總資源的利用率有關，而與各個源端之間的資源利用無關。

2．公平性

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

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

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

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

● 如果資料流遵守TCP擁塞控制方式，那麼在擁塞發生時，作為響應，它首先應將擁塞視窗cwnd減半，然後在每個RTT內按常數速率增加cwnd。給定包丟失率p,TCP連線的最大傳送速率為T byte/s，B為一個數據包的最大位元組數，R為最小RTT。當某資料流的傳送速率大於T時，則可斷定該資料流沒有執行擁塞控制。這一公式主要應用於沒有突發級資料包丟失的情況。實際使用中以大於1.45B/(R)判定資料流沒有執行擁塞控制，以小於1.22B/(R)為解除對該資料流“懲罰”的條件。

● 通過判斷網路中佔據高頻寬的資料流是否對擁塞指示進行響應來決定其是否執行擁塞控制，也就是隨著網路包丟失率的增加，其傳送速率應相應降低。

如果包丟失率p增加x，則源端的傳送速率應大致減少。例如，如果包丟失率增加4倍，那麼傳送速率應減少2倍。正是根據這一關係，通過檢測資料流對包丟失率的反應，就可以大致判斷該流是否執行了擁塞控制。對有ON/OFF特性的資料來源和接收者經常變動的多點廣播（multicast）方式，由於傳送速率本身經常變化，所以這種判斷方法在以上兩種情況下並不理想。

(2) 一些TCP連線之間也存在公平性問題。產生問題的原因在於一些TCP在擁塞前使用了大視窗尺寸，或者它們的RTT較小，或者資料包比其他TCP大，這樣它們也會多佔頻寬。總之，解決TCP擁塞控制公平性問題的根本出路是在Internet上全面實行端到端擁塞控制和融合IP層擁塞控制的新演算法。

改進

事實上，在TCP Reno之前還有TCP Tahoe,兩者的主要區別在於後者只有擁塞控制的前三部分，沒有快速恢復，所以可以認為TCP Reno是TCP Tahoe的改進版。但TCP Reno演算法仍有不足。

首先，源端在檢測到擁塞後，要重傳從資料包丟失到檢測到丟失時傳送的全部資料包（即Go-back-n演算法），而這中間有些資料包被正確地傳到接收端，而不必重傳。

另外，在大多數TCP實現中，RTO計數器的值被認為是RTT的均值和方差的估計值的函式。而準確估計RTO和RTT值並不是一件容易的事。理論上，RTT的測量比較簡單。它只是資料包從發出到確認ACK返回源端的時間。但由於TCP使用的是用一個ACK確認所有已收到資料的“累積”確認方式，所以實際中RTT的估計往往很複雜。

針對以上缺點，近年來人們又提出了一些改進演算法，其中New-Reno和SACK都是改進版。SACK演算法是在Reno基礎上進行擴充套件，對資料包進行有選擇地確認和重傳。這樣，源端就能準確地知道哪些資料包被正確的傳到接收端，從而避免不必要的重傳，減少時延，提高網路吞吐量。New-Reno沒有選用SACK方法，而是盡力避免了Reno在快速恢復階段的許多重傳超時，利用一個ACK確認部分發送視窗，立即重傳餘下的資料包。顯然，New-Reno只需修改源端程式碼。

綜合來看，即使源端不通過等待超時來恢復一個視窗資料中丟失的包，Reno和New-Reno在一個RTT內至多也只能重傳一個被丟棄的包。SACK使用“管道”（pipe）變量表示在傳送路徑上損失的資料包的數量。用tcpremtthresh判斷擁塞是否發生。Reno 優於Tahoe，New-Reno和SACK則優於Tahoe和Reno。由於SACK不像New-Reno一次全部重傳已傳送包，而是有選擇地重傳，因此在一個視窗中出現數據包大量丟失時，SACK的效能優於New-Reno，但SACK的最大缺點在於要修改TCP協議。

由於RTT值與網路執行情況密切相關，因此近幾年又出現了利用RTT控制擁塞的Vegas演算法。Vegas就是通過觀察以前的TCP連線中RTT值的改變情況來控制擁塞視窗cwnd。如果發現RTT變大，那麼Vegas就認為網路發生擁塞，並開始減小cwnd；如果RTT變小，Vegas則解除擁塞，再次增加cwnd。這樣，cwnd在理想情況下就會穩定在一個合適的值上。這樣做的最大好處在於擁塞機制的觸發只與RTT的改變有關，而與包的具體傳輸時延無關。由於它沒有采用包丟失來判斷網路可用頻寬，而改以用RTT的改變來判斷，所以能較好地預測網路頻寬使用情況，並且對小快取的適應性較強，其公平性、效率都較好。但Vegas演算法距離在Internet上普遍應用還有一段距離。這倒不是演算法本身的問題，而是由於使用Vegas和未使用Vegas演算法在競爭頻寬方面不公平所致。