檢視 TCP擁塞控制的原始碼

'''TCP 擁塞控制'''是傳輸控制協定（英語：Transmission Control Protocol，縮寫 TCP）避免網路窒起來的演算法，是網際網路上主要的一个擁塞控制措施。伊使用一套基於線增積減模式的多樣化網路窒窒控制方法（包括慢啟動佮擁窒窗口等模式）來控制擁塞。佇網際網路頂懸應用中有誠濟的具體實現演算法。

==運作方法==

TCP 使用濟款誠窒控制策略來避免雪崩式擁塞。TCP 會共逐條連接維護一个「窒窗仔口」來限制可能佇端對端間傳輸的未確認分組總數量。這類似 TCP 流量控制機制內底使用的滑動窗口。TCP 佇一个連接初始化抑是萬時間使用一種「沓沓仔振動」機制來增加窒窗口的大細。伊的起始值一般為上大分段大細（Maximum segment size，MSS）的兩倍，雖然講名做「沓沓仔振動」，初初值嘛相當低，猶毋過其增加誠緊：做每一个分段得著確認的時陣，窒窗口會增加一个 MSS，予每一擺去返時間（round-trip time，RTT）內擁窒窗仔口能高效地雙倍增長。

做擁塞窗口超過慢啟動隱值（ssthresh）時，演算法就會進入一个名為「窒落來避免」的階段。佇咧擁塞避免的階段，只要無收著重複確認，窒窗口是佇每改往回時間內線性增加一个 MSS 大細。

==窒窗仔口==

佇咧 TCP 中，'''窒窗仔口'''（congestion window）是任何時刻內確定會當予傳送出去的位元組數的控制因素之一，是阻止傳送方至接收方之間的鏈路變甲誠狹的手段。伊是由傳送方維護，通過估計鏈路的洘旱程度計算出來的，佮接收的方維護的接收窗口大細並無衝突。

做一條連接建立了後，逐个主機獨立維護一个人窒窗口並設定值為連接所會當承受的 MSS 的上小倍數，了後的變化倚靠線增積減機制來控制，意味所有分段到達接收方佮確認包準時地轉來到傳送方，窒窗口會增加一定數量。該窗口會保持指數增大，一直到發生過時間抑是超過一个叫做「慢啟動誘值（ssthresh）」 的限值。若是傳送方到這个被值的時陣，每收著一个新的確認包，窒窗仔口干焦按照線性速度增加自身值的倒算。

當發生過時間的時陣，慢啟動增加值降為過時進前洘窒窗仔口的一半大細、擁窒窗口會降為一个 MSS，而且重新轉到嘛開始啟動的階段。

系統的管理員會當設定窗仔口上大限值，抑是調整擁窒窗口的增加量，來著 TCP 調優。

佇咧流量控制中間，接收方通過 TCP 的「窗口」值（Window Size）來告知傳送方，由傳送方通過對窒窗仔口和接收窗仔口的大細較，來確定任何時刻內需要傳輸的資料量。

==沓沓仔振動==

'''沓沓仔振動'''（Slow-start）就是用結合其他的階段佇咧演算法，來避免傳送過多資料到網路內底煞致使網路窒起來，演算法佇 RFC  五千六百八十一中定義。

慢啟動初啟動的時陣設定擁窒窗仔口值（cwnd）為一、二、四或者是十个 MSS。窒窗口佇每一收著一个確認包的時陣增加，彼每一个 RTT 內成倍加，當然實際上並無完全是指數增長，因為接收方會延遲傳送確認，通常是每接收兩个分段是傳送一改確認包。傳送速率隨著慢啟動的進行增加，一直到拄著出現遺失、達到慢啟動標值（ssthresh）、 或者是接收方的接收窗仔口進行限制。若是發生遺失，著 TCP 推斷網路出現濟濟，會試圖採取措施來降低網路負載。遮的靠具體使用的 TCP 窒算法來進行測量判斷。當達到慢啟動隱值（ssthresh）時，慢啟動演算法就會當轉換做線性增長的階段，演算法控制逐个 RTT 內擁窒窗口干焦增加一个分段量。雖然講「沓沓仔振動」，但實際上比人較窒控制階段的窗口增加閣較激進。

對處理報文遺失這个事件頂懸，無仝擁塞控制演算法表現有所無仝：


:'''TCP Tahoe'''
: 對於 TCP Tahoe 演算法，當發生遺失的時，會進入「快速重傳」機制，慢啟動增加值設為進前擁窒窗口值的一半，擁窒窗口值降為初初值，重新進入慢啟動的階段。做咧窒窗仔口值達到慢啟動隱值時，逐 RTT 內底窒窗仔口增加值是為著「MSS 除以 CWND」的值，所以人窒窗仔口按線性速度增加。


:'''TCP Reno'''
: TCP Reno 演算法實現一个叫做「快速恢復」的機制，慢啟動增加值設為進前擁窒窗口值的一半，佮作為新的窒窗口值，並且跳過慢啟動的階段，直接進入擁塞控制階段。

慢啟動假設分段的未確認是因為網路有較窒造成的，雖然大部份網路的確實是按呢，但是有其他的原因，譬如講一寡鏈路品質差的網路，會致使分段的遺失。佇一寡網路環境，譬如講無線網路，慢慢啟動效率並無好。

沓沓仔啟動對一寡短暫的連接效能並無好，一寡較舊的網頁瀏覽器會建立大量連紲的短暫連結，通過快速開啟佮關係連結來請求得著檔案，這予大多數連結結佇咧慢啟動的模式，致使網頁回應時間差。所以這馬新的網頁瀏覽器，會通過向特殊的侍服器，開一條連結來請求得著全部的檔案，避免發生新起大量短暫連結。毋過按呢對一寡非請求網站所提供的服務，譬如講廣告佮蹤指令碼、社交分享功能指令碼、網路分析指令碼等等，並無合用。

==和式增加，積式減少==

佮性增加 / 乘性降低（additive-increase / multiplicative-decrease，AIMD，遮簡稱「線增積減」）是一種回饋控制演算法，其包括著這个對窒窗口線就增加，佮當發生擁塞的時對窗口積式減少。濟使用 AIMD 控制的 TCP 流落尾會縮著對線路的等量競爭使用。

==快速重傳==

'''快速重傳'''（Fast retransmit）是嘿 TCP 傳送方降低等待重發遺失分段用時的一種改進。TCP 傳送方每一个分段攏會啟動一个過時間，若無法度佇特定時間內接收著相應分段的確認，傳送方就假做這个分段佇網路頂懸拍無去，需要去重發。按呢嘛是 TCP 用來估計 RTT 測量方法。

重複確認（duplicate cumulative acknowledgements，DupAcks）就是這个階段的基礎，其實以下的過程：若是接收方接收著一个資料分段，就會將該分段的序列號加上資料位元組長的值，做分段確認的確定號，傳送回傳送方，表示向望傳送方傳送後一个序列號的分段。毋過若是接收方提前收著更後一个序列號的分段—— 抑是講接收著順序達成的分段，就進前向望確認號對應的分段出現接收遺失—— 接收方需要隨使用進前的確認號傳送分段確認。這个時陣若傳送方收著接收方仝款確認號的分段確認超過一擺，並且這該對應序列號的分段超時間計時間猶未超過的時間，則這就是出現重複確認，需要進入快速重傳。

快速重傳就是對以下的機制：若準講設重複交代為三，做傳送方收著四擺仝款確認號的分段確認（第一遍收著確認向望序列號，加三擺重複的向望序列號確認）時，是會當認為繼續傳送閣較高序列號的分段將會予人接受方挕捒，而且會不辦法有長送達。傳送方應該趕緊過時間計時器的等待重發，隨重發重複分段確認中確認號對應序列號的分段。

==具體實現演算法==

「 TCP + 演算法名稱」這一 TCP 演算法號名方式上早出佇凱文 ・ 福爾（Kevin Fall）佮莎莉 ・ 洛洛伊德（Sally Floyd）佇一九九六年發佈的一篇論文中。

===TCP Tahoe 和 Reno===

這兩个演算法是根據其第一擺加入四四配三 BSD 的時間回溯號名的，兩个名對應自其第一改出現的時陣 BSD 的代號，代號分別取自太浩湖（Lake Tahoe）佮其附近的城市雷諾市。「Tahoe」演算法實現此時四配三 BSD-Tahoe 內底第一改加入，了後佇咧四配三 BSD 網路發佈第一版實現矣脫 AT & T 授權版本，遮其實閣會當予人廣泛閣發布佮實現。改進版「Reno」佇咧四配三 BSD-Reno 中實現，並了後通過「四配三 BSD 網路發佈第二版」佮四配四 BSD-Lite 發布。

兩个人演算法大致一致，對擲包事件判斷攏是以重傳超過時間（retransmission timeout，RTO）佮重複確認為條件，但是對重複確認的處理，兩个有無仝款：

* Tahoe：若收著三擺重複確認—— 即第四遍收著相同確認號的分段確認，並且分段對應包無負載分段佮無改變接收窗仔口—— 的話，Tahoe 演算法則進入快速重傳，共慢啟動鋪值改做前人窒窗口的一半，共窒起來窗仔口降做一个 MSS，閣重新進入沓沓仔啟動的階段。
* Reno：若收著三擺重複確認，Reno 演算法則進入快速重傳，只欲窒窗仔口減半來跳過慢啟動的階段，將慢啟動隱值設為當前新的擁窒窗口值，進入一个叫「快速恢復」的新設計階段。

對於 RTO，兩个演算法攏是共窒窗仔口降為一个 MSS，然後進入慢啟動的階段。

====快速恢復====

'''快速恢復'''（Fast recovery）是 Reno 演算法新引入的一个階段，佇咧共遺失的分段重傳了後，發動一个萬時間定時間，並等待該遺失分段包的分段確認了後，閣進入擁塞控制階段。若是猶原超時間，轉到會當慢啟動的階段。

===TCP Vegas===

至一九九空年代中期，TCP 量度延遲和 RTT 攏是以傳輸快取中上尾一个予傳送的分段包為準。亞利桑彼大學的研究人員拉里 ・ 彼著愛佮勞倫斯 ・ 布拉科夫提出新的 TCP 窒起來演算法「TCP Vegas」，其實通過度量傳輸緊取著每一个傳送分段包來代替只量度一个分段包，根據逐改量的平均值來增加窒窗口。該演算法號名自內華達州上大的城市拉斯維加斯。毋過因為一寡資源公平性原因，該演算法並無佇彼个森的實驗室以外廣泛部署。一寡研究認為這个演算法佮其他窒牢演算法敆使用，可能會致使效能競爭袂赴其他演算法。佇各種 TCP 擁塞演算法的較研究中，Vegas 予人認為是上平滑的控制演算法，其次為 CUBIC。

DD-WRT 佇咧 v 二十四 SP 二開始共這个演算法做其預設的 TCP 擁塞控制演算法。

===TCP New Reno===

TCP New Reno 是嘿 TCP Reno 中快速恢復階段的重傳進行改善的一種改進演算法，其定義佇咧 RFC  六千五百八十二，崁去矣原在 RFC  三千七百八十二佮 RFC  兩千五百八十二的舊定義。

佇咧 Reno 的快速恢復內底，若是出現三改的重複確認，TCP 傳送方會重發重複確認對應序列號的分段並設定時器等待該重發分段包的分段確認包，做一个分段確認包收到了後，就隨登出快速恢復階段，進入擁塞控制階段，啊但是若是某一个致使重複確認的分段包著拄著重複確認期間所傳送的分段包佇咧加一个遺失的話，是遮的遺失只通等待超時間重發，並且致使窒窗仔口濟擺進入擁窒控制階段抑若濟擺下降。而且 New Reno 的快速恢復內底，若是出現三改的重複確認，TCP 傳送方先記後三擺重複確認時已經傳送猶毋過無確認的分段的上大序列號，然後重發重複確認對應序列號的分段包。若是干焦該重複確認的分段遺失，則接收方接收該重發分段包了後，會隨轉去上大序列號的分段確認包，對而且完成重發；毋過若重複確認期間的傳送包有加一个遺失，接收方佇接收該重發分段了後，會倒轉去伊上大序列號的分段確認包，對傳送方繼續保持重發遮的遺失的分段，一直到上大序列號的分段確認包的返回，才登出快速恢復階段。

New Reno 佇低錯誤率的時陣執行效率佮「選擇確認」（Selective ACKnowledgement，SACK）相當，佇咧高錯誤率猶原優於 Reno。

===TCP Hybla===

TCP Hybla 旨咧消除因為懸延遲地面線路抑是衛星無線鏈路下致使的 RTT 過長著 TCP 連結的影響。伊通過對窒窗口動態分析來修改，來減少著 RTT 的效能依賴。

===TCP BIC 和 CUBIC===

TCP BIC（Binary Increase Congestion control）旨佇最佳化高速高延遲網路（即根據 RFC  一千空七十二所定義的「長肥網路」（long fat network，LFN）） 的擁塞控制，其實窒窗仔口演算法使用二分搜揣演算法來試看會著會當長時間保持窒窗仔口上大值的值。Linux 核心佇咧二交六 . 八到二鋪六 . 十八使用這個演算法做預設 TCP 窒起來演算法。

CUBIC 著是比 BIC 更加溫和系統化的分支版本，其使用三擺函式代替二分演算法做其他的櫼窗口演算法，並且使用函式拐點作為擁塞窗口的設定值。Linux 核心佇咧二交六 . 十九了後使用這該演算法做預設 TCP 窒起來演算法。

===TCP Westwood 和 Westwood +===

TCP Westwood 改良自 New Reno，無仝往過其他誠窒控制演算法使用遺失來測量，其通過對確認包測量來確定一个「合適的傳送速度」，並且調整擁窒窗口佮慢啟動隱值。其改良矣慢啟動階段演算法為「敏捷探測（Agile Probing）」，佮設計一種繼續探測擁塞窗口的方法來控制進入「敏捷探測」，使連結儘可能地使用閣較濟的頻寬。Westwood + 使用較長的頻寬估計間隔佮最佳化的濾波器來修正 Westwood 著 ACK 壓縮場景對頻寬估計過懸的問題。通過以上改良，TCP Westwood 系列演算法佇咧有線網路佮無線網路的窒起來控制頂懸取得平衡，尤其研究中針對無線通信網路頂懸。

===Compound TCP===

複合 TCP（Compound TCP）是微軟家己實現的 TCP 擁塞控制演算法，通過同時維護兩个人窒窗口，來實這馬長肥網路有較好的效能啊若是閣無損失公平性。該演算法佇 Windows Vista 和 Windows Server 兩千空八開始廣泛部署，閣通過修補程式的方式回溯支援到 Windows XP 和 Windows Server 兩千空三。佇咧 Linux 上嘛有一个舊版本的移植實現。

===TCP PRR===

TCP PRR（TCP Proportional Rate Reduction）是旨咧恢復期間提懸傳送資料的準確性。該演算法確保恢復了後的窒窗仔口大細隻可能接近慢啟動保值。佇咧 Google 進行的測試，會當共平均延續降低三 ~ 百分之十，恢復的萬時間減少百分之五。PRR 演算法了做為 Linux 核心三更二版本的預設擁塞演算法。

===TCP BBR===

TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是由 Google 設計的，佇二空一六年發布的擁塞演算法。往陣大部份是窒起來演算法是因為擲包來做為降低傳輸速率的訊號，而且 BBR 是因為模型主動探測。該演算法使用網路最近出站資料分組彼當時的上大的頻寬佮往回時間來建立網路的顯式模型。封包傳輸的逐个累積或者是選擇性確認用佇生成記錄佇封包傳輸的過程佮確認返回期間的時間內所傳送資料量的取樣率。該演算法認為綴網路介面控制器沓沓仔進入千兆速度的時陣，佮慢衝膨脹相關的延延相比擲包較應該予人認為是辨識擁塞的主要決定因素，所以基於延遲模型的擁塞控制演算法（如 BBR）會有閣較懸的吞吐量佮閣較低的延遲，會用得 BBR 來替代其他的流行擁塞演算法，比如講 CUBIC。Google 佇咧 YouTube 上應該用這个演算法，共全球平均的 YouTube 網路吞吐量提懸百分之四，佇一寡國家超過了百分之十四。

BBR 了後徙入去 Linux 核心四配九版本，並且對 QUIC 可用。

BBR 效率是足懸的，速度嘛誠緊，但是伊佮非 BBR 的流的公平性有爭議。雖然 Google 的展示顯示 BBR 佮 CUBIC 共存甲好勢，但是像傑夫呢 ・ 休斯頓佮霍克、布利斯佮齊特巴特等研究者發現講伊對其他流無公平，並且袂使延伸。霍克等人閣發現，佇咧 Linux 四配九的 BBR 實現中「佇咧一寡嚴重的原生問題，如排隊延延增加、無公平和大量的封包遺失」。

索海爾 ・ 阿巴斯洛等等的人（C 二 TCP 的作者）指出，BBR 佇咧動態環境表現無好，比如蜂岫式網路。𪜶閣表明 BBR 有佇無公平的問題。比如講，做一个 CUBIC 流（佇咧 Linux、Android 和 MacOS 中是預設的 TCP 實現）佮網路中的 BBR 流共存的時，BBR 流會當支配 CUBIC 流並對中得著規个鏈路誠闊。

==註跤==

==參考文獻==

==外部連結==

* Approaches to Congestion Control in Packet Networks ( PDF ) , [二千空一十八孵四鋪十九] ,（原始內容存檔 ( PDF ) 佇二千空一十四抹二爿二十一）
* 一寡關於著櫼控制的論文
* TCP Vegas 的介紹首頁
* Mark Allman , Vern Paxson , W . Richard Stevens . Fast Retransmit / Fast Recovery . TCP Congestion Control . IETF . April 一千九百九十九 : sec .   三孵二 [二千空一十五孵一] . RFC 兩千五百八十一 .
* TCP Congestion Handling and Congestion Avoidance Algorithms –The TCP / IP Guide
* TCP 的 NewReno 快速重傳和快速恢復演算法
* TCP 擁塞控制：Tahoe、Reno、NewReno 佮 SACK 佇咧演算法佮較

[[分類: 待校正]]