TCP擁塞控制

TCP擁塞控制是傳輸控制協議來控制擁塞。在網際網路上應用中有相當多的具體實現演算法。運作方法.TCP使用多種擁塞控制策略來避免雪崩式擁塞。TCP會為每條連線維護一個“擁塞視窗”來限制可能在端對端間傳輸的未確認分組總數量。這類似TCP流量控制機制中使用的滑動視窗。TCP在一個連線初始化或超時後使用一種“慢啟動”機制來增加擁塞視窗的大小。它的起始值一般為最大分段大小內擁塞視窗能高效地雙倍增長。當擁塞視窗超過慢啟動閾值時，演算法就會進入一個名為“擁塞避免”的階段。在擁塞避免階段，只要未收到重複確認，擁塞視窗則在每次往返時間內線性增加一個MSS大小。擁塞視窗.在TCP中，擁塞視窗是任何時刻內確定能被髮送出去的位元組數的控制因素之一，是阻止傳送方至接收方之間的鏈路變得擁塞的手段。他是由傳送方維護，透過估計鏈路的擁塞程度計算出來的，與由接收方維護的接收視窗大小並不衝突。當一條連線建立後，每個主機獨立維護一個擁塞視窗並設定值為連線所能承受的MSS的最小倍數，之後的變化依靠線增積減機制來控制，這意味如果所有分段到達接收方和確認包準時地回到傳送方，擁塞視窗會增加一定數量。該視窗會保持指數增大，直到發生超時或者超過一個稱為“慢啟動閾值”的限值。如果傳送方到達這個閾值時，每收到一個新確認包，擁塞視窗只按照線性速度增加自身值的倒數。當發生超時的時候，慢啟動閾值降為超時前擁塞視窗的一半大小、擁塞視窗會降為1個MSS，並且重新回到慢啟動階段。系統管理員可以設定視窗最大限值，或者調整擁塞視窗的增加量，來對。在流量控制中，接收方透過TCP的“視窗”值來告知傳送方，由傳送方透過對擁塞視窗和接收視窗的大小比較，來確定任何時刻內需要傳輸的資料量。慢啟動.慢啟動是用於結合其他階段演算法，來避免傳送過多資料到網路中而導致網路擁塞，演算法在#重定向 中定義。慢啟動初始啟動時設定擁塞視窗值時，慢啟動演算法就會轉換為線性增長的階段，演算法控制每個RTT內擁塞視窗只增加1個分段量。雖然稱為“慢啟動”，但實際上比擁塞控制階段的視窗增加更為激進。對於處理報文丟失這個事件上，不同擁塞控制演算法表現有所不同：;TCP Tahoe對於TCP Tahoe演算法，當發生丟失時，會進入“快速重傳”機制，慢啟動閾值設為之前擁塞視窗值的一半，擁塞視窗值降為初始值，重新進入慢啟動階段。當擁塞視窗值達到慢啟動閾值時，每RTT內擁塞視窗增加值則為“MSS除以CWND”的值，所以擁塞視窗按線性速度增加。;TCP RenoTCP Reno演算法實現了一個名為“快速恢復”的機制，慢啟動閾值設為之前擁塞視窗值的一半，和作為新的擁塞視窗值，並跳過慢啟動階段，直接進入擁塞控制階段。慢啟動假設分段的未確認是由於網路擁塞造成的，雖然大部分網路的確如此，但也有其他原因，例如一些鏈路質量差的網路，會導致分段包丟失。在一些網路環境，例如無線網路，慢啟動效率並不好。慢啟動對於一些短暫的連線效能並不好，一些較舊的網頁瀏覽器會建立大量連續的短暫連結，透過快速開啟和關閉連結來請求獲得檔案，這使得大多數連結處於慢啟動模式，導致網頁響應時間差。所以現在新的網頁瀏覽器，會透過向特殊的伺服器，開啟一條連結來請求獲得全部的檔案，而避免頻繁新建大量短暫連結。不過這樣對一些非請求網站所提供的服務，例如廣告跟蹤指令碼、社交分享功能指令碼、網路分析指令碼等，並不適用。和式增加，積式減少.和性增長/乘性降低是一種反饋控制演算法，其包含了對擁塞視窗線性增加，和當發生擁塞時對視窗積式減少。多個使用AIMD控制的TCP流最終會收斂到對線路的等量競爭使用。快速重傳.快速重傳是對TCP傳送方降低等待重發丟失分段用時的一種改進。TCP傳送方每傳送一個分段都會啟動一個超時計時器，如果沒能在特定時間內接收到相應分段的確認，傳送方就假設這個分段在網路上丟失了，需要重發。這也是 TCP 用來估計 RTT 的測量方法。重複確認就是這個階段的基礎，其基於以下過程：如果接收方接收到一個數據分段，就會將該分段的序列號加上資料位元組長的值，作為分段確認的確認號，傳送回傳送方，表示期望傳送方傳送下一個序列號的分段。但是如果接收方提前收到更下一個序列號的分段——或者說接收到無序到達的分段，即之前期望確認號對應的分段出現接收丟失——接收方需要立即使用之前的確認號傳送分段確認。此時如果傳送方收到接收方相同確認號的分段確認超過1次，並且該對應序列號的分段超時計時器仍沒超時的話，則這就是出現重複確認，需要進入快速重傳。快速重傳就是基於以下機制：如果假設重複閾值為3，當傳送方收到4次相同確認號的分段確認時，則可以認為繼續傳送更高序列號的分段將會被接受方丟棄，而且會無法有序送達。傳送方應該忽略超時計時器的等待重發，立即重發重複分段確認中確認號對應序列號的分段。具體實現演算法.“TCP+演算法名稱”這一TCP演算法命名方式最早出在凱文·福爾在1996年釋出的一篇論文中。TCP Tahoe 和 Reno.這兩個演算法是根據其第一次加入到4.3BSD的時間回溯命名的，兩個名字對應自其第一次出現時BSD的代號，而代號分別取自太浩湖和其附近的城市雷諾市。“Tahoe”演算法實現在4.3BSD-Tahoe中第一次加入，之後在4.3BSD網路釋出第一版實現了脫AT&amp;T授權版本，使其能更容易被廣泛再發布與實現。改進版“Reno”在4.3BSD-Reno中實現，並之後透過“4.3BSD網路釋出第二版”和4.4BSD-Lite釋出。兩者演算法大致一致，對於丟包事件判斷都是以重傳超時和重複確認為條件，但是對於重複確認的處理，兩者有所不同：對於RTO，兩個演算法都是將擁塞視窗降為1個MSS，然後進入慢啟動階段。快速恢復.快速恢復是Reno演算法新引入的一個階段，在將丟失的分段重傳後，啟動一個超時定時器，並等待該丟失分段包的分段確認後，再進入擁塞控制階段。如果仍然超時，則回到慢啟動階段。TCP Vegas.至1990年代中期，TCP量度延遲和RTT都是以傳輸快取中最後一個被傳送的分段包為準。亞利桑那大學的研究人員拉里·彼得森和提出了新的TCP擁塞演算法“TCP Vegas”，其實透過度量傳輸快取中每個傳送分段包來代替只量度一個分段包，根據每次度量的平均值來增加擁塞視窗。該演算法取名自內華達州最大的城市拉斯維加斯。不過由於一些資源公平性原因，該演算法並沒有在彼得森的實驗室之外廣泛部署。一些研究認為該演算法和其他擁塞演算法混合使用，可能會導致效能競爭不及其他演算法。在各種TCP擁塞演算法的比較研究中，Vegas被認為是最平滑的控制演算法，其次為CUBIC。DD-WRT在v24 SP2開始將該演算法作為其預設的TCP擁塞控制演算法。TCP New Reno.TCP New Reno是對TCP Reno中快速恢復階段的重傳進行改善的一種改進演算法，其定義於#重定向 ，覆蓋了原有在#重定向 和#重定向 的舊定義。在Reno的快速恢復中，一旦出現3次重複確認，TCP傳送方會重發重複確認對應序列號的分段並設定定時器等待該重發分段包的分段確認包，當該分段確認包收到後，就立即退出快速恢復階段，進入擁塞控制階段，但如果某個導致重複確認的分段包到遇到重複確認期間所傳送的分段包存在多個丟失的話，則這些丟失只能等待超時重發，並且導致擁塞視窗多次進入擁塞控制階段而多次下降。而New Reno的快速恢復中，一旦出現3次重複確認，TCP傳送方先記下3次重複確認時已傳送但未確認的分段的最大序列號，然後重發重複確認對應序列號的分段包。如果只有該重複確認的分段丟失，則接收方接收該重發分段包後，會立即返回最大序列號的分段確認包，從而完成重發；但如果重複確認期間的傳送包有多個丟失，接收方在接收該重發分段後，會返回非最大序列號的分段確認包，從而傳送方繼續保持重發這些丟失的分段，直到最大序列號的分段確認包的返回，才退出快速恢復階段。New Reno在低錯誤率時執行效率和“選擇確認”相當，在高錯誤率仍優於Reno。TCP Hybla.TCP Hybla旨在消除由於高延遲地面線路或者衛星無線鏈路下導致的RTT過長而對TCP連結的影響。它透過對擁塞視窗動態分析來修改，來減少對RTT的效能依賴。TCP BIC 和 CUBIC.TCP BIC的擁塞控制，其擁塞視窗演算法使用二分搜尋演算法嘗試找到能長時間保持擁塞視窗最大值的值。Linux核心在2.6.8至2.6.18使用該演算法作為預設TCP擁塞演算法。CUBIC則是比BIC更溫和和系統化的分支版本，其使用三次函式代替二分演算法作為其擁塞視窗演算法，並且使用函式拐點作為擁塞視窗的設定值。Linux核心在2.6.19後使用該演算法作為預設TCP擁塞演算法。TCP Westwood和Westwood+.TCP Westwood改良自New Reno，不同於以往其他擁塞控制演算法使用丟失來測量，其透過對確認包測量來確定一個“合適的傳送速度”，並以此調整擁塞視窗和慢啟動閾值。其改良了慢啟動階段演算法為“敏捷探測”，和設計了一種持續探測擁塞視窗的方法來控制進入“敏捷探測”，使連結儘可能地使用更多的頻寬。Westwood+使用更長的頻寬估計間隔和最佳化的濾波器來修正Westwood對ACK壓縮場景對頻寬估計過高的問題。透過以上改良，TCP Westwood系列演算法在有線網路和無線網路的擁塞控制上取得平衡，尤其研究中針對於無線通訊網路上。Compound TCP.複合TCP是微軟自己實現的TCP擁塞控制演算法，透過同時維護兩個擁塞視窗，來實現在長肥網路有較好的效能而又不損失公平性。該演算法在Windows Vista和Windows Server 2008開始廣泛部署，並透過補丁的方式回溯支援到Windows XP和Windows Server 2003。在Linux上也有一箇舊版本的移植實現。TCP PRR.TCP PRR是旨在恢復期間提高發送資料的準確性。該演算法確保恢復後的擁塞視窗大小盡可能接近慢啟動閾值。在Google進行的測試中，能將平均延遲降低3~10%，恢復的超時減少5%。PRR演算法之後作為Linux核心3.2版本的預設擁塞演算法。TCP BBR.TCP BBR會有更高的吞吐量和更低的延遲，可以用BBR來替代其他流行的擁塞演算法，例如CUBIC。Google在YouTube上應用該演算法，將全球平均的YouTube網路吞吐量提高了4%，在一些國家超過了14%。BBR之後移植入Linux核心4.9版本，並且對於QUIC可用。BBR效率很高，速度也很快，但是它與非BBR的流的公平性有爭議。雖然谷歌的展示顯示 BBR 與 CUBIC 共存良好，但像傑夫·休斯頓和霍克、布利斯和齊特巴特等研究者發現它對其他流不公平，並且不可擴充套件。霍克等人還發現，在Linux 4.9的BBR實現中“存在一些嚴重的固有問題，如排隊延遲增加、不公平和大量資料包丟失”。索海爾·阿巴斯洛等人與網路中的BBR流共存時，BBR流可以支配 CUBIC 流並從中獲得整個鏈路頻寬。