0x00.前言
這是TCP/IP協議棧系列的第二篇文章，之前的一篇理解TCP/IP協議棧之HTTP2.0感興趣可以看下，今天一起來學習下一個熱點問題。
通過本文你將瞭解到以下內容：
擁塞控制概念以及其背景
流量控制和擁塞控制的區別與聯繫
擁塞控制主要過程詳解
夥伴們認真學習一下，讓offer來得更猛烈些吧！
0x01.TCP/IP協議棧簡要回顧
來看下維基百科對TCP/IP的一些介紹，筆者做了少量的修改來確保語句通順：
互聯網協議套件是一個網絡通信模型以及整個網絡傳輸協議家族，由於該協議簇包含兩個核心協議：TCP（傳輸控制協議）和IP（網際協議），因此常被通稱爲TCP/IP協議族。
TCP/IP協議對於數據應該如何封裝、定址、傳輸、路由以及在目的地如何接收等基本過程都加以標準化。它將通信過程抽象化爲四個層次，並採取協議堆棧的方式分別實現出不同通信協議，實際使用的四層結構是七層OSI模型的簡化。
我們可以看到TCP/IP協議棧是一個簡化的分層模型，是互聯網世界連接一切的基石，一起來看一張七層模型vs四層模型的簡圖：
TCP/IP協議棧過於龐大，篇幅所限本文不再做更多細節的描述。
0x02.流量控制和擁塞控制
TCP是一種面向連接的、可靠的、全雙工傳輸協議，前輩們寫了很多複雜的算法爲其保駕護航，其中有一組像海爾兄弟一樣的算法：流量控制和擁塞控制，這也是我們今天的主角。
2.1 流量控制簡介
流量控制和擁塞控制從漢語字面上並不能很好的區分，本質上這一對算法既有區別也有聯繫。
維基百科對於流量控制Flow Control的說明：
In data communications, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver.
It provides a mechanism for the receiver to control the transmission speed, so that the receiving node is not overwhelmed with data from transmitting node.
翻譯一下：
在數據通信中，流量控制是管理兩個節點之間數據傳輸速率的過程，以防止快速發送方壓倒慢速接收方。
它爲接收機提供了一種控制傳輸速度的機制，這樣接收節點就不會被來自發送節點的數據淹沒。
可以看到流量控制是通信雙方之間約定數據量的一種機制，具體來說是藉助於TCP協議的確認ACK機制和窗口協議來完成的。
窗口分爲固定窗口和可變窗口，可變窗口也就是滑動窗口，簡單來說就是通信雙方根據接收方的接收情況動態告訴發送端可以發送的數據量，從而實現發送方和接收方的數據收發能力匹配。
這個過程非常容易捕捉，使用wireshark在電腦上抓或者tcpdump在服務器上抓都可以看到，大白在自己電腦上用wireshark抓了一條：
我們以兩個主機交互來簡單理解流量控制過程：
接收方回覆報文頭部解釋：
圖中RcvBuffer是接收區總大小，buffered data是當前已經佔用的數據，而free buffer space是當前剩餘的空間，rwnd的就是free buffer space區域的字節數。
HostB把當前的rwnd值放入報文頭部的接收窗口receive window字段中，以此通知HostA自己還有多少可用空間， 而HostA則將未確認的數據量控制在rwnd值的範圍內，從而避免HostB的接收緩存溢出。
可見流量控制是端到端微觀層面的數據策略，雙方在數據通信的過程中並不關心鏈路帶寬情況，只關心通信雙方的接收發送緩衝區的空間大小，可以說是個速率流量匹配策略。
流量控制就像現實生活中物流領域中A和B兩個倉庫，A往B運送貨物時只關心倉庫B的剩餘空間來調整自己的發貨量，而不關心高速是否擁堵。
2.2 擁塞控制的必要性
前面我們提到了微觀層面點到點的流量控制，但是我們不由地思考一個問題：只有流量控制夠嗎？答案是否定的。
我們還需要一個宏觀層面的控去避免網絡鏈路的擁堵，否則再好的端到端流量控制算法也面臨丟包、亂序、重傳問題，只能造成惡性循環。
我們從一個更高的角度去看大量TCP連接複用網絡鏈路的通信過程：
所以擁塞控制和每一條端到端的連接關係非常大，這就是流量控制和擁塞控制的深層次聯繫，所謂每一條連接都順暢那麼整個複雜的網絡鏈路也很大程度是通暢的。
在展開擁塞控制之前我們先考慮幾個問題：
如何感知擁塞
TCP連接的發送方在向對端發送數據的過程中，需要根據當前的網絡狀況來調整發送速率，所以感知能力很關鍵。
在TCP連接的發送方一般是基於丟包來判斷當前網絡是否發生擁塞，丟包可以由重傳超時RTO和重複確認來做判斷。
如何利用帶寬
誠然擁塞影響很大，但是一直低速發包對帶寬利用率很低也是很不明智的做法，因此要充分利用帶寬就不能過低過高發送數據，而是保持在一個動態穩定的速率來提高帶寬利用率，這個還是比較難的，就像茫茫黑夜去躲避障礙物。
擁塞時如何調整
擁塞發生時我們需要有一套應對措施來防止擁塞惡化並且恢復連接流量，這也是擁塞控制算法的精要所在。
0x03.理解擁塞控制
前面我們提了擁塞控制的必要性以及重要問題，接下來一起看下前輩們是如何設計實現精彩的擁塞控制策略的吧！
3.1 擁塞窗口cwnd
從流量控制可以知道接收方在header中給出了rwnd接收窗口大小，發送方不能自顧自地按照接收方的rwnd限制來發送數據，因爲網絡鏈路是複用的，需要考慮當前鏈路情況來確定數據量，這也是我們要提的另外一個變量cwnd，筆者找了一個關於rwnd和cwnd的英文解釋：
Congestion Window (cwnd) is a TCP state variable that limits the amount of data the TCP can send into the network before receiving an ACK.
The Receiver Window (rwnd) is a variable that advertises the amount of data that the destination side can receive.
Together, the two variables are used to regulate data flow in TCP connections, minimize congestion, and improve network performance.
筆者在rfc5681文檔中也看到cwnd的定義：
這個解釋指出了cwnd是在發送方維護的，cwnd和rwnd並不衝突，發送方需要結合rwnd和cwnd兩個變量來發送數據，如圖所示：
cwnd的大小和MSS最大數據段有直接關係，MSS是TCP報文段中的數據字段的最大長度，即MSS=TCP報文段長度-TCP首部長度。
3.2 擁塞控制基本策略
擁塞控制是一個動態的過程，它既要提高帶寬利用率發送儘量多的數據又要避免網絡擁堵丟包RTT增大等問題，基於這種高要求並不是單一策略可以搞定的，因此TCP的擁塞控制策略實際上是分階段分策略的綜合過程：
注：有的版本的TCP算法不一定沒有快速恢復階段
如圖爲典型的包含4個策略的擁塞控制：
如圖爲發生超時重傳RTO時的過程：
3.3 TCP算法常見版本
實際上TCP算法有很多版本，每個版本存在一些差異，在這裏簡單看一下維基百科的介紹：
算法命名規則
TCP+算法名的命名方式最早出現在Kevin Fall和Sally Floyd1996年發佈的論文中。
TCP Tahoe 和TCP Reno
這兩個算法代號取自太浩湖Lake Tahoe和裏諾市，兩者算法大致一致，對於丟包事件判斷都是以重傳超時retransmission timeout和重複確認爲條件，但是對於重複確認的處理兩者有所不同，對於超時重傳RTO情況兩個算法都是將擁塞窗口降爲1個MSS，然後進入慢啓動階段。
TCP Tahoe算法：如果收到三次重複確認即第四次收到相同確認號的分段確認，並且分段對應包無負載分段和無改變接收窗口的話，Tahoe算法則進入快速重傳，將慢啓動閾值改爲當前擁塞窗口的一半，將擁塞窗口降爲1個MSS，並重新進入慢啓動階段。
TCP Reno算法：如果收到三次重複確認，Reno算法則進入快速重傳只將擁塞窗口減半來跳過慢啓動階段，將慢啓動閾值設爲當前新的擁塞窗口值，進入一個稱爲快速恢復的新設計階段。
TCP New Reno
TCP New Reno是對TCP Reno中快速恢復階段的重傳進行改善的一種改進算法，New Reno在低錯誤率時運行效率和選擇確認SACK相當，在高錯誤率仍優於Reno。
TCP BIC 和TCP CUBIC
TCP BIC旨在優化高速高延遲網絡的擁塞控制，其擁塞窗口算法使用二分搜索算法嘗試找到能長時間保持擁塞窗口最大值，Linux內核在2.6.8至2.6.18使用該算法作爲默認TCP擁塞算法。
CUBIC則是比BIC更溫和和系統化的分支版本，其使用三次函數代替二分算法作爲其擁塞窗口算法，並且使用函數拐點作爲擁塞窗口的設置值，Linux內核在2.6.19後使用該算法作爲默認TCP擁塞算法。
TCP PRR
TCP PRR是旨在恢復期間提高發送數據的準確性，該算法確保恢復後的擁塞窗口大小盡可能接近慢啓動閾值。在Google進行的測試中，能將平均延遲降低3~10%恢復超時減少5%，PRR算法後作爲Linux內核3.2版本默認擁塞算法。
TCP BBR
TCP BBR是由Google設計於2016年發佈的擁塞算法，該算法認爲隨着網絡接口控制器逐漸進入千兆速度時，分組丟失不應該被認爲是識別擁塞的主要決定因素，所以基於模型的擁塞控制算法能有更高的吞吐量和更低的延遲，可以用BBR來替代其他流行的擁塞算法。
Google在YouTube上應用該算法，將全球平均的YouTube網絡吞吐量提高了4%，BBR之後移植入Linux內核4.9版本。
3.4 擁塞控制過程詳解
我們以典型慢啓動、擁塞避免、快速重傳、快速恢復四個過程進行闡述。
慢啓動
慢啓動就是對於剛啓動的網絡連接，發送速度不是一步到位而是試探性增長，具體來說：連接最初建立時發送方初始化擁塞窗口cwnd爲m，之後發送方在一個RTT內每收到一個ACK數據包時cwnd線性自增1，發送方每經過一個RTT時間，cwnd=cwnd*2指數增長，經過一段時間增長直到cwnd達到慢啓動閾值ssthresh。
之後cwnd不再呈指數增長從而進入擁塞避免階段(注cwnd增長的單位是MSS)，當然如果在慢啓動階段還未到達閾值ssthresh而出現丟包時進入快速重傳等階段，需要注意的是如果網絡狀況良好RTT時間很短，那麼慢啓動階段將很快到達一個比較高的發送速率，所以將慢啓動理解爲試探啓動更形象。
擁塞避免
當慢啓動階段cwnd的值到達ssthresh時就不再瘋狂增長，進入更加理性的線性階段直至發送丟包，本次的閾值ssthresh是上一次發生丟包時cwnd的1/2，因此這是一個承上啓下的過程。
本次發送丟包時仍然會調整ssthresh的值，具體擁塞避免增長過程：發送方每收到一個ACK數據包時將cwnd=cwnd+1/cwnd，每經過一個RTT將cwnd自增1。
超時重傳和快速重傳
TCP作爲一個可靠的協議面臨的很大的問題就是丟包，丟包就要重傳因此發送方需要根據接收方回覆的ACK來確認是否丟包了，並且發送方在發送數據之後啓動定時器，如圖所示：
RTO是隨着複雜網絡環境而動態變化的，在擁塞控制中發生超時重傳將會極大拉低cwnd，如果網絡狀況並沒有那麼多糟糕，偶爾出現網絡抖動造成丟包或者阻塞也非常常見，因此觸發的慢啓動將降低通信性能，故出現了快速重傳機制。
所謂快速重傳時相比超時重傳而言的，重發等待時間會降低並且後續儘量避免慢啓動，來保證性能損失在最小的程度，如圖所示：
快速重傳和超時重傳的區別在於cwnd在發生擁塞時的取值，超時重傳會將cwnd修改爲最初的值，也就是慢啓動的值，快速重傳將cwnd減半，二者都將ssthresh設置爲cwnd的一半。
從二者的區別可以看到，快速重傳更加主動，有利於保證鏈路的傳輸性能，但是有研究表明3個ACK的機制同樣存在問題，本文就不做深入闡述了，感興趣的讀者可以自主查閱。
快速重傳是基於對網絡狀況沒有那麼糟糕的假設，因此在實際網絡確實還算好的時候，快速重傳還是很有用的，在很差的網絡環境很多算法都很難保證效率的。
快速恢復
在快速重傳之後就會進入快速恢復階段，此時的cwnd爲上次發生擁塞時的cwnd的1/2，之後cwnd再線性增加重複之前的過程。
0x04.往期精彩
0x05.巨人的肩膀
https://andrewpqc.github.io/2018/07/21/tcp-flow-control-and-congestion-control/
https://blog.stackpath.com/glossary-cwnd-and-rwnd/
https://tools.ietf.org/html/rfc5681
https://courses.cs.washington.edu/courses/cse461/12sp/lectures/11-congestion-avoidance.html
https://juejin.im/post/5acae2b55188252b0b2013aa
https://www.zhihu.com/question/280521822
https://journal.accsindia.org/experiential-learning-of-networking-technologies-5/4/
