目錄
聲明：以下圖片來源於網絡
1 擁塞的概念
在這裏我引用百度百科上面的概念：
擁塞是指到達通信子網中某一部分的分組數量過多，使得該部分網絡來不及處理，以致引起這部分乃至整個網絡性能下降的現象，嚴重時甚至會導致網絡通信業務陷入停頓，即出現死鎖現象。這種現象跟公路網中經常所見的交通擁擠一樣，當節假日公路網中車輛大量增加時，各種走向的車流相互干擾，使每輛車到達目的地的時間都相對增加（即延遲增加）,甚至有時在某段公路上車輛因堵塞而無法開動(即發生局部死鎖 )。
我們熟知的TCP模塊還有一個重要的任務，就是提高網絡的利用率，降低丟包率，並保證網絡資源對每條數據流的公平性。這就是所謂的擁塞控制，在介紹擁塞控制之前，不得不先提一下TCP的流量控制，滑動窗口。
2.流量控制：滑動窗口
一般來說，我們總是希望數據發送的又快又多。但是這樣，接收方了能來不及接收。所以要進行流量控制。
滑動窗口有的機制很簡單，就是通過設置滑動窗口的大小，來決定每次發送數據的數量。
例如,當前我們的滑動窗口大小爲6，那麼這將意味着主機每次可以最多發送6個數據段。
以下滑動窗口發送機制參考文章：淺談TCP滑動窗口機制
第一次發送：
第一次發送前6個數據段，發送之後必須等待主機B的確認。
加入主機只收到段1，2和5，那麼主機A接收到主機B的的確認包中有序號爲3的段進行確認，確認的是1和2段。此時發送主機的滑動窗口向右滑兩個段，加入7和8，進入第二次發送。
第二次發送：
我們假設當前的6個段都被正常發送，且正常接收，那麼接收記住發回的包中有序列號爲9的段進行確認，即表示前9個段都接受成功。這時滑動窗口向右滑動6個段，進入下一次發送。
第三次發送：
以上三步很具體的概括了滑動窗口的機制。
在瞭解了滑動窗口以後，能讓我們更加深入的理解擁塞控制，因爲滑動窗口決定了發送數據量的大小，擁塞控制主要就是在滑動窗口上做文章。
3 擁塞控制
首先規定幾個縮寫，在下述文章中出現可以進行對照：
- cwnd：擁塞窗口
- SMSS:TCP報文段的最大長度（僅指數據部分）
- ssthresh:慢啓動門限，相當於一個閾值。
- RTT：往返時間 (表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認，不包含數據傳輸時間,總共經歷的時間)。
慢啓動和擁塞避免配合使用，快速重傳和快速恢復同時使用。
3.1 慢啓動
慢啓動的機制是這樣的：爲TCP的發送發增加一個窗口：擁塞窗口（congestion window）,記爲cwnd。當TCP連接建立之後，cwnd的大小被初始化爲1個最大報文段的大小。發送方每收到一次ACK確認之後，就將cwnd的大小增加一個報文段（注意：一個報文段包括不止一個報文）。
增加規則如下：
cwnd += min(N,SMSS)
N爲上次發送被確認的字節數。
假設開始cwnd的大小爲1，那麼經過一次發送之後大小變爲2，經過兩次發送大小變爲4。
cwnd相當於發送方的流量控制。
同時接收方也具有一個窗口叫作通告窗口，作爲接收方的流量控制。
發送方發送數據的大小爲：在發送方擁塞窗口和接收方通告窗口二者中取最小。即將發送方滑動窗口的大小設置爲擁塞控制窗口和通告窗口大小的最小值。
慢啓動存在的理由是：tcp剛開始並不知道網絡的實際情況，需要用一種試探性的方式平滑的增加cwnd的大小。慢啓動算法增加了擁塞窗口，可以反應網絡的整體情況，而滑動窗口只能反應主機個體情況。
從上述cwnd的增加規則中可以看出，慢啓動中cwnd的大小是呈指數級增長的，因此，慢啓動並不慢。如果不進行控制，慢啓動最終會導致網絡擁塞。爲了防止這種情況的發生，TCP在擁塞控制中增加了一個變量ssthresh。並且規定了cwnd的大小要按照下述規則進行：
當cwnd<ssthresh時：進行慢啓動算法
當cwnd>ssthresh時：進行擁塞避免算法
當cwnd==ssthresh時:：兩種皆可
下面介紹擁塞避免。
3.2 擁塞避免
擁塞避免即讓cwnd緩慢的增長，在一個RTT時間內，將cwnd的大小增加1，即增加cwnd的初始大小。這樣，cwnd的大小就從以前的指數級增長變成現在的線性增長。
通過時規定：
無論時慢開始還是擁塞避免，只要網絡出現阻塞，就將ssthresh的值跟新爲cwnd的一半，但不能小於2。同時將cwnd的大小跟新爲1，即爲cwnd的初始大小。
如下圖，時一個慢開始與擁避免的應用舉例：
從可以清楚的看到cwnd的增長方式以及ssthresh的更新。
3.3 快速重傳
在TCP報文段丟失或者接收端收到亂序的TCP報文段等情況下，發送端都會收到重複的確認報文段。
當發送端連續收到3個重複的確認報文端段的時候，tcp就認爲擁塞發生了。然後會立即重傳丟失的報文段。
這就是快速重傳的機制。
3.4 快速恢復
快速恢復機制一般和快速重傳機制同時使用。快速恢復機制如下：
- 當發送端收到第三個重複確認的報文時，會更新ssthresh的值，然後立即重傳丟失的報文段，並且設置：cwnd = ssthresh+3*SMSS，進入擁塞避免階段。
- 當收到一個重複確認的報文時，設置cwnd = cwnd +SMSS。此時發送端可以發送新的TCP報文（如果新的cwnd允許）
- 當收到新數據的確認時，設置cwnd=ssthresh。進入擁塞避免階段。
這裏的新數據表示新的報文，而不是丟失的報文。
在舊的tcp擁塞控制算法中，快速重傳之後會進入慢啓動階段，而新的tcp擁塞控制算法在快速重傳之後進入快速恢復階段。
如下圖：
以上內容有自己的理解，也有網絡上的資料，歡迎大家指正。