控制擁塞演算法
Ⅰ 擁塞演算法
基於包丟失檢測的 Reno、NewReno 或者 cubic 為代表，其主要問題有 Buffer bloat 和長肥管道兩種。和這些演算法不同，bbr 演算法會以時間窗口內的最大帶寬 max_bw 和最小 RTT min_rtt，並以此計算發送速率和擁塞窗口
RTProp : round-trip propagation time BtlBW : bottleneck bandwidth，bbr 演算法關於擁塞窗口的核心就是計算 BtlBW 和 RTprop，根據這兩者值計算 BDP
bbr 演算法輸出 pacing_rate 和 cwnd 兩個數據。pacing_rate 決定發包速率，cwnd 為窗口大小
TCP Tahoe 和 Reno
這兩個演算法是根據其第一次加入到4.3BSD的時間回溯命名的，兩個名字對應自其第一次出現時BSD的代號，而代號分別取自太浩湖（Lake Tahoe）和其附近的城市裡諾市
• Tahoe：如果收到三次重復確認——即第四次收到相同確認號的分段確認，並且分段對應包無負載分段和無改變接收窗口——的話，Tahoe演算法則進入快速重傳，將慢啟動閾值改為當前擁塞窗口的一半，將擁塞窗口降為1個MSS，並重新進入慢啟動階段
• Reno：如果收到三次重復確認，Reno演算法則進入快速重傳，只將擁塞窗口減半來跳過慢啟動階段，將慢啟動閾值設為當前新的擁塞窗口值，進入一個稱為「快速恢復」的新設計階段
Fast recovery
是Reno演算法新引入的一個階段，在將丟失的分段重傳後，啟動一個超時定時器，並等待該丟失分段包的分段確認後，再進入擁塞控制階段。如果仍然超時，則回到慢啟動階段
TCP Vegas
至1990年代中期，TCP量度延遲和RTT都是以傳輸緩存中最後一個被傳送的分段包為准。vegas通過度量傳輸緩存中每個傳送分段包來代替只量度一個分段包，通過每次度量的平均值來增加擁塞窗口。該演算法取名自內華達州最大的城市拉斯維加斯。不過由於一些資源公平性原因，該演算法並沒有在彼得森的實驗室之外廣泛部署。一些研究認為該演算法和其他擁塞演算法混合使用，可能會導致性能競爭不及其他演算法。在各種TCP擁塞演算法的比較研究中，Vegas被認為是最平滑的控制演算法，其次為CUBIC
TCP New Reno
TCP New Reno是對TCP Reno中快速恢復階段的重傳進行改善的一種改進演算法，其定義於RFC 6582，覆蓋了原有在RFC 3782和RFC 2582的舊定義。
在Reno的快速恢復中，一旦出現3次重復確認，TCP發送方會重發重復確認對應序列號的分段並設置定時器等待該重發分段包的分段確認包，當該分段確認包收到後，就立即退出快速恢復階段，進入擁塞控制階段，但如果某個導致重復確認的分段包到遇到重復確認期間所發送的分段包存在多個丟失的話，則這些丟失只能等待超時重發，並且導致擁塞窗口多次進入擁塞控制階段而多次下降。而New Reno的快速恢復中，一旦出現3次重復確認，TCP發送方先記下3次重復確認時已發送但未確認的分段的最大序列號，然後重發重復確認對應序列號的分段包。如果只有該重復確認的分段丟失，則接收方接收該重發分段包後，會立即返回最大序列號的分段確認包，從而完成重發；但如果重復確認期間的發送包有多個丟失，接收方在接收該重發分段後，會返回非最大序列號的分段確認包，從而發送方繼續保持重發這些丟失的分段，直到最大序列號的分段確認包的返回，才退出快速恢復階段。
New Reno在低錯誤率時運行效率和「選擇確認」（Selective ACKnowledgement，SACK）相當，在高錯誤率仍優於Reno
TCP Hybla
TCP Hybla旨在消除由於高延遲地面線路或者衛星無線鏈路下導致的RTT過長而對TCP鏈接的影響。它通過對擁塞窗口動態分析來修改，來減少對RTT的性能依賴
TCP BIC 和 CUBIC
TCP BIC（Binary Increase Congestion control）旨在優化高速高延遲網路（即根據RFC 1072所定義的「長肥網路」（long fat network，LFN））的擁塞控制，其擁塞窗口演算法使用二分搜索演算法嘗試找到能長時間保持擁塞窗口最大值的值。Linux內核在2.6.8至2.6.18使用該演算法作為默認TCP擁塞演算法。
CUBIC則是比BIC更溫和和系統化的分支版本，其使用三次函數代替二分演算法作為其擁塞窗口演算法，並且使用函數拐點作為擁塞窗口的設置值。Linux內核在2.6.19後使用該演算法作為默認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 2008開始廣泛部署，並通過補丁的方式回溯支持到Windows XP和Windows Server 2003。在Linux上也有一個舊版本的移植實現
TCP PRR
TCP PRR（TCP Proportional Rate Rection ）是旨在恢復期間提高發送數據的准確性。該演算法確保恢復後的擁塞窗口大小盡可能接近慢啟動閾值。在Google進行的測試中，能將平均延遲降低3~10%，恢復的超時減少5%。PRR演算法之後作為Linux內核3.2版本的默認擁塞演算法
TCP BBR
TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是由Google設計，於2016年發布的擁塞演算法。以往大部分擁塞演算法是基於丟包來作為降低傳輸速率的信號，而BBR則基於模型主動探測。該演算法使用網路最近出站數據分組當時的最大帶寬和往返時間來創建網路的顯式模型。數據包傳輸的每個累積或選擇性確認用於生成記錄在數據包傳輸過程和確認返回期間的時間內所傳送數據量的采樣率。該演算法認為隨著網路介面控制器逐漸進入千兆速度時，與緩沖膨脹相關的延遲相比丟包更應該被認為是識別擁塞的主要決定因素，所以基於延遲模型的擁塞控制演算法（如BBR）會有更高的吞吐量和更低的延遲，可以用BBR來替代其他流行的擁塞演算法，例如CUBIC
QUIC Quick UDP Internet Connections
QUIC旨在提供幾乎等同於TCP連接的可靠性，但延遲大大減少。它主要通過兩個理解HTTP流量的行為來實現這一點：
第一個變化是在連接創建期間大大減少開銷。由於大多數HTTP連接都需要TLS，因此QUIC使協商密鑰和支持的協議成為初始握手過程的一部分。 當客戶端打開連接時，伺服器響應的數據包包括將來的數據包加密所需的數據。
QUIC使用UDP協議作為其基礎，不包括丟失恢復。相反，每個QUIC流是單獨控制的，並且在QUIC級別而不是UDP級別重傳丟失的數據。這意味著如果在一個流中發生錯誤，協議棧仍然可以獨立地繼續為其他流提供服務
QUIC包括許多其他更普通的更改，這些更改也可以優化整體延遲和吞吐量
每個數據包是單獨加密的，因此加密數據時不需要等待部分數據包。 在TCP下通常不可能這樣做，其中加密記錄在位元組流中，並且協議棧不知道該流中的更高層邊界。這些可以由運行在更上層的協議進行協商，但QUIC旨在通過單個握手過程完成這些
QUIC的另一個目標是提高網路切換期間的性能，例如當移動設備的用戶從WiFi熱點切換到移動網路時發生的情況。 當這發生在TCP上時，一個冗長的過程開始了：每個現有連接一個接一個地超時，然後根據需要重新創建。期間存在較高延遲，因為新連接需要等待舊連接超時後才會創建。 為解決此問題，QUIC包含一個連接標識符，該標識符唯一地標識客戶端與伺服器之間的連接，而無論源IP地址是什麼。這樣只需發送一個包含此ID的數據包即可重新創建連接，因為即使用戶的IP地址發生變化，原始連接ID仍然有效
QUIC在應用程序空間中實現，而不是在操作系統內核中實現。當數據在應用程序之間移動時，這通常會由於上下文切換而調用額外的開銷。 但是在QUIC下協議棧旨在由單個應用程序使用，每個應用程序使用QUIC在UDP上託管自己的連接
Chromium的網路堆棧同時打開QUIC和傳統TCP連接，並在QUIC連接失敗時以零延遲回退到TCP連接
Ⅱ tcp擁塞控制演算法包括
擁塞控制的演算法有：慢開始、擁塞避免、快重傳、快恢復。
慢開始和擁塞避免發送方維持一個擁塞窗口的狀態變數，其大小取決於網路的擁塞程度，動態地變化，而發送窗口一般取擁塞窗口和對方給出的接收窗口之間的最小值。慢開始演算法的核心是從小到大逐漸增大擁塞窗口的數值。
Ⅲ tcp如何實現擁塞控制
TCP擁塞控制是傳輸控制協議（英語：Transmission Control Protocol，縮寫TCP）避免網路擁塞的演算法，是互聯網上主要的一個擁塞控制措施。它使用一套基於線增積減模式的多樣化網路擁塞控制方法（包括慢啟動和擁塞窗口等模式）來控制擁塞。在互聯網上應用中有相當多的具體實現演算法。
在TCP中，擁塞窗口（congestion window）是任何時刻內確定能被發送出去的位元組數的控制因素之一，是阻止發送方至接收方之間的鏈路變得擁塞的手段。他是由發送方維護，通過估計鏈路的擁塞程度計算出來的，與由接收方維護的接收窗口大小並不沖突。
1、慢開始演算法：
簡單的說，開始傳輸時，傳輸的數據由小到大遞增到一個值(即發送窗口由小到大(指數增長)逐漸增大到擁塞窗口的數值)。
2、擁塞避免演算法：
數據發送出去，並發到接收方發回來的確認收到，擁塞窗口每次值加1地線性增大。
3、快重傳演算法：
數據傳輸時(數據被分成報文，每個報文都有個序號)，中間的一部分丟失接收方沒收到，接收方連續接到後面的數據，則發回對丟失前的數據的重復確認，這樣發送方就知道有部分數據丟失了，於是從丟失出重傳數據。
4、快恢復演算法：
快恢復是與快重傳配合的演算法，在發生數據丟失時，發送方收到接收方發回的三個重復確認信息時，就把每次傳輸的數據量減為原來的一半，擁塞窗口也修改為這個值,然後又開始擁塞避免的演算法。
Ⅳ tcp擁塞控制常用演算法
tcp擁塞控制常用演算法方法如下
TCP協議有兩個比較重要的控制演算法，一個是流量控制，另一個就是阻塞控制。TCP協議通過滑動窗口來進行流量控制，它是控制發送方的發送速度從而使接受者來得及接收並處理。而擁塞控制是作用於網路，它是防止過多的包被發送到網路中，避免出現網路負載過大，網路擁塞的情況。擁塞演算法需要掌握其狀態機和四種演算法。擁塞控制狀態機的狀態有五種，分別是Open，Disorder，CWR，Recovery和Loss狀態。四個演算法為慢啟動，擁塞避免，擁塞發生時演算法和快速恢復。和TCP一樣，擁塞控制演算法也有其狀態機。當發送方收到一個Ack時，LinuxTCP通過狀態機(state)來決定其接下來的行為，是應該降低擁塞窗口cwnd大小，或者保持cwnd不變，還是繼續增加cwnd。
Ⅳ TCP擁塞控制
在計算機網路中的鏈路容量（即帶寬）、交換節點（如路由器）中的緩存和處理機等，都是網路的資源。在某段時間內，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的性能就要變壞，從而導致吞吐量將隨著輸入負荷增大而降低。這種情況就叫做 擁塞 。通俗來說，就跟交通擁堵性質一樣。
網路擁塞的原因有很多，如交換節點的 緩存容量太小、輸出鏈路的容量和處理機的速度 。
擁塞控制就是防止過多的數據注入網路中，這樣可以使網路中的路由器或鏈路不致於過載 。擁塞控制是一個 全局性的過程 。涉及網路中所有的主機、所有的路由器，以及與降低網路傳輸性能有關的所有因素。
擁塞控制和流量控制的關系密切，但是 流量控制往往是指點對點的通信量控制 ，是個 端對端 的問題。流量控制所要做的就是抑制發送方發送數據的速率，以便使接收端來得及接收。
TCP進行擁塞控制的演算法有四種，即 慢開始（slow-start）、擁塞避免（congestion-avoidance）、快重傳（fast retransmit）、快恢復（fast recovery） 。
為了討論問題方便，提出以下假定：
擁塞控制也叫做 基於窗口 的擁塞控制。為此，發送方維持一個叫作 擁塞窗口cwnd （congestion window）的狀態變數。 擁塞窗口的大小取決於網路的用誰程度，並且動態的變化。發送方讓自己的發送窗口等於擁塞窗口 。
接收方窗口值rwnd和擁塞窗口值cwnd的區別：
發送方控制擁塞窗口的原則是：只要網路沒有出現擁塞，擁塞窗口就可以再擴大一些，以便讓更多的分組發送出去，如果網路出現了擁塞，就必須將擁塞窗口減小一些，以減少分組的發送。 判斷網路擁塞的依據就是出現了超時 。
慢開始演算法的思路：剛開始發送數據時，不一下向網路中注入大量數據，而是先探測一下，即 由小到大逐漸增大發送窗口 ，也就是說， 由小到大逐漸增大擁塞窗口數值 。
慢開始演算法具體規定：剛開始發送數據時，先把擁塞窗口cwnd根據 發送方的最大報文段SMSS （Sender Maximum Segment Size）數值的大小設置為不超過2-4個SMSS的數值。在 每收到一個對新的報文段的確認後，可以把擁塞窗口增加最多一個SMSS的數值 。用這樣的方法逐步增大發送方的擁塞窗口rwnd，可以使分組注入到網路中的速率更加合理。
下面舉例說明一下，雖然實際上TCP是用位元組數作為窗口大小的單位，但為了方便描述，下面使用報文段的個數來作為窗口的大小的單位，並且假設所有的報文段大小相等。
所以， 慢開始演算法每經過一個傳輸輪次（transmission round），擁塞窗口cwnd就加倍 。
註：在TCP實際運行時，發送方只有收到一個確認就可以將cwnd加1並發送新的分組，並不需要等一個輪次所有的確認都收到後再發送新的分組。
從上面可以看出，慢開始演算法雖然起始的窗口很小，但是每過一個輪次，窗口大小翻倍，呈指數爆炸增長，所以必須要對其進行一個限制，防止其增長過大引起網路擁塞。這個限制就是 慢開始門限ssthresh 狀態變數。慢開始門限ssthresh的用法如下：
擁塞避免演算法的思路是讓擁塞窗口cwnd緩慢增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是像慢開始階段那樣加倍增長。因此在擁塞避免階段就有 「加法增大」AI （Additive Increase）的特點。這表明在擁塞避免階段，擁塞窗口cwnd 按線性規律增長 ，比慢開始演算法的擁塞窗口增長速率緩慢得多。
下面用一個具體的例子來說明擁塞控制的過程，下圖假設TCP發送窗口等於擁塞窗口，慢開始初始門限設置為16個報文段，即ssthresh = 16。
在擁塞避免階段，擁塞窗口是按照線性規律增大的，這常稱為 加法增大AI 。無論在慢開始階段還是擁塞避免階段，只要出現一次超時（即出現一次網路擁塞），就把慢開始門限值 ssthresh 設置為當前擁塞窗口的一半，這叫做 乘法減小 MD （Multiplication Decrease）。
當網路頻繁出現擁塞時，ssthresh 值就下降的很快，以大大減少注入網路中的分組數。
快恢復演算法 ，如果發送方連續接收到3個冗餘ACK，發送方知道現在只是丟失了個別的報文段，此時調整門限值 ssthresh為當前擁塞窗口的一半，同時設置擁塞窗口 cwnd為新的門限值（發生報文段丟失時擁塞窗口的一半），而不是從1開始。
TCP對這種丟包事件的行為，相比於超時指示的丟包，不那麼劇烈 ，所以對於連續收到3個冗餘ACK，擁塞窗口不會從1開始開始。
Ⅵ 簡述擁塞控制的四種基本演算法
慢開始,擁塞避免,快重傳,快恢復.
首先要明白什麼TCP協議可靠傳輸,還有什麼是擁塞窗口:表示當前發送數據的上限,但是它會根據網路好壞狀況動態改變.
慢開始:簡單的說,開始傳輸時,傳輸的數據由小到大遞增到一個值(即發送窗口由小到大(指數增長)逐漸增大到擁塞窗口的數值).
擁塞避免:數據發送出去,並發到接收方發回來的確認收到,擁塞窗口每次值加1地線性增大.
快重傳:數據傳輸時(數據被分成報文,每個報文都有個序號),中間的一部分丟失接收方沒收到,接收方連續接到後面的數據,則發回對丟失前的數據的重復確認,這樣發送方就知道有部分數據丟失了,於是從丟失出重傳數據.
快恢復:快恢復是與快重傳配合的演算法,在發生數據丟失時,發送方收到接收方發回的三個重復確認信息時,就把每次傳輸的數據量減為原來的一半,擁塞窗口也修改為這個值,然後又開始擁塞避免的演算法.