bbr演算法路由器

『壹』 協議確認機制TACK的通俗解析

搞計算機網路研究的人都知道，傳輸層協議最經典的問題就是怎麼做 擁塞控制 （Congestion Control）。這玩意做了三十多年還是經久不衰，新人老人前赴後繼，近年來又如雨後春筍般出現了BBR，Copa，PCC， Indigo等演算法，在不同的場景和目標中各顯神通。

在數據傳輸的過程中，人們通常關注正向的數據報文傳輸性能，卻很少關心反向路徑上確認報文ACK的傳輸。然而，高吞吐和低時延往往與ACK的機制設計息息相關。例如，發生擁塞時，我們依賴ACK及時、准確地反饋連接狀態，從而調整發送速率；發生丟包時，我們依賴ACK通知包到達信息，從而進行丟包重傳。

擁塞控制已經「殺」成了一片紅海，而作為協議的另一個重要模塊 協議確認機制 ，卻還是一片處女地。

今年我們在SIGCOMM2020上提出了一種新型的傳輸協議確認機制（ACK Scheme）： TACK ，今天我想通過這篇博文給大家簡單地對TACK機制進行通俗化的解析，算作導讀。

進入正題。

作為萬物互聯 「最後100米」的通信網路技術，無線區域網（WLAN）技術催生了各式各樣新型的移動應用。無論是通過無線路由器把手機、平板、電腦和電視等智能化設備接入到互聯網，還是通過WiFi直連技術架起設備與設備之間的捷徑，WLAN為生活數字化和新型應用（如4K無線投屏、AR/VR互動式游戲等）的涌現，提供了無限可能。​

WLAN最常用的技術就是WiFi。WiFi通常工作在非授權公共頻段（2.4GHz或5GHz），非常容易受到「外部干擾」。這種干擾將造成網路質量突發性劣化和間歇式丟包，導致用戶體驗下降，例如視頻應用可能出現花屏、卡頓，甚至業務中斷。

​業界針對無線傳輸協議的優化，通常更關注「外部干擾」，即採取某種演算法應對網路抖動或丟包。然而，無線傳輸過程中還存在所謂的「內部干擾」——同一連接中ACK報文對數據報文的干擾。

傳統傳輸協議TCP因為要保證可靠，在發送數據報文的同時，難以避免地頻繁發送ACK報文。另一方面，WiFi的半雙工特性和沖突避免機制，造成ACK報文與和數據報文形成了直接的資源競爭，在傳統TCP的ACK機制下，控制報文（ACK）幾乎要佔用將近一半的可用頻譜資源。而且，帶寬越大，「內部干擾」越嚴重。

在這種情況下，減少ACK報文的數目從而降低「內部干擾」，不僅可以提高無線傳輸的有效帶寬利用率，而且還可以在弱網下將有限的寶貴傳輸資源留給數據報文。

然而，傳統TCP依賴於高頻度的ACK進行傳輸控制，簡單粗暴地減少ACK的數目，卻又可能造成滑窗效率低下、緩沖區壓力倍增、以及應用響應時延增加。具體表現為數據突發、窗口更新緩慢、時延評估不準確、丟包恢復魯棒性下降等。

另外，注意到，無線網路同時面臨「外部干擾」和「內部干擾」，傳輸協議如果只強化抗「內部干擾」的手段，就不可避免會降低其抗「外部干擾」的能力。

以上這些矛盾點都使得問題極具挑戰。

這篇文章提出「TACK」(Tame ACK，馴服的確認機制)機制，不僅可以最小化ACK的數目，而且還保證傳輸控制過程的井然有序，正所謂「魚與熊掌兼得」。

TACK機制顛覆了傳統協議確認機制的「簡單粗暴」和固有設定，賦予了ACK報文更多的智能和靈活性。其設計原理，可以簡單地理解成三點： 1）多ACK種類適應不同場景需求；2）ACK按需攜帶更多必要的信息；從而實現：3）更少但足夠的ACK數目。

具體來說，引入一種「即時ACK」報文加快傳輸控制對即時事件（例如丟包）的反饋和響應，同時，引入一種高度自適應的「周期ACK」報文保證反饋的魯棒性和可靠性。這種「周期ACK」報文是以時鍾周期觸發的，而並非以包接收或者超時等事件觸發，這種ACK的數量不會跟吞吐成比例，也就不會造成「內部干擾」隨著吞吐增大而增大。

「即時ACK」報文和「周期ACK」相輔相成、互相補充和高效協同，加上基於TACK機制的丟包恢復、時延探測和速率控制演算法，可以保證丟包恢復的魯棒性、時延探測的准確性以及速率控制高效性。

TACK機製作為一種創新的傳輸協議確認機制，可以在不同的協議載體（例如TCP/UDP/QUIC）上進行實現。我所在的華為計算機網路與協議LAB創新團隊，依託其創新的用戶態極簡協議，為華為全場景生態提供了高效的連接通道。例如，自華為手機系統EMUI 9.1以來，華為、榮耀旗艦手機和智慧屏等多餘款產品均採用了基於TACK的極簡協議，使得其高清視頻和游戲投屏體驗得到顯著改善。

在SIGCOMM的眾多研究方向中，傳輸協議TCP優化是一個經典的課題，與TCP優化相關的工作必須達到一個極高的「閾值」才可能被錄用。

筆者論文「TACK: Improving Wireless Transport Performance by Taming Acknowledgments」作為傳輸協議方向的文章成功入圍，多年苦心鑽研沒有白費，努力有被看到，不禁備感幸運。

這篇文章除了得到譚焜博士和鄭凱博士的指導外，還受到了清華大學徐恪教授也就是我博士導師的財力和學術上的大力支持，感激無法言表。這篇文章也受到了斯坦福大學Keith Winstein的指導和支持，Keith在自己的[個人主頁](https://cs.stanford.e/~keithw/)是這么介紹我們的合作過程的：

更多的細節可以閱讀論文： Tong Li, Kai Zheng, Ke Xu, Rahul Arvind Jadhav, Tao Xiong, Keith Winstein, Kun Tan. 「TACK: Improving Wireless Transport Performance by Taming Acknowledgments.」 Proceedings of the 2020 Conference of the ACM Special Interest Group on Data Communication (ACM SIGCOMM), pp. 15-30, 2020.

也可以訪問我的主頁，獲取PPT和視頻資料： https://leetong.weebly.com/

『貳』 ipv6怎麼開啟bbr

ipv6開啟bbr：買一個堪江出廠支持ipv4和ipv6雙模式光貓，可以相互轉換協議，只要Tcpip啟動iptv6協議光貓路由器模式開啟lenten英特爾連接就可以聯網，iiptv4是32位，iptv6是128位，是iptv4的4倍。

1、 以管理員身份運行cmd命令，進入命令行模式。

2、 輸入netsh。

3、 輸入int ipv6 isatap，進入isatap配置模式。

4、 輸入set router isatap.ahau.e.cn en，配置isatap路由器。

報文內容：

IPv6報文的整體結構分為IPv6報頭、擴展報頭和上層協議數據3部分。IPv6報頭是必選報文頭部，長度固定為40B，包含該報文的基本信息；擴展報頭是可選報頭，可能存在0個、1個或多個，IPv6協議通過擴展報頭實現各種豐富的功能。

上層協議數據是該IPv6報文攜帶的上層數據，可能是ICMPv6報文、TCP報文、UDP報文或其他可能報文。

『叄』 路由重分布的概念

配置基本的路由重分布

配置基本的路由重分布

【實驗目的】：
在本次實驗中，在本次實驗中，你將重分路RIPV2到OSPF協議，並且在RIPv2路由器提供預設路由。
在完成本次實驗之後，你需要完成下列任務：
• 在不同的路由協議之間重分布路由信息。
【實驗拓撲】：

注意：圖中x為所在機架編號，y為路由器編號。
【實驗幫助】：
如果出現任何問題，可以向在值的輔導老師提出並請求提供幫助。
【命令列表】：
命令 描述
(config-router)#default-information originate 在RIP域內發布預設路由
(config)#ip route 0.0.0.0 0.0.0.0 172.31.xx.4 創建一條靜態路由
(config-router)#no auto-summary 在類路由邊界關閉自動匯總功能
(config-router)#redistribute rip subnets 重分布RIP v2到OSPF。這個subnets關鍵字要求傳送子網路由到OSPF域中。
(config-router)#version 2 運行RIP v2
【任務一】：配置路由協議。
實驗過程：
第一步：你的導師已經把BBR2放置到OSPF區域0。
請配置邊界路由器和內部路由器為下列情形：
邊界路由器PxR1和PxR2運行OSPF和RIPv2兩種路由協議。
在邊界路由器上，放置s0介面到OSPF區域0。
因為BBR2是配置為點對多點介面，配置邊界路由器的s0介面為點對多點網路類型。
內部路由器僅配置RIPv2。
你的顯示應該如下列所示：
在邊界路由器上：

在內部路由器上：

第二步：顯示兩個邊界路由器的路由表。驗證兩個邊界路由器是學習到了OSPF和RIPv2的路由。在RIPv2的路由器到你的路由器，那一個是最高RIP跳計數？

【任務二】：配置基本重分布
實驗過程：
第一步：配置邊界路由器傳輸預設路由到RIPv2。記住：為了讓其它RIPv2的路由器學習到預設路由，RIPv2需要配置一條靜態預設路由。
測試內部路由器的路由表：
這里有預設路由出現？
他的路由和度量值是多少？
第二步： 配置兩個邊界路由器重分布RIPv2路到OSPF，重分布路由時，不指定度量值。從RIPv2重分布的路由將在OSPF中預設度量值是多少？記住在重分布路由時一定要使用subnets關鍵字。
第三步：TELNET到核心路由器BBR2測試OSPF資料庫。
路由表中的哪一個路由是從你的實驗機架重分布的？
它們是哪一種OSPF路由類型？
第四步：在兩個內部路由器上測試IP路由表。你的顯示應該與下列類似：

【任務三】：過濾路由更新
配置你的邊界路由器過濾環回介面路由到達網路核心。因為網路核心與你的路由器進行OSPF交換路由，使用分布列表去阻止這條路由重分布到OSPF。
實驗過程：
第一步：創建一條ACL區別四個環回介面地址。
第二步：使用分布列表去阻止這個ACL中的RIPv2路由被重分布到OSPF。
第三步：測試網路核心路由表，驗證環回介面地址是沒有被列表的。
第四步：網路核心能PING通你的環回介面地址嗎？

【實驗驗證】：
成功完成整個實驗，你需要完成下列任務：
• 你能夠在邊界路由器和核心路由之間建立OSPF鄰接，並進行路由交換
• 你能夠在邊界路由器和內部路由器之間進行RIPv2更新和路由交換
• 你能配置從RIPv2重分布路由到OSPF
• 你能發布一條預設路由並注入到RIPv2路由域中

『肆』 ospf路由器，一個路由器可以是IAR,BBR,ASBR.各種角色之間都有哪種可以相互扮演，請高手回個話，謝謝

題目再問清晰點.ABR是連接區域0和其他區域,ASBR是連接外部自治系統的

『伍』 如何驗證開啟linux bbr

僅在Ubuntu，Arch，Manjaro 下測試過，其它發行版同理。
Arch/Manjaro

雖然 Arch/Manjaro 可以直接安裝 linux49 包。但默認沒有開啟 BBR。需要手動編譯。下載 manjaro/packages-corelinux49 包的所有文件，將 config 以及 config.x86_64 文件中的

# CONFIG_TCP_CONG_BBR is not setCONFIG_DEFAULT_CUBIC=y

改為

CONFIG_TCP_CONG_BBR=yCONFIG_DEFAULT_BBR=y

然後將 PKGBUILD 中第二三個 hash 改為 'SKIP'. 執行 makepkg -si 即可。

『陸』 路由重分布希么意思

重發布的意思就是比如說 RouterA和RouterB配兩個不同的動態路由協議，他們之間是沒有LSA的，要想在router上有對方的LSA就要做重發布。一般來說一個組織或者一個跨國公司很少只使用一個路由協議，而如果一個公司同時運行了多個路由協議，或者一個公司和另外一個公司合並的時候兩個公司用的路由協議並不一樣，這個時候該怎麼辦呢？所以必須重發布來將一個路由協議的信息發布到另外的一個路由協議裡面去。
重發布只能在針對同一種第三層協議的路由選擇進程之間進行，也就是說，OSPF，RIP，IGRP等之間可以重發布，因為他們都屬於TCP/IP協議棧的協議

『柒』 如何實現自定義的可靠 UDP 協議--轉載

既然已經有TCP了，為什麼還需要UDP可靠？

TCP是強制的可靠性傳輸，其在IP協議的基礎上，發送端對所有的數據進行定時重傳，接受端對所有的數據進行排序，以此(當然還有很多其他的機制)來實現發送端是什麼樣子的，接受端就能接受到什麼樣子的數據。但是現實中有一些場景，我們並不需要如此固執的可靠性。

對於FPS游戲這種時效性要求非常高的游戲中，玩家最關心的是自己的射擊結果和角色的存活與否，當有一個手雷扔過來時，對於被炸死的玩家而言，這顆手雷是必須要接收到的消息，而其他沒有被炸到的玩家，僅需要看到手雷的爆炸動畫或者是聲音，其更關心的是自己現在的子彈，有沒有將敵人爆頭。我們不希望因為手雷的消息重傳排隊，而把射擊玩家的結果確認消息延後，這對於TCP而言就力所不逮了。

我們看一張圖：

在傳輸效率，傳輸代價和可靠性三個維度上，TCP在最左側的這條線上，可靠性最高，但傳輸代價也很大，效率上不及UDP。UDP則在最右側，只有傳輸效率，不保證可靠，傳輸代價也較低。我們如果需要在大約六角形的位置，選擇一個折中的方案，那就是UDP可靠傳輸，即RUDP登場的時刻了。

如何實現？

首先，為了保證可靠性，我們需要在發送數據的時候添加 重傳定時器 ，來保證丟失的數據會被重傳。重傳的定時器可以定時回調發送重傳的數據，也支持將接收到ACK的數據從定時器中取出。

現在有了重傳定時器，那每次發送數據的時候，應該給定時器設置多長的超時時間呢？最簡單的可以設定一個固定的重傳時間，最合理的應該針對每條傳輸鏈路的不同設置每個連接的合理時間--rto。為了找到rto時間，我們需要獲取到每個數據包發送確認時間，即rtt時間，即數據從發送到接收到ACK確認之間的時間間隔。我們參照TCP的實現策略，可以給每個消息記錄一個發送時間，當接收到ACK確認時，將此時的時間減去記錄的發送時間就獲取到了rtt時間。但這樣有一個問題，當發生數據重傳時接收到ACK，無法判斷這個ACK是對初次發送數據的確認還是對重傳數據的確認，此時只能將發生重傳數據測量到的rtt時間丟棄。所以又有第二種rtt計算策略，我們可以將發送時間記錄在數據頭中發送出去，接受端在發送確認ACK時，將這個時間戳抄下來順著ACK返回，這樣發送端接收到ACK確認時，就能准確的知道要確認數據的發送時間，由此來計算rtt時間。有了rtt時間，我們按照TCP的標准方法《CP/TPxian詳解卷一, P465》，計算rto時間。

當接受到ACK確認時，我們需要將確認的數據從定時器中移除。

為了提高網路鏈路利用率，接收端不能每次接收到數據時都立即發送ACK確認，為什麼呢？傳輸的數據量越小，控制頭佔比越高，而且網路中到處都是只攜帶一個ACK的包在飛，會造成路由器排隊。這里可以接著參考TCP的實現策略。一種是延時ACK，即接收端接收到消息時定製一個pending time，當超時時將這段時間內所有要發送的ACK組合在一起發送，還有一種是捎帶ACK，即pending time未到，但恰好也有數據要發送給對端，那麼就將ACK捎帶在這個數據包中一起發送出去。由於接收端ACK發送都不是瞬時的，所以在上文說到的RTT計算時也需要考慮引起的計算誤差。

有同學要問了，你這整半天UDP可靠，還不是TCP都一樣的策略？那接下來就說點和TCP不一樣的東西了。

我們之前都只說了一個數據包的發送接收策略，當大量數據到來時如何發送呢？不可能一下子將所有數據都發送出去。所以我們需要一個發送窗體來控制發送數據的個數，當允許發送時就拿出下一個數據包發送，這發生在接收到新的ACK確認或者發送窗體大小調整時。這里和TCP的實現不同，TCP將所有的數據平鋪在一個buffer里，然後通過移動滑動窗體來控制發送數據流動。我在這里沒有用到滑動窗體，而是將所有的數據包都放到一個許可權隊列中，按照發送兩個高一級許可權數據包一個低一級數據包的規則來調整發送順序，發送窗體中只有inflight的數據包，當可以發送下一個數據包時，再從許可權隊列中獲取。發送窗體負責對發送後的數據緩存，確認，許可權隊列負責給發送的數據按優先順序排序。

對接收端而言，也需要一個接收隊列對接收到的數據包進行整理，這里我們可以根據需求的不同實現多種排隊策略。如果是想得到TCP的效果，數據即有序，又可靠，那我們需要給所有到達的數據包發送ACK確認且排隊，只有前一個數據包排好隊，無亂序時，才能將數據反回給上層；如果只實現可靠性，不需要有序，那可以接收到一個數據包時，直接反回給上層，但是要發送ACK確認。如果只需要有序性，不需要可靠性，那可以記錄目前收到最大的數據包序號，比這個序號大的數據包返回給上層，比這個序號小的直接丟棄，也不需要發送ACK，因為發送端也不會重傳數據。以上就是三種不同的可靠性傳輸。

前面我們說了很多，數據包即要攜帶時間戳，又要攜帶確認ACK，我們需要給上層發下來的數據添加一個自己的協議頭以使雙端來識別必要的消息，這里我們可以通過不同的控制標識組合來實現一個變長的協議頭，有效利用數據包的傳輸數據量。

其中Flag是必須的，佔用4位元組的長度，通過位標識後面每個塊是否攜帶，這可以通過手動二進制序列來實現。

現在對於一個傳輸連接而言，我們有了重傳機制，確認機制，協議頭封裝，傳輸接收控制，但是網路是公共交通，我們如何遵守交通規則，不引起網路阻塞的同時有效利用網路帶寬呢？這就要引入擁塞控制演算法，我在這里目前使用的是BBR，還沒有實現TCP的CUBIC。那為什麼使用BBR演算法呢？這可就是小孩兒沒娘，說來話長了。簡單來講，常規的CUBIC演算法通過檢測丟包來判斷網路擁塞，然後通過控制發送窗體的大小來控制傳輸在網路中的數據量。大家想一下網路中的傳輸情況：

CUBIC演算法在第3階段檢測到丟包，開始減小發送窗體的大小，以收縮網路中傳輸的數據量，消化路由器排隊隊列，但是這時已經晚了！在沒有發生丟包之前，鏈路中已經被數據包壓的苦不堪言，發送數據的RTT時間已經非常慢。什麼時候是鏈路利用率最高的時候呢？即在2階段路由器即將有排隊情況出現的時候，這時RTT時間最小，但是鏈路上已經有足夠的數據在飛。CUBIC演算法還有一個問題是其控制的輸出變數只有發送窗體的大小，當發送窗體增大，應用層有數據到來時，會一股腦的將可發送的數據量全部發送出去。現實生活中的十字路口，大家都會遵守交通規則，通過紅綠燈控制來保證每個路口都定時的可以讓一些車輛通過，然而到了網路世界裡一切都變的蠻不講理，在此路口車很多的情況下，所有車都一個接一個的駛出，而不管交叉路口還有沒有別的車等待，這是不對的。所以BBR演算法不僅需要控制發送窗體的大小來控制發送的數據量，還通過RTT時間和傳輸的數據量來計算一個數據的發送速度，通過控制數據流發送的時間間隔，來實現按一定速率發送數據。具體BBR演算法是如何實現的，那就是另外一篇長篇大論了，本文不再細說。

到目前為止，關於可靠性和傳輸效率的機制我們基本已經介紹完成，接下來說下傳輸的建立和連接。傳輸建立時並沒有參考TCP的三次握手，依照UDP的簡單粗暴，發送端只管發送數據，接收端能收到算建立了連接，沒有接收到則發送端超時。因為我們的協議實現在應用層，沒有進程啟動的時候也無法發送RST給對端。連接斷開時基本參考了TCP的四次揮手實現，繼續保留了TIME_WAIT狀態來保證網路中上一個連接的數據包不會發送到現任連接上。

關於實現的大體機制終於講完，其他還有一些數據包序列號標識，隨機首個序列號，flow queue，pacing實現等細節沒有展開，但核心的可靠實現基本就是以上，接下來畫一張數據流向圖：

在socket上有一個Filters process，這是一個過濾器責任鏈，所有收發的數據都要通過這個過濾器責任鏈，其可以對傳輸的包體進行壓縮，加密等處理，我在這里實現了snappy對傳輸數據的壓縮過濾器，額外線程通知過濾器，和大數據包的拆分過濾器。通過雙向鏈表管理所有的過濾器模塊，可以很方便的嵌入額外的過濾器過程，在這里也可以實現一些熔斷轉發之類服務治理相關的過濾器。

『捌』 BBR是什麼意思

BBR是一個汽車模型品牌。

BBR是一個全球汽車模型的傳奇品牌，其產品充滿了超級汽車的激情和動感，同時也兼具了汽車模型產品特有的精細和巧奪天工。B.B.R品牌的誕生，來源於品牌創始團隊：Balestrini、Barberis、Reali三人姓名的縮寫。

1994年b.b.r.的車模被德國一家著名的模型雜志「model fan」評為「」modell des jahres」年度車模的榮譽. 這成為b.b.r發展歷史上的重要里程碑，b.b.r的1：43汽車模型，成為全球汽車模型質量卓著、精緻考究的代名詞。

(8)bbr演算法路由器擴展閱讀：

BBR模型種類

1、黏土模型

黏土材料來源廣泛取材方便價格低廉經過「洗泥」工序和「煉熟 過程 其質地更加細膩。黏土具有一定的粘合性 可塑性極強 在塑造過程中可以反復修改 任意調整、 修、 刮 、填，補比較方便。還可以重復使用是一種比較理想的造型材料。

2、石膏模型

石膏價格經濟，方便使用加工，用於陶瓷、塑料、模型製作等方面。石膏質地細膩，成型後易於表面裝飾加工的修補，易於長期保存，適用於製作各種要求的模型，便於陳列展示。

3、塑料模型

塑料是一種常用製作模型的新材料。塑料品種很多，主要品種有五十多種，製作模型應用最多的是熱塑性塑料，主要有聚氯乙烯（PVC）、聚苯乙烯、ABS工程塑料、有機玻璃板材、泡沫塑料板材等。聚氯乙烯耐熱性低，可用壓塑成型、吹塑成型、壓鑄成型等多種成型方法。

4、木製模型

我們使用的木材一般都是經過二次加工後的原木材和人造板材。人造板材常有膠合板、刨花板、細木工板、中密度纖維板等。傢具的模型製作常用木頭製作。

『玖』 如何開啟Linux BBR演算法提升網路速度

僅在Ubuntu，Arch，Manjaro 下測試過，其它發行版同理。
Arch/Manjaro

雖然 Arch/Manjaro 可以直接安裝 linux49 包。但默認沒有開啟 BBR。需要手動編譯。下載 manjaro/packages-corelinux49 包的所有文件，將 config 以及 config.x86_64 文件中的

# CONFIG_TCP_CONG_BBR is not setCONFIG_DEFAULT_CUBIC=y

改為

CONFIG_TCP_CONG_BBR=yCONFIG_DEFAULT_BBR=y

然後將 PKGBUILD 中第二三個 hash 改為 'SKIP'. 執行 makepkg -si 即可。

Ubuntu

『拾』 TCP擁塞控制及BBR原理分析

導語：TCP擁塞控制不僅僅是網路層的概念，可以將其歸屬於控制論的范疇。在TCP的演進過程中，出現了很多優秀的思想和演算法，以實現網路傳輸過程中，在公平競爭性的前提下，盡可能地利用帶寬資源。本文介紹TCP發展過程中出現的幾種擁塞控制演算法，並著重介紹BBR的原理。

TCP擁塞控制不僅僅是網路層的概念，可以將其歸屬於控制論的范疇。在TCP的演進過程中，出現了很多優秀的思想和演算法，以實現網路傳輸過程中，在公平競爭性的前提下，盡可能地利用帶寬資源。

公平性是在發生擁塞時各源端（或同一源端建立的不同TCP連接或UDP數據報）能公平地共享同一網路資源（如帶寬、緩存等）。處於相同級別的源端應該得到相同數量的網路資源。產生公平性的根本原因在於擁塞發生必然導致數據包丟失，而數據包丟失會導致各數據流之間為爭搶有限的網路資源發生競爭，爭搶能力弱的數據流將受到更多損害。因此，沒有擁塞，也就沒有公平性問題。

TCP層上的公平性問題表現在兩方面：

（1）面向連接的TCP和無連接的UDP在擁塞發生時對擁塞指示的不同反應和處理，導致對網路資源的不公平使用問題。在擁塞發生時，有擁塞控制機制的TCP會按擁塞控制步驟進入擁塞避免階段，從而主動減小發送到網路的數據量。但對無連接的數據報UDP，由於沒有端到端的擁塞控制機制，即使網路出現了擁塞，也不會減少向網路發送的數據量。結果遵守擁塞控制的TCP數據流得到的網路資源越來越少，沒有擁塞控制的UDP則會得到越來越多的網路資源。

（2）TCP連接之間也存在公平性問題。產生問題的原因在於使用了不同的擁塞控制演算法，一些TCP在擁塞前使用了大窗口尺寸，或者它們的RTT較小，或者數據包比其他TCP大，這樣它們也會多佔帶寬。

擁塞控制主要包括四個過程：1）慢啟動；2）擁塞避免；3）擁塞發生；4）快速恢復。

RTT ：數據包從發出去到收到對它的ack的來回時間，採用平滑方式計算RTT

RTO ：重傳超時。簡單的如RTO=n*RTT, n=3（或其他RTO計算方法）

SACK ：TCP Option攜帶多組ACK信息

FR ：Fast Retransmission，收到3個p ack後，即可認為發生了丟包。不需要等待RTO超時即可重傳丟失的包。

ER ：Early Retransmission，無法產生足夠的pack和沒有新的數據包可以發送進入網路的情況下，減少觸發FR的p ack數量，以達到觸發FR的目的。

TLP ：如果發生了尾丟包，由於尾包後面沒有更多的數據包，也就沒有辦法觸發任何的pack。實際上，Google統計超過70%的RTO是尾丟包導致沒有任何p

ack 。TLP演算法是通過發送一個loss probe包，來產生足夠的SACK/FACK的信息以觸發RF。

Pacing ：控制發送速率，防止bursting

流控 ：Flow control站在單條TCP連接的維度，目的是讓發送方發包的速度，不超過接收方收包的能力。所以流控解決的問題是，如何在接收方可承受的范圍內，讓單條 TCP 連接的速度最大化。通過滑動窗口機制實現。

擁塞控制 ：Congestion control站在整個互聯網的維度，讓網路里所有TCP連接最大化共享網路通道的同時，盡可能的少出現網路擁塞現象，讓網路世界裡的每一個參與者既公平又高效。

cwnd ：發送窗口，擁塞窗口；在擁塞控制過程中窗口大小值變化。

rwnd ：接收窗口，通知發送者能夠發送的數據大小。

sliding window ：滑動窗口，只是一種抽象機制概念；在發送請求及收到ack的過程中滑動。

歷史上出現的各種TCP擁塞控制演算法，其本質是針對擁塞控制的四個過程做策略調整。按照演算法依據的因素，可以簡單的分為以下類型：

因為Reno等演算法是後續演算法的基礎，這里詳細的描述下Reno演算法的過程。

（1）慢熱啟動演算法 – Slow Start

（2）擁塞避免演算法 – Congestion Avoidance
當cwnd >= ssthresh時，就會進入「擁塞避免演算法」。演算法如下：

（3）擁塞狀態演算法 – Fast Retransmit
Tahoe是等RTO超時，FR是在收到3個plicate ACK時就開啟重傳，而不用等到RTO超時。擁塞發生時：

（4）快速恢復 – Fast Recovery

Reno演算法以其簡單、有效和魯棒性，應用最廣泛。該演算法所包含的慢啟動、擁塞避免和快速重傳、快速恢復機制，是現有的眾多演算法的基礎。從Reno運行機制中很容易看出，為了維持一個動態平衡，必須周期性地產生一定量的丟失，再加上AIMD機制--減少快，增長慢，尤其是在大窗口環境下，由於一個數據報的丟失所帶來的窗口縮小要花費很長的時間來恢復，這樣，帶寬利用率不可能很高且隨著網路的鏈路帶寬不斷提升，這種弊端將越來越明顯。另外，丟包並不一定是網路擁塞，可能是網路常態，但是基於丟包的擁塞控制並不能區分。

vegas通過對RTT的非常重的監控來計算一個基準RTT。然後通過這個基準RTT來估計當前的網路實際帶寬，如果實際帶寬比我們的期望的帶寬要小或是要多的活，那麼就開始線性地減少或增加cwnd的大小。

中間路由器緩存數據導致RTT變大，認為發生擁塞；RTT不公平性，當不同的數據流對網路瓶頸帶寬進行競爭時，具有較小RTT的TCP數據流的擁塞窗口增加速率將會快於具有大RTT的TCP數據流，從而將會佔有更多的網路帶寬資源。

在發送端做帶寬估計，當探測到丟包時，根據帶寬值來設置擁塞窗口、慢啟動閾值。 那麼，這個演算法是怎麼測量帶寬的？每個RTT時間，會測量一次帶寬，測量帶寬的公式很簡單，就是這段RTT內成功被ACK了多少位元組。Westwood會根據RTT變化來判斷丟包是否是網路擁塞造成的，還是網路常態的丟包。如果時延變化不明顯，就認為是非網路擁塞，此時cwnd減少的比較小。

BIC-TCP是Linux 2.6.18默認擁塞控制演算法，依賴丟包條件觸發。BIC-TCP認為TCP擁塞窗口調整的本質就是找到最適合當前網路的一個發送窗口，為了找到這個窗口值，TCP採取的方式是(擁塞避免階段)每RTT加1，緩慢上升，丟包時下降一半，接著再來慢慢上升。BIC-TCP的提出者們看穿了事情的本質，其實這就是一個搜索的過程，而TCP的搜索方式類似於逐個遍歷搜索方法，可以認為這個值是在1和一個比較大的數(large_window)之間，既然在這個區間內需要搜索一個最佳值，那麼顯然最好的方式就是二分搜索思想。

BIC-TCP就是基於這樣一個二分思想的：當出現丟包的時候，說明最佳窗口值應該比這個值小，那麼BIC就把此時的cwnd設置為max_win，把乘法減小後的值設置為min_win，然後BIC就開始在這兩者之間執行二分思想--每次跳到max_win和min_win的中點。

BIC也具備RTT的不公平性。RTT小的連接，窗口調整發生的速度越快，因此可能更快的搶占帶寬。

CUBIC在設計上簡化了BIC-TCP的窗口調整演算法，在BIC-TCP的窗口調整中會出現一個凹和凸(這里的凹和凸指的是數學意義上的凹和凸，凹函數/凸函數)的增長曲線，CUBIC使用了一個三次函數(即一個立方函數)，在三次函數曲線中同樣存在一個凹和凸的部分，該曲線形狀和BIC-TCP的曲線圖十分相似，於是該部分取代BIC-TCP的增長曲線。另外，CUBIC中最關鍵的點在於它的窗口增長函數僅僅取決於連續的兩次擁塞事件的時間間隔值，從而窗口增長完全獨立於網路的時延RTT，使得連接之間保持良好的RRTT公平性。

來看下具體細節：當某次擁塞事件發生時，Wmax設置為此時發生擁塞時的窗口值，然後把窗口進行乘法減小，乘法減小因子設為β，當從快速恢復階段退出然後進入到擁塞避免階段，此時CUBIC的窗口增長開始按照「凹」式增長曲線進行增長，該過程一直持續直到窗口再次增長到Wmax，緊接著，該函數轉入「凸」式增長階段。該方式的增長可以使得窗口一直維持在Wmax附近，從而可以達到網路帶寬的高利用率和協議本身的穩定性。

CUBIC窗口的增長函數：W(t) = C * (t-K)3 + Wmax, 其中C和β為常量。

t為當前時間距上一次窗口減小的時間差，而K就代表該函數從W增長到Wmax的時間周期。

通俗一點講，假如我們知道了Wmax，那麼CUBIC的核心思想就是需要在連續兩次擁塞期間執行完上面的三次函數增長曲線

BBR通過實時計算帶寬和最小RTT來決定發送速率pacing rate和窗口大小cwnd。完全摒棄丟包作為擁塞控制的直接反饋因素。

傳統的擁塞控制演算法是計算cwnd值來規定當前可以發送多少數據，但是並不關注以什麼樣的速度發送數據。如果簡單而粗暴地將窗口大小（send.cwnd、recv.cwnd的最小值）數據全部突發出去，這往往會造成路由器的排隊，在深隊列的情況下，會測量出rtt劇烈地抖動。bbr在計算cwnd的同時，還計算了一個與之適配的pacing rate，該pacing rate規定cwnd指示的一窗數據的數據包之間，以多大的時間間隔發送出去。

我們知道，網路工作的最優點是在物理鏈路延遲狀態下，以最大速率傳輸數據。傳統的擁塞控制演算法思想是根據數據傳輸及ACK來確定RTT，但是這個RTT並不是物理鏈路延時，可能包含了路由器緩存耗時，也可能是擁塞狀態下的耗時。傳統的帶寬計算也是在不斷的試探逼近最優發送窗口，並在RTT或者統計周期內計算帶寬。這種情況下，RTT並不是真正的物理鏈路延遲，帶寬也有可能是在有路由緩存或丟包狀況下計算得到，那麼必然得到的不是精準的值。

BBR摒棄了丟包和實時RTT作為擁塞控制因素。引入BDP管道容量來衡量鏈路傳輸水平。BBR追求的是在鏈路最小RTT（物理鏈路延遲）的狀態下，找到最大帶寬。

首先我們認為網路最優點是可以達到的。下面描述RTT及收包速率與數據包投遞速率的關系。

圖中上半部分的過程可以描述為：隨著數據包投遞速率增加，如果沒有超過最優帶寬，則RTT不會變化，此時的RTT是物理鏈路延遲。隨著投遞速率繼續增加，這時中間路由節點可能出現需要緩存數據包的情況，這會導致RTT變大。如果投遞速率繼續增加，超過路由緩存能力，則可能出現丟包。

圖中下半部分的過程可以描述為：隨著數據包投遞速率增加，如果沒有超過最優帶寬，則發送方確認接收端收到的數據速率增加。隨著投遞速率繼續增加，因為數據包緩存在中間路由，這些包並不能及時得到ACK，因此發送方得到的ACK速率，即發送發確認接收方收到數據的速率會維持不變。如果投遞速率繼續增加，超過路由緩存能力，則可能出現丟包。

1）應答了多少數據，記為delivered；
2）應答1）中的delivered這么多數據所用的時間，記為interval_us。
將上述二者相除，就能得到帶寬：bw = delivered/interval_us；該計算方法不關注數據包ack及順序，是純粹的標量。

我們可以根據圖示很容易算出從Delivered為7時的數據包被確認到X被確認為止，一共有12-7=5個數據包被確認，即這段時間網路上清空了5個數據包。我們便很容易算出帶寬值了。

當10s內沒有發現最小RTTProp時，就要進入ProbeRTT狀態。在ProbeRTT狀態，僅發4MSS/RTT(接近停止發送)，從而排空鏈路上的數據包，測量真實的RTTProp。這里帶來的一個問題是，在一個RTT時間內以4MSS速率發送可能會造成抖動，特別是長RTT場景。具體的參考willko文章《GBN手札-BBR實時大數據傳輸之痛》。