原文：【**】你還在為 tcp 重傳、滑動視窗、流量控制、擁塞控制發愁嗎？看完**就不愁了
為什麼要有擁塞控制呀，不是有流量控制了嗎？前面的流量控制是避免「傳送方」的資料填滿「接收方」的快取，但是並不知道網路的中發生了什麼。
一般來說，計算機網路都處在乙個共享的環境。因此也有可能會因為其他主機之間的通訊使得網路擁堵。
在網路出現擁堵時，如果繼續傳送大量資料報，可能會導致資料報時延、丟失等，這時 tcp 就會重傳資料，但是一重傳就會導致網路的負擔更重，於是會導致更大的延遲以及更多的丟包，這個情況就會進入惡性迴圈被不斷地放大….
所以，tcp 不能忽略網路上發生的事，它被設計成乙個無私的協議，當網路傳送擁塞時，tcp 會自我犧牲，降低傳送的資料量。
於是，就有了擁塞控制，控制的目的就是避免「傳送方」的資料填滿整個網路。
為了在「傳送方」調節所要傳送資料的量，定義了乙個叫做「擁塞視窗」的概念。
什麼是擁塞視窗？和傳送視窗有什麼關係呢？擁塞視窗 cwnd是傳送方維護的乙個 的狀態變數，它會根據網路的擁塞程度動態變化的。
我們在前面提到過傳送視窗swnd和接收視窗rwnd是約等於的關係，那麼由於入了擁塞視窗的概念後，此時傳送視窗的值是swnd = min(cwnd, rwnd)，也就是擁塞視窗和接收視窗中的最小值。
擁塞視窗cwnd變化的規則：
那麼怎麼知道當前網路是否出現了擁塞呢？其實只要「傳送方」沒有在規定時間內接收到 ack 應答報文，也就是發生了超時重傳，就會認為網路出現了用擁塞。
擁塞控制有哪些控制演算法？擁塞控制主要是四個演算法：
慢啟動tcp 在剛建立連線完成後，首先是有個慢啟動的過程，這個慢啟動的意思就是一點一點的提高傳送資料報的數量，如果一上來就發大量的資料，這不是給網路添堵嗎？
慢啟動的演算法記住乙個規則就行：當傳送方每收到乙個 ack，就擁塞視窗 cwnd 的大小就會加 1。
這裡假定擁塞視窗cwnd和傳送視窗swnd相等，下面舉個栗子：
可以看出慢啟動演算法，發包的個數是指數性的增長。
那慢啟動漲到什麼時候是個頭呢？有乙個叫慢啟動門限
ssthresh（slow start threshold）狀態變數。
擁塞避免演算法
前面說道，當擁塞視窗cwnd「超過」慢啟動門限ssthresh就會進入擁塞避免演算法。
一般來說ssthresh的大小是65535位元組。
那麼進入擁塞避免演算法後，它的規則是：每當收到乙個 ack 時，cwnd 增加 1/cwnd。
接上前面的慢啟動的栗子，現假定ssthresh為8：
所以，我們可以發現，擁塞避免演算法就是將原本慢啟動演算法的指數增長變成了線性增長，還是增長階段，但是增長速度緩慢了一些。
就這麼一直增長著後，網路就會慢慢進入了擁塞的狀況了，於是就會出現丟包現象，這時就需要對丟失的資料報進行重傳。
當觸發了重傳機制，也就進入了「擁塞發生演算法」。
擁塞發生
當網路出現擁塞，也就是會發生資料報重傳，重傳機制主要有兩種：
這兩種使用的擁塞傳送演算法是不同的，接下來分別來說說。
發生超時重傳的擁塞發生演算法當發生了「超時重傳」，則就會使用擁塞發生演算法。
這個時候，sshresh 和 cwnd 的值會發生變化：
接著，就重新開始慢啟動，慢啟動是會突然減少資料流的。這真是一旦「超時重傳」，馬上回到解放前。但是這種方式太激進了，反應也很強烈，會造成網路卡頓。
就好像本來在秋名山高速漂移著，突然來個緊急剎車，輪胎受得了嗎。。。
發生快速重傳的擁塞發生演算法還有更好的方式，前面我們講過「快速重傳演算法」。當接收方發現丟了乙個中間包的時候，傳送三次前乙個包的 ack，於是傳送端就會快速地重傳，不必等待超時再重傳。
tcp 認為這種情況不嚴重，因為大部分沒丟，只丟了一小部分，則ssthresh和cwnd變化如下：
快速恢復
快速重傳和快速恢復演算法一般同時使用，快速恢復演算法是認為，你還能收到 3 個重複 ack 說明網路也不那麼糟糕，所以沒有必要像rto超時那麼強烈。
正如前面所說，進入快速恢復之前，cwnd和ssthresh已被更新了：
然後，進入快速恢復演算法如下：
也就是沒有像「超時重傳」一夜回到解放前，而是還在比較高的值，後續呈線性增長。
擁塞演算法示意圖
TCp擁塞控制機制
tcp本身的可靠性是利用確認機制，超時重發來保證的，這些不說了，網上資料很多。不過以前一直沒有仔細學習過tcp的網路擁塞控制，現在記錄下一些總結吧。什麼是擁塞？一圖勝千言，看上面的圖，上面是負載 吞吐量，下面是負載 延遲，問題很明顯了，受限於網路節點的物理承受能力，負載顯然不可能和吞吐量成線性關係，...
TCP擁塞控制機制
產生的原因 對資源的需求 可用資源 對資源的需求 可用資源 sum 對資源的需求 可用資源 注意單純的增加網路資源無法解決問題 例如 把結點的儲存空間擴大，更換更高速率的鏈路，提高結點處理機的運算速度，不僅不能解決問題，而且可能使網路效能更壞。原因 網路擁塞是許多因素引起的，單純的解決乙個可能會使上...
TCP擁塞控制機制
對 資源的需 可用資源 對資源的需求 可用資源 注意單純的增加網路資源無法解決問題 例如 把結點的儲存空間擴大，更換更高速率的鏈路，提高結點處理機的運算速度，不僅不能解決問題，而且可能使網路效能更壞。原因 網路擁塞是許多因素引起的，單純的解決乙個可能會使上述情況得到一些緩解，但是會把擁塞轉移到其他地...