分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！
擁塞控制策略
刺蝟@《tcp/ip v1》中tcp的超時和重傳這章講得實在凌亂無比，再加之我們親愛的譯者同志翻譯的時候也按部就班地不幸地湊齊了字數，裡面很多概念看起來特別的晦澀難懂。這裡我參考了《tcp/ip簇》關於tcp的相關章節，稍稍總結了下，方便我後面回頭看了。
講擁塞控制前，我們起碼要知道什麼叫擁塞，就像了解如何帶套前，至少我們先了解什麼是安全套一樣。啥叫「擁塞」呢？《tcp/ip簇》曰"如果網路的負載(即是傳送到網路的分組數)大於網路的容量(即網路能夠處理的分組數)"，打個比方說吧，就是三條高速公路的盡頭匯聚到乙個鄉間機耕道了(高速路和機耕道中間有乙個收費站，中國特色)，你可以想象一下有多少的汽車在收費站面前徘徊，這就叫擁塞了！
接下來是擁塞控制，我們要解決的問題是如何盡最大努力地控制擁塞，減少擁塞。關於擁塞控制策略，《tcp/ip詳解》裡面直接提出的擁塞避免演算法，其實這只是擁塞控制策略的一部分，先把這塊內容提出來讓人有種一葉障目不見泰山的感覺。擁塞控制策略是基於三部分:慢啟動，擁塞避免，擁塞檢測。下面乙個乙個來分析下。
慢啟動的原理我就不再重複打一遍字了，這裡我直接拷貝一塊積木的《tcp/ip 詳解學習筆記》：
擁塞避免階段是擁塞視窗達到我們預先設定的限度之後的階段，這個限度就是我們所說的慢啟動門限，為什麼會設有門限？這個問題很容易理解，因為直觀上看網速肯定有個上限，當達到一定上限後，我們就不能提高了，如果再要往網路裡硬塞入資料報，這就會發生擁塞現象了。這個階段我們要保證這個擁塞視窗不再如同慢啟動一樣瘋狂指數級增長了，所以我們的策略是當視窗裡的所有報文都受到確認後，cwnd就加乙個報文段，即是加一了，這樣就減緩了cwnd增長。《tcp/ip 詳解》說的是受到乙個確認，cwnd加1/cwnd ，其實乙個道理，不過玩了個數字遊戲罷了。
擁塞檢測階段是發現了擁塞我們的處理辦法，一旦擁塞發生了，我們必定要降低往網路裡面塞資料量，這自然是通過傳送方控制cwnd來達到目的了(這裡我們忽略rwnd的影響)，而對於傳送方來說，它只是不停地發資料，根本不知道網路是否擁塞了(為什麼？)。它唯一能體會到的是自己被逼重傳資料報的時候，傳送方要重傳資料報的時候無非兩種情況，乙個是超時，也就是傳送方前面發的資料報在規定時刻沒有受到接受端的確認，這就好比你發了郵件對方不告訴你受到沒有，這種情況很可能是擁塞發生了，中間路由器把包給丟了(資料嚴重擁塞，它直接給你丟了也不告訴你)，接受方根本沒有受到資料報，這樣我們自然收不到確認了。所以這裡處理是:
1、門限值設為當前視窗一半 2、cwnd設為乙個報文段 3、重新從慢開始啟動
第二種情況是受到了》=3個的ack確認，這個是由於其中乙個報文段丟了造成的，然後後面的包又沒有丟失，所以每發乙個資料報，接受端每收到乙個，就發現咦，不對，這個不是我馬上想要的，於是它就發個想要資料報的ack，這種情況出現擁塞可能性比較小，有同學問為什麼這個同樣是丟包了，為什麼不是擁塞呢？很簡單，如果擁塞了，那中間路由器很可能會大量丟報，那我們受到ack確認的資料報可能性也比較小，所以這裡不大可能是擁塞。這裡我們處理較第一種情況反應弱點兒:
1、門限值還是設為一半 2、cwnd設定為門限值 3、回到擁塞避免，而不是慢啟動。
csdn部落格啊～ 越來越不爭氣了～～
給我老師的人工智慧教程打call！
tcp擁塞控制演算法 WebRTC擁塞控制原理解析
webrtc包含三種擁塞控制演算法，gcc bbr和pcc。其中，bbr一開始是針對tcp的擁塞控制提出來的。它的輸入為ack sack，輸出為擁塞視窗 congestion window 傳送速度 pacing rate bbr是怎樣運用到udp，甚至運用到實時流 傳輸之上的？拜讀一下在webrt...
tcp 擁塞控制 TCP流量控制與擁塞控制
流量控制 流量控制的定義 一條tcp連線每一側主機都為該連線設定了接收快取。當該tcp連線收到了正確的 按序的位元組後，他就將資料放入接收快取。相關聯的應用程序會從該快取中讀取資料。但不必是資料一到達就立即讀取。事實上，接收方也許正忙於其他任務，甚至要過很長時間後才讀取該資料。如果某個應用程序讀取比...
TCP擁塞控制
擁塞控制就是防止過多的資料注入到網路中，這樣可以使網路中的路由器或鏈路不致過載，擁塞控制要做的都有個前提，就是網路能夠承受現有的網路負荷。擁塞控制是個全域性性的過程。幾種擁塞控制方法 慢開始 擁塞避免 快重傳 快恢復 1.慢開始和擁塞避免 傳送方維持乙個叫做擁塞視窗的狀態變數，擁塞視窗取決於網路的擁...