快考計網了，正好看到以前 收藏 的一篇文章，關於堵塞控制，我在這裏整理一下。
- 作者寫的相關代碼，有空研究研究
爲什麼會發生阻塞呢？
可以看到下圖，當有多個發端最後匯入一個收端，由於發端都以1GB的速度傳輸，加起來爲2GB，而收端的鏈路只能傳輸1GB的數據，從而導致阻塞的發生。
除了 delay / bandwidth / queue，還有一個 BDP(bandwidth-delay product) 的概念，它是 bandwidth 和 delay 的乘積，表示在一定時間內該鏈路可以容納的字節（容量）。
A link is fully utilized when the number of bytes flowing through it
is equal to the BDP。
所以當發端發送的數據量大於 BDP，鏈路中的 queue 就會溢出，於是就會丟棄數據包。
發端如何知道阻塞的發生呢？
主要有兩種方法：packet loss 和 increased round trip times 前者一直沒有接收到 ack 的回覆，後者會發現接收到回覆的時間比預計的長很多。
在網絡層的協議主要有兩種，TCP 和 UDP，這裏只關注 TCP，區別它與其它協議的是它是可靠傳輸協議，這是通過 ack 來實現的（我之前轉載了一篇文章講 rdt），所以當發端在給定時間內沒有收到收端的 ack，就會重發。
阻塞窗口（The Congestion Window）
The congestion window refers to the number of segments that a sender can send without having seen an acknowledgment yet.
也就是說，阻塞窗口設置爲多大，在一段 delay 的時間裏，它就只能發這麼多包。所以當阻塞窗口設置的太大，發的內容過多，可能就會導致阻塞。所謂 congestion control，就是來調整 congestion window size，以最大限度地減少阻塞。
TCP Tahoe
在80年代互聯網第一次面臨阻塞問題時被髮明出來的算法，流程如下：
Phase 1: Slow Start
每當接收到一個ack，阻塞窗口加一。這種情況下每一輪（一個阻塞窗口大小內容被髮送並接收到ack）的阻塞窗口會翻倍。這個過程一直持續到阻塞窗口大小達到ssthresh（預先設定的值）。
Phase 2: Congestion Avoidance
一旦阻塞窗口大小達到閾值，每一輪的ack被接收，阻塞窗口加一。
如果檢測到有包丟失，發端會重發該包，並且ssthresh會減小一半，當前阻塞窗口恢復爲1，重新進入慢啓動過程。
如何檢測包的丟失？
- time out
- duplicate acks → Fast Retransmit
問題
- 如果鏈路速度非常快，該算法會消耗很長時間
- 包的丟失不一定意味着阻塞發生（可能無線傳輸可靠性差帶來的丟失？）但每次一丟失就減小到1可能不太合適。
- 該算法每次衡量阻塞的方法是檢查包的丟失，但一般包的丟失是因爲阻塞，發生阻塞時，已經發送了很多包，太晚了。
其他方法
CUBIC: This algorithm was implemented in 2005, and is currently the default congestion control algorithm used on Linux systems. Like Tahoe, it relies on packet loss as the indicator of congestion. However, unlike Tahoe, it works far better on high bandwidth networks, since rather than increasing the window by 1 on every round trip, it uses, as the name would suggest, a cubic function to determine what the window size should be, and therefore grows much more quickly.
BBR (Bufferbloat): This is a very recent algorithm developed by Google, and unlike Tahoe or CUBIC, uses delay as the indicator of congestion, rather than packet loss. The rough thinking behind this is that delays are a leading indicator of congestion–they occur before packets actually start getting lost. Slowing down the rate of sending before the packets get lost ends up leading to higher throughput.