大家可能都聽說過擁塞控制和流量控制，想必也有一些人可能還分不清擁塞控制和流量控制，進而把他們當作一回事。擁塞控制和流量控制雖然采取的動作很相似，但擁塞控制與網絡的擁堵情況相關聯，而流量控制與接收方的緩存狀態相關聯。

也就是說，擁塞控制和流量控制是針對完全不同的問題而采取的措施。今天這篇文章，我們先來講講擁塞控制。

一、為何要進行擁塞控制？

為了方便，我們假設主機A給主機B傳輸數據。

我們知道，兩臺主機在傳輸數據包的時候，如果發送方遲遲沒有收到接收方反饋的ACK，那么發送方就會認為它發送的數據包丟失了，進而會重新傳輸這個丟失的數據包。

然而實際情況有可能此時有太多主機正在使用信道資源，導致網絡擁塞了，而A發送的數據包被堵在了半路，遲遲沒有到達B。這個時候A誤認為是發生了丟包情況，會重新傳輸這個數據包。

結果就是不僅浪費了信道資源，還會使網絡更加擁塞。因此，我們需要進行擁塞控制。

二、如何知道網絡的擁塞情況？

A與B建立連接之后，就可以向B發送數據了，然而這個時候A并不知道此時的網絡擁塞情況如何，也就是說，A不知道一次性連續發送多少個數據包好，我們也把A一次性連續發送多少個數據包稱之為擁塞窗口，用N代表此時擁塞窗口的大小吧。

為了探測網絡的擁塞情況，我們可以采取以下兩種策略：

1、先發送一個數據包試探下，如果該數據包沒有發生超時事件(也就是沒有丟包)。那么下次發送時就發送2個，如果還是沒有發生超時事件，下次就發送3個，以此類推，即N = 1, 2, 3, 4, 5.....

(圖可能畫的不大形象，，，，)

2、一個一個增加實在是太慢了，所以可以剛開始發送1個，如果沒有發生超時時間，就發送2個，如果還是沒有發送超時事件就發送4個，接著8個...，用翻倍的速度類推,即 N = 1, 2, 4, 8, 16...

無論是第一種方法還是第二種方法，最后都會出現瓶頸值。不過這里值得注意的是，第一種情況的增長速率確實有點慢，但是第二種情況以指數增長，增長速度有點太快了，可能一下子就到瓶頸值了。

為了解決這個過慢或過快的問題，我們可以把第一種方法和第二種方法結合起來。也就是說，我們剛開始可以以指數的速度增長，增長到某一個值，我們把這個值稱之為閾值吧，用變量ssthresh代替。當增長到閾值時，我們就不在以指數增長了，而是一個一個線性增長。

所以最終的策略是：前期指數增長，到達閾值之后，就以一個一個線性的速度來增長。

(注：8之后其實是直線的，那里只是彎曲了一下)

我們也把指數增長階段稱之為慢啟動，線性增長階段稱之為擁塞避免

三、到了瓶頸值之后怎么辦？

無論是指數增長還是一個一個增長，最終肯定會出現超時事件，總不可能無限增長吧。當出現超時事件時，我們就認為此時網絡出現了擁塞了，不能再繼續增長了。我們就把這個時候的N的值稱之為瓶頸值吧，用MAX這個字母來代替吧，即最大值。

注：這里再次提醒閾值過后是一個一個線性增長，圖中之所以彎曲是因為我畫圖原因導致的。

當達到最大值MAX之后，我們該怎么辦呢？

當到達最大值之后我們采取的策略是這樣的：

我們就回到最初的最初的狀態，也就是說從1，2，4，8.....開始,不過這個時候我們還會把ssthresh調小，調為MAX值的一半，即ssthresh = MAX / 2。

圖中閾值為8，瓶頸值是14；超時事件發生后，閾值為14 / 2 = 7。

四、超時事件就一定是網絡擁塞？

超時事件發送就一定是網絡出現了擁堵嗎？其實也有可能不是出現了網絡擁堵，有可能是因為某個數據包出現了丟失或者損害了，導致了這個數據包超時事件發生了

為了防止這種情況，我們是通過冗余ACK來處理的。我們都知道，數據包是有序號的，如果A給B發送M1, M2, M3, M4, M5...N個數據包，如果B收到了M1, M2, M4....卻始終沒有收到M3，這個時候就會重復確認M2，意在告訴A,M3還沒收到，可能是丟失了。

當A連續收到了三個確認M2的ACK，且M3超時事件還沒發生。A就知道M3可能丟失了，這個時候A就不必等待M3設置的計時器到期了，而是快速重傳M3。并且把ssthresh設置為MAX的一半，即ssthresh = MAX/2，但是這個時候并非把控制窗口N設置為1，而是讓N = ssthresh，N在一個一個增長。

我們也把這種情況稱之為快速恢復。而這種具有快速恢復的TCP版本稱之為TCP Reno。

還有另外一種TCP版本，無論是收到三個相同的ACK還是發生超時事件，都把擁塞窗口的大小設為1，從最初狀態開始，這種版本的TCP我們稱之為TCP Tahoe。
編輯:hfy