基于QUIC的擁塞控制算法動態切換機制

關鍵詞：擁塞控制；動態切換；QUIC；網絡質量探測

中圖分類號：TP319 文獻標志碼：A 文章編號：1001-3695（2025）07-030-2147-07

doi：10.19734/j. issn.1001-3695.2024.12.0499

Abstract：The traditional approachof staticallyconfiguringasinglecongestioncontrolalgorithmcannolongeradapttothedynamic changes in networksacrosstimeandregions，the dynamicswitching mechanism for congestion control algorithmshas drawnwiespreadatentionfromtheindustry.Toaddressissues suchaslownetwork detectionaccuracyand transmisionperformance fluctuations during dynamic switching，this paper studied the dynamic switching mechanismforcongestioncontrol algorithms basedon QUIC inthe wired network scenario.This mechanismfirstlyintroducedthereceiverbuferfactortoenhance thealgorithm’sadaptabilitytodiferentconfigurationsof thereeivingend.Secondly，itestablishedabotlenecklinkbufer detectionmodelbasedonBBRtoimprovethedetectionaccuracyofnetwork conditions.Finally，itrealizedthesmothswitching between BBRand CUBIC toachievea balance betweenperformanceimprovementand stabilityduring theswitching process.Experimental results demonstrate that this mechanism achieves a throughput gain coverage rate of 78%～87% in shallow bottleneck link buffer scenarios and 89%～95% in deep bottleneck link buffer scenarios.Compared with traditional modeling-basedalgorithms，thismechanismsignificantlyimproves thebandwidthutilizationinwirednetwork scenariosand shows good stability in both throughput and round-trip delay dimensions.

Key Words：congestion control;dynamic switching；QUIC；network quality detection

0引言

在數字化浪潮下，社交、在線辦公、高清視頻等多元網絡應用不斷涌現，對數據傳輸的高效性和穩定性提出了更高要求。傳輸層作為銜接應用層與網絡層的紐帶，處于網絡分層架構的關鍵位置。然而，傳統TCP擁塞控制難以適應復雜多變的網絡環境，不能滿足新型業務需求，且由于位于系統內核空間，難以實現優化調整。現有研究表明，不同擁塞控制算法在各種網絡環境下表現差異顯著[1]，當前也沒有一種擁塞控制算法能夠適用所有網絡場景[2]。但是，在實際應用中，服務提供者通常采用默認的擁塞控制算法，且在連接的全生命周期內維持不變。因此，當應用服務接入的網絡條件隨時間、地域持續動態變化時，這一機制將無法獲得最佳的傳輸性能[3＼～5]

QUIC[6是Google設計的基于UDP的傳輸協議，IETF于2016年開始對QUIC系列協議開展標準化工作。相比TCP，QUIC 具有以下特性：可插拔的擁塞控制[7.8]、傳輸層多路復用、兩級流量控制、O-RTT握手、連接遷移[9-11]等。如今，HTTP/3作為一種基于QUIC的最新HTTP協議，已經在多個場景中成功部署并實現顯著增長[12.13]。繼Google率先采用HTTP/3之后，Akamai、Cloudflare和其他主流CDN服務提供商也都支持和推廣 HTTP/3 。自2024年5月起，HTTP/3的流量占比已達29.5%[14]

QUIC協議作為TCP的升級方案，被越來越多的網絡應用采用，其擁塞控制算法作為傳輸協議的核心模塊被業界廣泛關注。與TCP擁塞控制算法部署在系統內核空間不同，QUIC的擁塞控制以模塊化的方式運行在用戶空間，這帶來了諸多優勢：首先，這使得最新的算法能更便捷地部署到不同的操作系統和真實的網絡環境，促進了算法的檢驗和創新；其次，這有助于根據不同的網絡場景和應用需求來進行精細化的算法調控，更好地適應各種復雜多變的網絡環境。

針對靜態配置擁塞控制算法引發的性能瓶頸問題，學術界首先探索了基于學習機制的擁塞控制算法。此類研究往往使用強化學習等技術來增強算法的動態適應能力，但也面臨諸多挑戰。一方面，實際部署過程中存在訓練復雜、運行開銷大等問題;另一方面，離線訓練的算法在遇到未預訓練場景時，容易出現收斂異常問題，比如收斂到錯誤發送速率導致性能下降、振蕩不穩；即便采用在線學習，也常面臨收斂緩慢、開銷大等難題[15＼～20]

相較之下，關于擁塞控制算法動態切換的研究展現出顯著優勢。這些經典擁塞控制算法往往是針對特定優化目標和網絡場景進行建模的，比如：Westwood算法能精準應對Wi-Fi場景下的信號波動；Swift算法2則在低延遲、高吞吐場景中表現突出，契合數據中心網絡大規模數據傳輸需求;Copa算法[22]在實時視頻流傳輸場景中能有效減少視頻卡頓，提升吞吐量。因此，針對特定目標和網絡場景切換合適的擁塞控制算法，既能規避學習機制算法的短板，又能達到理想的傳輸效果。

關于擁塞控制算法動態切換的研究目前仍處于起步階段，如何結合QUIC優勢來充分提高擁塞控制算法動態切換的性能，仍需解決以下問題：

a）研究場景覆蓋不足。 Floo^[5] 只研究了移動網絡下的動態調整，對局域網、數據中心間高速網絡等場景的研究尚存在空白。

b）指標探測精度差。瓶頸鏈路網絡條件、應用層指標等的探測準確程度將影響選擇策略的有效性。然而，探測效果又受到諸多因素影響，包括探測周期、探測階段的擁塞控制算法選擇等。

c）算法切換前后傳輸波動大。為了保證來回切換的效果，需要解決不同算法切換后導致的傳輸性能波動難題。例如，從BBR[23]（基于BDP算法）切換成CUBIC[24]（基于丟包算法），常出現性能下降或不穩定的問題。

1 研究現狀

1.1相關工作

為解決靜態配置擁塞控制算法引發的性能瓶頸問題，當前開展的研究方向按照基本原理可以分為基于學習機制的擁塞控制算法、融合建模和學習機制的擁塞控制算法、擁塞控制算法動態切換三類。

a）基于學習機制的擁塞控制算法將網絡環境視為黑盒子，不需要對網絡進行假設和精確建模。Remy[15]首次將人工智能技術應用到擁塞控制領域，通過離線訓練直接生成從網絡狀態到限速規則的映射模型。之后，基于在線優化的PCC系列[16＼～18]、基于深度強化學習的 Orca^[19] 、Aurora[20]被陸續提出。但這類研究面臨訓練復雜、收斂振蕩或緩慢、開銷大等難題。

b）融合建模和學習機制的擁塞控制算法的主要思想是結合兩者的優點重新設計一個統一的擁塞控制框架。Libra[25]是最早研究該方向的工作，但其強化學習模型需要調整很多參數，面對未訓練的場景，其公平性和收斂性仍面臨挑戰。Seagull[26]只吸收CUBIC思想進行融合改進。

c）擁塞控制算法動態切換的研究中， Rein^[3] 是最早探索該領域的先驅，但其用戶態與內核態模塊間的管道通信開銷較大，且選擇器僅將網絡條件粗略區分為Wi-Fi和有線兩大類，并依賴預定規則來選擇算法。相比之下，Antelope[4通過eBPF技術優化了通信開銷，盡管選擇云端在線學習在一定程度上減小了計算開銷，但也引人了額外的通信負擔。 Floo^[5] 則是最早基于QUIC實現擁塞控制算法動態切換的機制，其在移動網絡服務中成功優化了請求完成時間（requestcompletion time，RCT）指標，展現了其在這一領域的創新與實用性。表1比較了三者工作的差異。

1.2創新點

盡管現有研究已經對有線網絡環境的擁塞控制表現、擁塞控制算法切換兩個方面作出了重要貢獻，但這些研究通常是孤立進行的。本文的目的是填補這一空自。通過實驗和對結果的深入分析，本文提出一種新的擁塞控制算法動態切換機制，充分利用QUIC在擁塞控制方面的優勢，并針對有線網絡環境特性進行優化設計。本文的主要創新點如下：

a）增加接收端緩沖區影響因素。已有相關研究未充分考慮接收端緩沖區這一影響因素。接收端緩沖區的大小直接影響擁塞控制算法的性能，若緩沖區過小，可能導致數據包丟失，嚴重影響CUBIC等基于丟包算法的表現。為此，本文研究了不同大小的接收端緩沖區條件下的擁塞控制算法表現。

b）精準探測網絡指標。探測階段有很多因素影響網絡條件的探測精度，比如瓶頸鏈路帶寬和平滑往返時延的記錄時間會對瓶頸鏈路緩沖區的估計造成很大影響，從而影響算法切換的決策。已有相關研究并未展開討論。為此，本文提出了瓶頸鏈路緩沖區的精準探測方法。

c）平滑切換算法。針對CUBIC等丟包敏感的擁塞控制算法，為了兼顧快速收斂和性能穩定兩個優化目標，本文提出一種BBR到CUBIC的擁塞控制算法平滑切換方法。

2擁塞控制算法動態切換機制

基于QUIC的擁塞控制算法動態切換框架主要包含監測器、選擇器、切換器三個核心組件。圖1展示了擁塞控制算法動態切換工作流程：監測器針對每條連接，周期性地采集網絡指標及兩端協商參數，并將相關數據信息傳輸至選擇器；選擇器基于所接收的數據信息，為每條連接匹配最適合的擁塞控制算法；切換器在切換擁塞控制算法的同時，還負責平滑轉換擁塞控制狀態，以此構建起一套高效、穩健的擁塞控制算法動態切換機制。

2.1 監測器

監測器模塊需要統計的指標和網絡狀態如表2所示，這些數據主要從CRYPTO幀、ACK幀以及本地QUIC連接信息中獲取。

其中，QUIC握手階段協商的連接級流量控制窗口（con-nectionflowcontrolwindow，cfcw）可以反映接收端緩沖區（receiverbuffer，Rcvbuf）大小，最小往返時延（minimumRTT，minRTT）可以反映往返傳播時間（round-trippropagationtime，RTT）。式（1）遵循RFC9002規定，對最新往返時延（latestRTT，latestRTT）進行加權統計，來計算平滑往返時延（smoothRTT，sRTT）。式（2）根據當前擁塞控制算法的類型，使用瓶頸鏈路帶寬探測過濾器（bottleneck linkbandwidthprobe filter，BtlbwFilter）或擁塞控制窗口（congestioncontrolwindow，cwnd）來估算瓶頸鏈路帶寬（bottlenecklinkbandwidth，Btlbw）。

Floo使用式（3）估算瓶頸鏈路緩沖區（bottlenecklinkbuffer，Btlbuf）。本文通過實驗發現這種探測方法與真實情況存在偏差。

Btlbuf=（sRTT-minRTT）×Btlbw

監測器的探測階段有很多調控因素，具體而言：切換周期（switchingperiod，SP）過短會導致無意義的擁塞控制算法頻繁切換，也不利于準確感知網絡條件，而切換周期過長將對算法適應網絡條件變化的響應速度產生影響；另外，探測階段使用不同原理的擁塞控制算法，會導致從狀態機估算出的網絡指標存在偏差；更重要的是，Floo并未明確Btlbw和sRTT的探測時機，這很大程度決定了Btlbuf的探測準確程度。本文通過實驗，將式（3）估算Btlbuf產生的具體問題總結如下：

a）SP過短導致Btlbuf估計過小。實驗設置Rcvbuf為100MB、Btlbuf為 10MB 、Btlbw為750Mbit/s、RTT為 100ms SP為1s。若到達SP時統計sRTT，估算的Btlbuf遠小于實際值。通過觀察sRTT在1＼～3s的變化曲線可知，由于鏈路時延較大，ACK到達發送端速度慢，導致sRTT更新緩慢，無法反映Btlbuf滿載時的網絡時延，最終使得估算的Btlbuf過小。所以，為確保發送端在各種網絡環境下都能準確測量Btlbuf，需設置更大的 sp 0

b）大量丟包重傳導致Btlbuf估計過大。實驗設置Rcvbuf為5MB、Btlbuf為100KB、SP為12s，并采用BBR作為擁塞控制算法。實驗結果表明，當時延帶寬積（bandwidth-delayproduct，BDP）遠大于Btlbw時，若到達 sp 時統計sRTT，會導致估算的Btlbuf遠大于實際值。BBR在大BDP與淺Btlbuf的網絡條件中容易導致Btlbuf發生丟包，接收端在接收亂序數據包后會等待部分數據包重傳，從而導致ACK發送速度變慢。發送端統計的sRTT將包含過大的端側等待時間，無法準確反映Btlbuf滿載時的網絡時延，最終導致估算的Btlbuf過大。為確保sRTT盡可能反映Btlbuf滿載時的鏈路傳輸時延，本文將在探測階段使用BBR，并在首次丟包時記錄sRTT。

c）BDP遠小于Btlbuf導致Btlbuf估計過小。實驗設置Rcvbuf為100MB、Btlbuf為10MB、SP為12s。實驗結果表明，估算出的Btlbuf遠小于實際值。BBR旨在將發送數據量逼近BDP，但在某些網絡場景中，Btlbuf遠大于BDP，導致BBR無法填滿中間鏈路緩沖區，從而低估Btlbuf的大小。為了規避由于網絡條件BDP限制導致的緩沖區深淺判定錯誤，本文給出瓶頸鏈路緩沖區公式，如式（4）所示。若切換周期內未發生丟包，則表明BDP小于Btlbuf，此時中間鏈路緩沖區為深緩沖區；若切換周期內發生丟包，則按原公式計算緩沖區大小。

同時，通過分析Btlbuf探測精度差的原因，本文進一步總結出一套估計流程方法，如表3所示。設定切換周期為5s，在此期間內，使用BBR控制發包速率；同時，若未發生丟包，則判定瓶頸鏈路緩沖區足夠深，反之則記錄首次丟包時的sRTT。到達切換周期時間節點后，選取BtlbwFilter的最大值為瓶頸鏈路帶寬；同時，若此前發生丟包，則利用式（4）計算瓶頸鏈路緩沖區大小。

2.2 選擇器

在本文中，選擇器的優化目標是選出最適合當前網絡條件的擁塞控制算法，以提升網絡吞吐量。為實現這一目標，本文首先在有線網絡環境的大量場景中，對BBR和CUBIC兩種擁塞控制算法的吞吐量進行詳盡測量，并指定擁塞控制算法選擇規則。

本文測試了QUIC不同擁塞控制算法的吞吐表現，并利用式（5）評估了BBR相對于CUBIC的吞吐增益百分比，具體實驗方法見3.1節。

圖2展示了BBR相對CUBIC的增益效果，其中，Shallow和deepBtlbuf分別是 100KB 和 10MB ，Shallow和deepRecvbuf分別是5MB和 100MB 。表格顏色越深表示兩者傳輸吞吐差異越大，其中藍色表示BBR差于CUBIC，紅色則表示BBR優于CUBIC（見電子版）。通過實驗，本文可以獲取以下結論：

a）在淺Btlbuf、深Rcvbuf網絡環境中，式（6）成為BBR優于CUBIC、BBR，差于CUBIC兩個區域的大致分界線，本文實驗條件下 k 取近似值3。

BDP=k×Btlbuf

b）在淺Btlbuf網絡環境中，Rcvbuf的深淺程度對熱力分布影響不大，并非主要因素。

c）在深Btlbuf網絡環境中，Rcvbuf的深淺程度對熱力分布影響很大。具體而言，在淺Rcvbuf情況下，BBR在超過 95% 的網絡條件中表現均優于CUBIC，且剩余 5% 的網絡條件下吞吐表現絕對值差異均很小，本文直接選擇BBR;而在深Rcvbuf情況下，在大BDP網絡條件中CUBIC的表現反而相比BBR有較大優勢。

另外，考慮深Btlbuf、深Rcvbuf網絡環境中，當Btlbw ?20 Mbit/s時，監測器始終無法精確探測瓶頸鏈路帶寬，選擇器通過切換周期內是否丟包來進一步優化切換策略。具體算法如下所示。

算法1接收端深緩沖區場景下的算法選擇策略輸入：切換周期內的丟包情況lossflag；接收端可用緩沖區大小Rcvbuf；往返傳播時間 RTProp ；瓶頸鏈路帶寬 Btlbw ；瓶頸鏈路緩沖區Btlbuf。

輸出：選擇的擁塞控制算法accflag。

a）if（Rcvbuf gt; Rcvbuf_thresh）then/*接收端深緩沖區條件*/b） if（ lossflag==1 amp;amp;Btlbuf Π_lt; Btlbuf_threshamp;amp;Btlbw RTProp lt;= k* Btlbuf）then / * 瓶頸鏈路淺緩沖區條件 /

c） a ccflag=CUBIC 執行后轉步驟r）。

d） else if（lossflag== 1 amp;amp;Btlbuf gt; Btlbuf_threshamp;amp;Btlbw * RTProp）then/ * 瓶頸鏈路深緩沖區條件*/

e） for（i=1;i-1;i++） do

f） if（s.t：RULE_1（i））then

g） accflag Σ=Σ CUBIC。執行后轉步驟r）。

h） end if

i） end for

j） else 瓶頸鏈路深緩沖區條件 * /

k） for（j=1;j2;j++） do

1） if（s.t：RULE_2（j））then

m） accflag τ=τ CUBIC。執行后轉步驟r）。

n） end if

0） end for

p） endif

q）end if

r）return accflag

2.3 切換器

切換器的主要目標之一是在切換后能夠快速收斂并適應當前網絡狀態，從而實現性能提升。理想情況下，新的擁塞控制算法應繼承所有相關變量，并根據切換后新觀察到的網絡情況實現持續更新。然而，不同原理的算法在切換過程中可能面臨性能下降或不穩定的問題，這主要源于算法間的個性化操作和狀態變量的差異性。例如，直接從基于BDP的BBR算法切換到基于丟包的CUBIC算法時，CUBIC[24]可能收斂至異常值，影響性能表現。

為了解決從BBR切換到CUBIC性能下降或不穩定的問題，本文給出分析過程和優化方案：

a）BBR定期進入RTT探測階段，通過主動減小cwnd來探測最小往返時延。為避免CUBIC繼承該階段的cwnd，本文提出式（7），采用基于時間窗的統計方法，選擇過去一段時間內的cwnd平均值供CUBIC繼承。

b）CUBIC是一種基于丟包的擁塞控制算法，它在慢啟動階段采用指數增長，在擁塞避免階段采用三次函數增長。當檢測到丟包時，CUBIC會啟動新一輪的擁塞避免階段，而超時則會導致完全重新開始慢啟動。相比之下，BBR不響應丟包事件，并力求維持發送數據量達到BDP。在BDP超過BtIbuf的場景中，如果CUBIC直接采用BBR的cwnd，可能引發大量數據在瓶頸鏈路緩沖區排隊超時或者溢出丟包，進而導致cwnd的顯著波動。為緩解這一問題，本文在這種場景中重置CUBIC的關鍵變量epoch_start（該變量記錄擁塞避免階段的開始時間），這可以使cwnd在適當的比例下繼承當前值，并且在新的cwnd周圍按照三次函數進行增長。這種機制不僅加快了收斂速度，還確保了擁塞窗口不會增長過快，增強切換算法后cwnd調整的穩定性。式（8）進一步給出了epoch_start的處理方法。

2.4算法復雜度分析

本文擁塞控制算法動態切換機制的時間復雜度為 O（1） 0

證明擁塞控制算法動態切換機制主要由監測、選擇、切換三個階段構成。

a）監測階段的時間復雜度。監測器定期記錄網絡狀態變量，并使用式（2）（4）來估計瓶頸鏈路網絡指標，上述操作時間復雜度都是 O（1） 。

b）選擇階段的時間復雜度。結合圖2可知，BBR表現優于（差于）CUBIC的網絡條件存在明顯的區域分界，因此本文選擇器采用規則判斷方法，無須復雜的計算或迭代，算法1中的循環條件判斷復雜度是常數級別。因此，該階段的時間復雜度為 O（1） 。

c）切換階段的時間復雜度。切換算法通過統計過去一段時間內的cwnd平均值來支持決策。為了保證較低的計算開銷并在動態網絡環境中快速響應，統計的cwnd數量通常被限制為常數級別，因此該階段的時間復雜度為 O（1） 。

本文所提整體機制的時間復雜度由監測、選擇、切換三個階段的時間復雜度相加構成。由于這三個階段的時間復雜度均為 O（1） ，所以，本文提出的擁塞控制算法動態切換機制的時間復雜度為 O（1） 。

3 實驗性能評估

為了驗證擁塞控制算法動態切換機制的性能，本文搭建了實驗環境并開展測試。

3.1 實驗方法

本節詳細描述實驗方法，包括實驗平臺、網絡場景、QUIC選型、磁盤讀寫、緩沖區設置、驗證方式等。

a）實驗平臺。本文復現了文獻[27，28]中使用的拓撲結構，其中發送端（表示為h1）通過中間節點（表示為h2）向接收端（表示為h3）發送數據。如圖3所示，拓撲中的所有節點采用的都是Linux服務器，具體配置如下：操作系統為Ubuntu20.04.6LTS（內核版本是5.15.0-97-generic），CPU型號是 Xeon@ CPU E5-2660 v3 @ 2.60 GHz，CPU核數是40核，網卡型號是IntelCorporationI35OGigabitNetworkConnection。

b）網絡場景。實驗過程中，在中間節點使用流量控制工具TC來設置網絡條件：上行鏈路出口（eth1）設置網絡延遲（該規則需要設置足夠大的隊列長度，因為在大時延大帶寬條件下，大量ACK可能在該隊列等待造成隊列溢出，影響發送端擁塞控制調整）;下行鏈路出口（eth2）設置瓶頸鏈路帶寬和瓶頸鏈路緩沖區。本文考慮的網絡條件基本與上述論文保持一致，如表4所示。

c）QUIC選型。為拓寬擁塞控制動態切換研究范圍，本實驗采用TQUIC[29]作為客戶端，LSQUIC[30]作為服務器。這是因為LSQUIC支持IETFQUIC和GQUIC雙協議棧，盡管本次研究的重點是IETFQUIC，但采用LSQUIC將為未來在GQUIC分支開展工作提供便利。同時，LSQUIC已被集成到其CDN服務（quic.cloud[31]），并展現出良好的整體性能，這一實際應用案例進一步驗證了LSQUIC的有效性和可靠性。另一方面，TQUIC具有出色的跨平臺兼容性，截至2024年11月已支持多達七個平臺，為未來服務器端算法適應不同平臺客戶端奠定部署基礎。

d）其他配置。磁盤讀寫方面，為了消除磁盤I/O對實驗結果的影響，服務器端將待發送的文件直接保存在內存中，客戶端在接收網絡數據后不寫人磁盤。套接字緩沖區方面，由于可靠傳輸和限速控制邏輯均在用戶態實現，UDP緩沖區通常不會成為吞吐量的瓶頸，所以本文將UDP緩沖區設置為50MB。QUIC接收端緩沖區方面，本文在TQUIC客戶端側分別設置了5MB和100MB的連接級別流量控制窗口（前者是默認值，后者使QUIC的吞吐表現接近網絡性能測試工具iperf3），以檢驗客戶端側的變化對服務器擁塞控制表現的影響。

e）驗證方式。為驗證實驗設置符合預期，本文使用ping來驗證往返時延，使用UDP模式下的iperf3來驗證瓶頸鏈路帶寬。為驗證實驗設置和QUIC實現沒有導致QUIC吞吐表現異常，本文使用TCP模式下的iperf3（TCP發送端和接收端緩沖區均設置成100MB）來對比QUIC吞吐效果。

3.2吞吐量對比效果與分析

本節評估動態切換機制（adaptive）在不同網絡場景下的吞吐性能，圖4、5展示了其分別與CUBIC、BBR以及不同網絡條件下兩者表現最優值（best）的對比結果，其中藍色表示adap-tive更差，紅色則表示adaptive更優（見電子版）。

1）瓶頸鏈路淺緩沖區場景

a）實驗結果。如圖4所示，在超過 87% 的網絡條件中，本文提出的機制與CUBIC表現相近或更好 （?-0.1% ），在大BDP網絡條件下增益明顯;在超過 78% 的網絡條件中，本文提出的機制與BBR表現相近或更好（ ），在小BDP網絡條件下增益明顯；盡管無法在所有網絡環境中表現得比最佳值更好，但相比CUBIC和BBR都更能適應不同的網絡條件。

b）原因分析。首先，本文機制相較于CUBIC在吞吐增益方面提升顯著，接近 28% 的區域增益達到 100%～1 000% 。這主要是由于在大BDP和淺Btlbuf的網絡環境中，容易發生丟包，導致對丟包敏感的CUBIC算法主動降低發送速率；而本文機制基于BDP探測值來動態調控發送速率，以適度的重傳為代價，換取了顯著的吞吐量優勢。其次，本文機制相較于BBR在吞吐增益方面的提升主要集中在小BDP區域，這主要是由于在小BDP網絡中，RTT的波動較為顯著，BBR的帶寬探測機制難以充分發揮作用，同時BDP較小，限制了BBR的性能表現；相比之下，本文提出的機制能夠準確監測網絡指標，并平滑切換至CUBIC算法，不僅保證了算法在不同網絡條件下的適應性，還顯著提升了吞吐表現的穩定性。

2）瓶頸鏈路深緩沖區場景

a）實驗結果。如圖5所示，在超過 95% 的網絡條件中，本文提出的機制與CUBIC表現相近或更好 （?-0.1% ），在大時延網絡條件下增益明顯；在超過 89% 的網絡條件中，本文提出的機制與BBR表現相近或更好 （?-0.1% ），在大BDP網絡條件下增益明顯；另外，相比前面瓶頸鏈路淺緩沖區實驗結果，本文所提出的機制更能適應不同網絡條件的變化，在超過84% 的網絡條件中與最優值表現相近或更好（ ≥-0.1% ），其中，最差相對表現能控制在 -1% 以內，而在大BDP條件下增益明顯。

b）原因分析。當瓶頸鏈路緩沖區深度足夠時，丟包頻率顯著降低，在大BDP網絡條件下，CUBIC的表現優于BBR。本文提出的機制可以平滑切換至CUBIC算法，充分利用深緩沖區的優勢，突破BDP的限制，進一步提升發送速率。此外，在小BDP網絡條件下，CUBIC與BBR的性能接近，本文提出的機制將保持原有策略，避免頻繁切換，從而確保傳輸的穩定性。

3.3 穩定性效果與分析

a）實驗結果。本節對平滑往返時間和吞吐量指標進行歸一化處理，使不同算法或場景之間的比較更加直觀和公平。圖6展示了兩個指標的關聯關系及其穩定性表現。三種算法的橢圓都是向右下方傾斜，表示平滑往返時間和吞吐量呈負相關（當平滑往返時間增加時，吞吐量減少）。本文提出的機制能夠獲得比其他擁塞控制算法更小的橢圓，這表明其在不同的網絡條件下具有更好的性能穩定性。

b）原因分析。本文提出的機制的優勢在于其動態切換能力。當BBR算法在部分網絡環境下表現不佳時，本文機制能夠動態切換至CUBIC，從而確保吞吐量不會出現大幅下降，同時平滑往返時延也不會顯著超出最小往返時延，因此吞吐量和平滑往返時延兩個指標均比BBR更穩定。

在實際應用中，擁塞控制算法動態切換技術能夠顯著提升網絡傳輸的效率和可靠性。以全球數據分發為例，不同地區的網絡條件差異顯著：部分海外國家網絡限速嚴重，而另一些地區則擁有高速專線。借助動態切換技術，數據中心能夠根據實時網絡狀況，自適應地為不同用戶選擇合適的擁塞控制算法（如BBR或CUBIC），確保數據分發的效率與穩定性。此外，該機制還可應用于移動網絡等場景，尤其是在網絡波動頻繁的情況下，傳統單一算法難以兼顧低延遲與高吞吐量要求，導致卡頓或畫質下降。例如在視頻直播場景中，通過動態切換算法，視頻直播系統能夠為不同用戶實時調整傳輸策略，在保證流暢性的同時提升畫質。

未來的研究方向包括深入探討更多擁塞控制算法與其他算法的動態切換效果，以及在動態切換機制中考慮用戶體驗質量（qualityofexperience，QoE）指標，以全面提升網絡傳輸性能和用戶滿意度。

4結束語

本文針對有線網絡環境，提出了一種基于QUIC的擁塞控制算法動態切換機制，以適應不斷變化的網絡條件。本文主要圍繞監測器、選擇器、切換器三個核心組件展開。相比已有工作，本文新增考慮接收端可用緩沖區大小以適應對端不同配置，同時進一步研究了sRTT選擇時機、探測階段擁塞控制算法選擇、Btlbuf探測方法等監測器調控因素；此外，本文在有線網絡的大量場景下對比了BBR和CUBIC的吞吐表現，并結合BBR和CUBIC的特性提出了從BBR到CUBIC的平滑切換方法。

參考文獻：

[1]YanFY，MaJ，HillGD，etal.Pantheon：the training ground forInternet congestion-control research [C]/′ Proc of USENIX Annual Technical Conference.Berkeley：USENIX Association，2O18：731-743.

[2]蔣萬春，李昊陽，陳晗瑜，等．網絡擁塞控制方法綜述［J]．軟 件學報，2024，35（8）：3952-3979.（JiangWanchun，LiHaoyang， ChenHanyu，et al．Survey on network congestion control algorithms [J].Journal ofSoftware，2024，35（8）：3952-3979.）

[3]Chen Kefan，Shan Danfeng，Luo Xiaohui，et al.One rein to rule themall：a framework for datacenter-to-user congestion control[C]// Proc of the 4th Asia-Pacific Workshop on Networking.New York： ACMPress，2020：44-51.

[4]Zhou Jianer，Qiu Xinyi，Li Zhenyu，et al.A machine learning-based framework fordynamic selection ofcongestioncontrol algorithms[J]. IEEE/ACM Transon Networking，2023，31（4）：1566-1581.

[5]Zhang Jia，ZhangYixuan，Dong Enhuan，etal.Bridging the gap betweenQoEandQoSin congestion control：a large-scale mobileWeb service perspective[C]//Proc of USENIX Annual Technical Conference.Berkeley：USENIX Association，2023：553-569.

[6]LangleyA，Riddoch A，Wilk A，et al．TheQUIC transport protocol： designand Internet-scaledeployment[C]//Proc ofConference of the ACMSpecial Interest Group on Data Communication.New York： ACMPress，2017：183-196.

[7]Mishra A，Lim S，Leong B. Understanding speciation in QUIC congestion control[C]// Proc of the 22nd ACM Internet Measurement Conference.NewYork：ACMPress，2022：560-566.

[8]MishraA，LeongB.Containing the Cambrian explosion inQUIC congestion control[C]//Proc of ACM Conference on Internet Measurement.New York：ACM Press，2023：526-539.

[9]Cook S，Mathieu B，TruongP，et al.QUIC：better for what and for whom？[C]//Proc of IEEE International Conference on Communications.Piscataway，NJ：IEEE Press，2O17：1-6.

[10]Puliafito C，ConfortiL，VirdisA，et al.Server-sideQUIC connection migration to support microservice deployment at the edge[J]. Pervasive and Mobile Computing，2022，83：101580.

[11]Buchet A，PelsserC.An analysis ofQUIC connection migrationin the wild[EB/OL].（2024-10-08）.htps：//arxiv.org/abs/2410. 06066.

[12]Zirngibl J，Buschmann P，Sattler P，et al.It’s over 90oO：analyzing earlyQUIC deployments with the standardization on the horizon [C]//Proc of the21st ACM Internet Measurement Conference.New York：ACM Press，2021：261-275.

[13] Zirngibl J，Gebauer F，Sattler P，et al. QUIC hunter：finding QUIC deploymentsand identifying server libraries across the Internet[M]// RichterP，BajpaiV，CarisimoE.Passive and ActiveMeasurement. Cham：Springer，2024：273-290.

[14]Zhou Mengying，Chen Yang，Lin Shihan，et al.Dissecting the applicability of HTTP/3 in content delivery networks[C]//Proc of the 44th International Conference on Distributed Computing Systems.Piscataway，NJ：IEEE Press，2024：936-946.

[15]Winstein K，Balakrishnan H. TCP ex machina：computer-generated congestion control[ J]. ACM SIGCOMM Computer Communication Review，2013，43（4）：123-134.

[16]Dong Mo，Li Qingxi，Zarchy D，et al.PCC：re-architecting congestioncontrol forconsistent high performance[C]//Proc of the 12th USENIX Symposium on Networked Systems Design and Implementation.Berkeley：USENIX Association，2015：395-408.

[17]Dong Mo，Meng Tong，ZarchyD，et al.PCC vivace：online-learning congestioncontrol[C]//Proc of the 15th USENIX Symposiumon Networked Systems Design and Implementation. Berkeley：USENIX Association，2018：343-356.

[18]Meng Tong，SchiffNR，GodfreyPB，et al.PCC proteus：scavenger transport and beyond[C]//Proc of Annual Conference of ACM Special Interest Group on Data Communication on the Applications， Technologies，Architectures，and Protocols for Computer Communication.NewYork：ACM Press，2020：615-631.

[19]Abbasloo S，Yen C Y，Chao HJ. Classic meets modern：a pragmatic learning-based congestion control for the Internet[C]//Proc of Annual ConferenceofACMSpecial Interest GrouponData Communicationon the Applications，Technologies，Architectures，and Protocolsfor Computer Communication.New York：ACM Press，2020： 632-647.

[20]JayN，Rotman N，Godfrey B，et al.A deep reinforcement learning perspective on internet congestion control[C]//Proc of International Conference on Machine Learning. New York：PMLR，2019：3050-3059.

[21]KumarG，Dukkipati N，JangK，etal.Swift：delayis simple andeffective for congestion control in the datacenter[C]//Proc of Annual Conference of ACM Special Interest Group on Data Communication on Applications，Technologies，Architectures，and Protocols for Computer Communication. New York：ACM Press，2020：514-528.

[22]Arun V，Balakrishnan H. Copa：practical{delay-based}congestion control for the Internet[C]//Proc of the15th USENIX Symposium on Networked Systems Design and Implementation.Berkeley：USENIX Association，2018：329-342.

[23] CardwellN， Cheng Y，Gunn C S，et al.BBR：congestion-based congestion control[J]. Communications of the ACM，2017，60（2）： 58-66.

[24]HaS，RheeI，Xu Lisong.CUBIC：a new TCP-friendly high-speed TCP variant[J].ACM SIGOPS Operating Systems Review， 2008，42（5）： 64-74.

[25]Du Zhuoxuan，Zheng Jiaqi，Yu Hebin，et al.A unified congestion control framework for diverse application preferences and network conditions[C]//Proc of the 17th International Conferenceon Emerging Networking Experimentsand Technologies. New York：ACM Press， 2021： 282-296.

[26]王潔．自適應擁塞控制：經典算法和機器學習的融合研究［D]. 長沙：中南大學，2023.（Wang Jie.Adaptive congestion control： research on the fusion of classcal algorithms and machine learning [D].Changsha：Central South University，2023.）

[27] Cao Yi， Jain A， Sharma K，et al.When to use and when not to use BBR：an empirical analysis and evaluation study[C]//Proc of InternetMeasurementConference.NewYork：ACMPress，2019：130-136.

[28]Datt S，Fund F. Replication：when to use and when not to use BBR [C]//Proc ofACM on Internet Measurement Conference.New York：ACM Press，2023：30-35.

[29]Tencent.TQUIC[EB/OL].（2024-12-16）.https：//github.com/ Tencent/tquic.

[30]Litespeedtech.LSQUIC[EB/OL].（2024-12-16）． https：// github.com/litespeedtech/lsquic.

[31]Litespeedtech.QUIC.cloud.[EB/OL].（2024-12-16）．https：// www.quic.cloud.