原創帥地 發布於2019-12-15 18:34:36 閱讀數 65 收藏 展開
大家可能都聽說過擁塞控制和流量控制，想必也有一些人可能還分不清擁塞控制和流量控制，進而把他們當作一回事。擁塞控制和流量控制雖然採取的動作很相似，但擁塞控制與網路的擁堵情況相關聯，而流量控制與接收方的快取狀態相關聯。
也就是說，擁塞控制和流量控制是針對完全不同的問題而採取的措施。今天這篇文章，我們先來講講擁塞控制。
為了方便，我們假設主機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。
偷偷透露一下，由於第一次畫這種圖，這幾個圖畫了差不多兩個小時，也是醉了。
下一次可能會將流量控制，敬請期待，如果覺得有收穫，那麼不妨送我乙個贊
作者簡潔
tcp擁塞控制演算法 WebRTC擁塞控制原理解析
webrtc包含三種擁塞控制演算法，gcc bbr和pcc。其中，bbr一開始是針對tcp的擁塞控制提出來的。它的輸入為ack sack，輸出為擁塞視窗 congestion window 傳送速度 pacing rate bbr是怎樣運用到udp，甚至運用到實時流 傳輸之上的？拜讀一下在webrt...
tcp 擁塞控制 TCP流量控制與擁塞控制
流量控制 流量控制的定義 一條tcp連線每一側主機都為該連線設定了接收快取。當該tcp連線收到了正確的 按序的位元組後，他就將資料放入接收快取。相關聯的應用程序會從該快取中讀取資料。但不必是資料一到達就立即讀取。事實上，接收方也許正忙於其他任務，甚至要過很長時間後才讀取該資料。如果某個應用程序讀取比...
TCP擁塞控制
擁塞控制就是防止過多的資料注入到網路中，這樣可以使網路中的路由器或鏈路不致過載，擁塞控制要做的都有個前提，就是網路能夠承受現有的網路負荷。擁塞控制是個全域性性的過程。幾種擁塞控制方法 慢開始 擁塞避免 快重傳 快恢復 1.慢開始和擁塞避免 傳送方維持乙個叫做擁塞視窗的狀態變數，擁塞視窗取決於網路的擁...