基于QUIC的擁塞控制算法動(dòng)態(tài)切換機(jī)制

關(guān)鍵詞：擁塞控制；動(dòng)態(tài)切換；QUIC；網(wǎng)絡(luò)質(zhì)量探測(cè)

中圖分類號(hào)：TP319 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：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引言

在數(shù)字化浪潮下，社交、在線辦公、高清視頻等多元網(wǎng)絡(luò)應(yīng)用不斷涌現(xiàn)，對(duì)數(shù)據(jù)傳輸?shù)母咝院头€(wěn)定性提出了更高要求。傳輸層作為銜接應(yīng)用層與網(wǎng)絡(luò)層的紐帶，處于網(wǎng)絡(luò)分層架構(gòu)的關(guān)鍵位置。然而，傳統(tǒng)TCP擁塞控制難以適應(yīng)復(fù)雜多變的網(wǎng)絡(luò)環(huán)境，不能滿足新型業(yè)務(wù)需求，且由于位于系統(tǒng)內(nèi)核空間，難以實(shí)現(xiàn)優(yōu)化調(diào)整?，F(xiàn)有研究表明，不同擁塞控制算法在各種網(wǎng)絡(luò)環(huán)境下表現(xiàn)差異顯著[1]，當(dāng)前也沒有一種擁塞控制算法能夠適用所有網(wǎng)絡(luò)場(chǎng)景[2]。但是，在實(shí)際應(yīng)用中，服務(wù)提供者通常采用默認(rèn)的擁塞控制算法，且在連接的全生命周期內(nèi)維持不變。因此，當(dāng)應(yīng)用服務(wù)接入的網(wǎng)絡(luò)條件隨時(shí)間、地域持續(xù)動(dòng)態(tài)變化時(shí)，這一機(jī)制將無法獲得最佳的傳輸性能[3＼～5]

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

QUIC協(xié)議作為TCP的升級(jí)方案，被越來越多的網(wǎng)絡(luò)應(yīng)用采用，其擁塞控制算法作為傳輸協(xié)議的核心模塊被業(yè)界廣泛關(guān)注。與TCP擁塞控制算法部署在系統(tǒng)內(nèi)核空間不同，QUIC的擁塞控制以模塊化的方式運(yùn)行在用戶空間，這帶來了諸多優(yōu)勢(shì)：首先，這使得最新的算法能更便捷地部署到不同的操作系統(tǒng)和真實(shí)的網(wǎng)絡(luò)環(huán)境，促進(jìn)了算法的檢驗(yàn)和創(chuàng)新；其次，這有助于根據(jù)不同的網(wǎng)絡(luò)場(chǎng)景和應(yīng)用需求來進(jìn)行精細(xì)化的算法調(diào)控，更好地適應(yīng)各種復(fù)雜多變的網(wǎng)絡(luò)環(huán)境。

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

相較之下，關(guān)于擁塞控制算法動(dòng)態(tài)切換的研究展現(xiàn)出顯著優(yōu)勢(shì)。這些經(jīng)典擁塞控制算法往往是針對(duì)特定優(yōu)化目標(biāo)和網(wǎng)絡(luò)場(chǎng)景進(jìn)行建模的，比如：Westwood算法能精準(zhǔn)應(yīng)對(duì)Wi-Fi場(chǎng)景下的信號(hào)波動(dòng)；Swift算法2則在低延遲、高吞吐場(chǎng)景中表現(xiàn)突出，契合數(shù)據(jù)中心網(wǎng)絡(luò)大規(guī)模數(shù)據(jù)傳輸需求;Copa算法[22]在實(shí)時(shí)視頻流傳輸場(chǎng)景中能有效減少視頻卡頓，提升吞吐量。因此，針對(duì)特定目標(biāo)和網(wǎng)絡(luò)場(chǎng)景切換合適的擁塞控制算法，既能規(guī)避學(xué)習(xí)機(jī)制算法的短板，又能達(dá)到理想的傳輸效果。

關(guān)于擁塞控制算法動(dòng)態(tài)切換的研究目前仍處于起步階段，如何結(jié)合QUIC優(yōu)勢(shì)來充分提高擁塞控制算法動(dòng)態(tài)切換的性能，仍需解決以下問題：

a）研究場(chǎng)景覆蓋不足。 Floo^[5] 只研究了移動(dòng)網(wǎng)絡(luò)下的動(dòng)態(tài)調(diào)整，對(duì)局域網(wǎng)、數(shù)據(jù)中心間高速網(wǎng)絡(luò)等場(chǎng)景的研究尚存在空白。

b）指標(biāo)探測(cè)精度差。瓶頸鏈路網(wǎng)絡(luò)條件、應(yīng)用層指標(biāo)等的探測(cè)準(zhǔn)確程度將影響選擇策略的有效性。然而，探測(cè)效果又受到諸多因素影響，包括探測(cè)周期、探測(cè)階段的擁塞控制算法選擇等。

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

1 研究現(xiàn)狀

1.1相關(guān)工作

為解決靜態(tài)配置擁塞控制算法引發(fā)的性能瓶頸問題，當(dāng)前開展的研究方向按照基本原理可以分為基于學(xué)習(xí)機(jī)制的擁塞控制算法、融合建模和學(xué)習(xí)機(jī)制的擁塞控制算法、擁塞控制算法動(dòng)態(tài)切換三類。

a）基于學(xué)習(xí)機(jī)制的擁塞控制算法將網(wǎng)絡(luò)環(huán)境視為黑盒子，不需要對(duì)網(wǎng)絡(luò)進(jìn)行假設(shè)和精確建模。Remy[15]首次將人工智能技術(shù)應(yīng)用到擁塞控制領(lǐng)域，通過離線訓(xùn)練直接生成從網(wǎng)絡(luò)狀態(tài)到限速規(guī)則的映射模型。之后，基于在線優(yōu)化的PCC系列[16＼～18]、基于深度強(qiáng)化學(xué)習(xí)的 Orca^[19] 、Aurora[20]被陸續(xù)提出。但這類研究面臨訓(xùn)練復(fù)雜、收斂振蕩或緩慢、開銷大等難題。

b）融合建模和學(xué)習(xí)機(jī)制的擁塞控制算法的主要思想是結(jié)合兩者的優(yōu)點(diǎn)重新設(shè)計(jì)一個(gè)統(tǒng)一的擁塞控制框架。Libra[25]是最早研究該方向的工作，但其強(qiáng)化學(xué)習(xí)模型需要調(diào)整很多參數(shù)，面對(duì)未訓(xùn)練的場(chǎng)景，其公平性和收斂性仍面臨挑戰(zhàn)。Seagull[26]只吸收CUBIC思想進(jìn)行融合改進(jìn)。

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

1.2創(chuàng)新點(diǎn)

盡管現(xiàn)有研究已經(jīng)對(duì)有線網(wǎng)絡(luò)環(huán)境的擁塞控制表現(xiàn)、擁塞控制算法切換兩個(gè)方面作出了重要貢獻(xiàn)，但這些研究通常是孤立進(jìn)行的。本文的目的是填補(bǔ)這一空自。通過實(shí)驗(yàn)和對(duì)結(jié)果的深入分析，本文提出一種新的擁塞控制算法動(dòng)態(tài)切換機(jī)制，充分利用QUIC在擁塞控制方面的優(yōu)勢(shì)，并針對(duì)有線網(wǎng)絡(luò)環(huán)境特性進(jìn)行優(yōu)化設(shè)計(jì)。本文的主要?jiǎng)?chuàng)新點(diǎn)如下：

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

b）精準(zhǔn)探測(cè)網(wǎng)絡(luò)指標(biāo)。探測(cè)階段有很多因素影響網(wǎng)絡(luò)條件的探測(cè)精度，比如瓶頸鏈路帶寬和平滑往返時(shí)延的記錄時(shí)間會(huì)對(duì)瓶頸鏈路緩沖區(qū)的估計(jì)造成很大影響，從而影響算法切換的決策。已有相關(guān)研究并未展開討論。為此，本文提出了瓶頸鏈路緩沖區(qū)的精準(zhǔn)探測(cè)方法。

c）平滑切換算法。針對(duì)CUBIC等丟包敏感的擁塞控制算法，為了兼顧快速收斂和性能穩(wěn)定兩個(gè)優(yōu)化目標(biāo)，本文提出一種BBR到CUBIC的擁塞控制算法平滑切換方法。

2擁塞控制算法動(dòng)態(tài)切換機(jī)制

基于QUIC的擁塞控制算法動(dòng)態(tài)切換框架主要包含監(jiān)測(cè)器、選擇器、切換器三個(gè)核心組件。圖1展示了擁塞控制算法動(dòng)態(tài)切換工作流程：監(jiān)測(cè)器針對(duì)每條連接，周期性地采集網(wǎng)絡(luò)指標(biāo)及兩端協(xié)商參數(shù)，并將相關(guān)數(shù)據(jù)信息傳輸至選擇器；選擇器基于所接收的數(shù)據(jù)信息，為每條連接匹配最適合的擁塞控制算法；切換器在切換擁塞控制算法的同時(shí)，還負(fù)責(zé)平滑轉(zhuǎn)換擁塞控制狀態(tài)，以此構(gòu)建起一套高效、穩(wěn)健的擁塞控制算法動(dòng)態(tài)切換機(jī)制。

2.1 監(jiān)測(cè)器

監(jiān)測(cè)器模塊需要統(tǒng)計(jì)的指標(biāo)和網(wǎng)絡(luò)狀態(tài)如表2所示，這些數(shù)據(jù)主要從CRYPTO幀、ACK幀以及本地QUIC連接信息中獲取。

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

Floo使用式（3）估算瓶頸鏈路緩沖區(qū)（bottlenecklinkbuffer，Btlbuf）。本文通過實(shí)驗(yàn)發(fā)現(xiàn)這種探測(cè)方法與真實(shí)情況存在偏差。

Btlbuf=（sRTT-minRTT）×Btlbw

監(jiān)測(cè)器的探測(cè)階段有很多調(diào)控因素，具體而言：切換周期（switchingperiod，SP）過短會(huì)導(dǎo)致無意義的擁塞控制算法頻繁切換，也不利于準(zhǔn)確感知網(wǎng)絡(luò)條件，而切換周期過長將對(duì)算法適應(yīng)網(wǎng)絡(luò)條件變化的響應(yīng)速度產(chǎn)生影響；另外，探測(cè)階段使用不同原理的擁塞控制算法，會(huì)導(dǎo)致從狀態(tài)機(jī)估算出的網(wǎng)絡(luò)指標(biāo)存在偏差；更重要的是，F(xiàn)loo并未明確Btlbw和sRTT的探測(cè)時(shí)機(jī)，這很大程度決定了Btlbuf的探測(cè)準(zhǔn)確程度。本文通過實(shí)驗(yàn)，將式（3）估算Btlbuf產(chǎn)生的具體問題總結(jié)如下：

a）SP過短導(dǎo)致Btlbuf估計(jì)過小。實(shí)驗(yàn)設(shè)置Rcvbuf為100MB、Btlbuf為 10MB 、Btlbw為750Mbit/s、RTT為 100ms SP為1s。若到達(dá)SP時(shí)統(tǒng)計(jì)sRTT，估算的Btlbuf遠(yuǎn)小于實(shí)際值。通過觀察sRTT在1＼～3s的變化曲線可知，由于鏈路時(shí)延較大，ACK到達(dá)發(fā)送端速度慢，導(dǎo)致sRTT更新緩慢，無法反映Btlbuf滿載時(shí)的網(wǎng)絡(luò)時(shí)延，最終使得估算的Btlbuf過小。所以，為確保發(fā)送端在各種網(wǎng)絡(luò)環(huán)境下都能準(zhǔn)確測(cè)量Btlbuf，需設(shè)置更大的 sp 0

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

c）BDP遠(yuǎn)小于Btlbuf導(dǎo)致Btlbuf估計(jì)過小。實(shí)驗(yàn)設(shè)置Rcvbuf為100MB、Btlbuf為10MB、SP為12s。實(shí)驗(yàn)結(jié)果表明，估算出的Btlbuf遠(yuǎn)小于實(shí)際值。BBR旨在將發(fā)送數(shù)據(jù)量逼近BDP，但在某些網(wǎng)絡(luò)場(chǎng)景中，Btlbuf遠(yuǎn)大于BDP，導(dǎo)致BBR無法填滿中間鏈路緩沖區(qū)，從而低估Btlbuf的大小。為了規(guī)避由于網(wǎng)絡(luò)條件BDP限制導(dǎo)致的緩沖區(qū)深淺判定錯(cuò)誤，本文給出瓶頸鏈路緩沖區(qū)公式，如式（4）所示。若切換周期內(nèi)未發(fā)生丟包，則表明BDP小于Btlbuf，此時(shí)中間鏈路緩沖區(qū)為深緩沖區(qū)；若切換周期內(nèi)發(fā)生丟包，則按原公式計(jì)算緩沖區(qū)大小。

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

2.2 選擇器

在本文中，選擇器的優(yōu)化目標(biāo)是選出最適合當(dāng)前網(wǎng)絡(luò)條件的擁塞控制算法，以提升網(wǎng)絡(luò)吞吐量。為實(shí)現(xiàn)這一目標(biāo)，本文首先在有線網(wǎng)絡(luò)環(huán)境的大量場(chǎng)景中，對(duì)BBR和CUBIC兩種擁塞控制算法的吞吐量進(jìn)行詳盡測(cè)量，并指定擁塞控制算法選擇規(guī)則。

本文測(cè)試了QUIC不同擁塞控制算法的吞吐表現(xiàn)，并利用式（5）評(píng)估了BBR相對(duì)于CUBIC的吞吐增益百分比，具體實(shí)驗(yàn)方法見3.1節(jié)。

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

a）在淺Btlbuf、深Rcvbuf網(wǎng)絡(luò)環(huán)境中，式（6）成為BBR優(yōu)于CUBIC、BBR，差于CUBIC兩個(gè)區(qū)域的大致分界線，本文實(shí)驗(yàn)條件下 k 取近似值3。

BDP=k×Btlbuf

b）在淺Btlbuf網(wǎng)絡(luò)環(huán)境中，Rcvbuf的深淺程度對(duì)熱力分布影響不大，并非主要因素。

c）在深Btlbuf網(wǎng)絡(luò)環(huán)境中，Rcvbuf的深淺程度對(duì)熱力分布影響很大。具體而言，在淺Rcvbuf情況下，BBR在超過 95% 的網(wǎng)絡(luò)條件中表現(xiàn)均優(yōu)于CUBIC，且剩余 5% 的網(wǎng)絡(luò)條件下吞吐表現(xiàn)絕對(duì)值差異均很小，本文直接選擇BBR;而在深Rcvbuf情況下，在大BDP網(wǎng)絡(luò)條件中CUBIC的表現(xiàn)反而相比BBR有較大優(yōu)勢(shì)。

另外，考慮深Btlbuf、深Rcvbuf網(wǎng)絡(luò)環(huán)境中，當(dāng)Btlbw ?20 Mbit/s時(shí)，監(jiān)測(cè)器始終無法精確探測(cè)瓶頸鏈路帶寬，選擇器通過切換周期內(nèi)是否丟包來進(jìn)一步優(yōu)化切換策略。具體算法如下所示。

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

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

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

c） a ccflag=CUBIC 執(zhí)行后轉(zhuǎn)步驟r）。

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

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

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

g） accflag Σ=Σ CUBIC。執(zhí)行后轉(zhuǎn)步驟r）。

h） end if

i） end for

j） else 瓶頸鏈路深緩沖區(qū)條件 * /

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

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

m） accflag τ=τ CUBIC。執(zhí)行后轉(zhuǎn)步驟r）。

n） end if

0） end for

p） endif

q）end if

r）return accflag

2.3 切換器

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

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

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

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

2.4算法復(fù)雜度分析

本文擁塞控制算法動(dòng)態(tài)切換機(jī)制的時(shí)間復(fù)雜度為 O（1） 0

證明擁塞控制算法動(dòng)態(tài)切換機(jī)制主要由監(jiān)測(cè)、選擇、切換三個(gè)階段構(gòu)成。

a）監(jiān)測(cè)階段的時(shí)間復(fù)雜度。監(jiān)測(cè)器定期記錄網(wǎng)絡(luò)狀態(tài)變量，并使用式（2）（4）來估計(jì)瓶頸鏈路網(wǎng)絡(luò)指標(biāo)，上述操作時(shí)間復(fù)雜度都是 O（1） 。

b）選擇階段的時(shí)間復(fù)雜度。結(jié)合圖2可知，BBR表現(xiàn)優(yōu)于（差于）CUBIC的網(wǎng)絡(luò)條件存在明顯的區(qū)域分界，因此本文選擇器采用規(guī)則判斷方法，無須復(fù)雜的計(jì)算或迭代，算法1中的循環(huán)條件判斷復(fù)雜度是常數(shù)級(jí)別。因此，該階段的時(shí)間復(fù)雜度為 O（1） 。

c）切換階段的時(shí)間復(fù)雜度。切換算法通過統(tǒng)計(jì)過去一段時(shí)間內(nèi)的cwnd平均值來支持決策。為了保證較低的計(jì)算開銷并在動(dòng)態(tài)網(wǎng)絡(luò)環(huán)境中快速響應(yīng)，統(tǒng)計(jì)的cwnd數(shù)量通常被限制為常數(shù)級(jí)別，因此該階段的時(shí)間復(fù)雜度為 O（1） 。

本文所提整體機(jī)制的時(shí)間復(fù)雜度由監(jiān)測(cè)、選擇、切換三個(gè)階段的時(shí)間復(fù)雜度相加構(gòu)成。由于這三個(gè)階段的時(shí)間復(fù)雜度均為 O（1） ，所以，本文提出的擁塞控制算法動(dòng)態(tài)切換機(jī)制的時(shí)間復(fù)雜度為 O（1） 。

3 實(shí)驗(yàn)性能評(píng)估

為了驗(yàn)證擁塞控制算法動(dòng)態(tài)切換機(jī)制的性能，本文搭建了實(shí)驗(yàn)環(huán)境并開展測(cè)試。

3.1 實(shí)驗(yàn)方法

本節(jié)詳細(xì)描述實(shí)驗(yàn)方法，包括實(shí)驗(yàn)平臺(tái)、網(wǎng)絡(luò)場(chǎng)景、QUIC選型、磁盤讀寫、緩沖區(qū)設(shè)置、驗(yàn)證方式等。

a）實(shí)驗(yàn)平臺(tái)。本文復(fù)現(xiàn)了文獻(xiàn)[27，28]中使用的拓?fù)浣Y(jié)構(gòu)，其中發(fā)送端（表示為h1）通過中間節(jié)點(diǎn)（表示為h2）向接收端（表示為h3）發(fā)送數(shù)據(jù)。如圖3所示，拓?fù)渲械乃泄?jié)點(diǎn)采用的都是Linux服務(wù)器，具體配置如下：操作系統(tǒng)為Ubuntu20.04.6LTS（內(nèi)核版本是5.15.0-97-generic），CPU型號(hào)是 Xeon@ CPU E5-2660 v3 @ 2.60 GHz，CPU核數(shù)是40核，網(wǎng)卡型號(hào)是IntelCorporationI35OGigabitNetworkConnection。

b）網(wǎng)絡(luò)場(chǎng)景。實(shí)驗(yàn)過程中，在中間節(jié)點(diǎn)使用流量控制工具TC來設(shè)置網(wǎng)絡(luò)條件：上行鏈路出口（eth1）設(shè)置網(wǎng)絡(luò)延遲（該規(guī)則需要設(shè)置足夠大的隊(duì)列長度，因?yàn)樵诖髸r(shí)延大帶寬條件下，大量ACK可能在該隊(duì)列等待造成隊(duì)列溢出，影響發(fā)送端擁塞控制調(diào)整）;下行鏈路出口（eth2）設(shè)置瓶頸鏈路帶寬和瓶頸鏈路緩沖區(qū)。本文考慮的網(wǎng)絡(luò)條件基本與上述論文保持一致，如表4所示。

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

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

e）驗(yàn)證方式。為驗(yàn)證實(shí)驗(yàn)設(shè)置符合預(yù)期，本文使用ping來驗(yàn)證往返時(shí)延，使用UDP模式下的iperf3來驗(yàn)證瓶頸鏈路帶寬。為驗(yàn)證實(shí)驗(yàn)設(shè)置和QUIC實(shí)現(xiàn)沒有導(dǎo)致QUIC吞吐表現(xiàn)異常，本文使用TCP模式下的iperf3（TCP發(fā)送端和接收端緩沖區(qū)均設(shè)置成100MB）來對(duì)比QUIC吞吐效果。

3.2吞吐量對(duì)比效果與分析

本節(jié)評(píng)估動(dòng)態(tài)切換機(jī)制（adaptive）在不同網(wǎng)絡(luò)場(chǎng)景下的吞吐性能，圖4、5展示了其分別與CUBIC、BBR以及不同網(wǎng)絡(luò)條件下兩者表現(xiàn)最優(yōu)值（best）的對(duì)比結(jié)果，其中藍(lán)色表示adap-tive更差，紅色則表示adaptive更優(yōu)（見電子版）。

1）瓶頸鏈路淺緩沖區(qū)場(chǎng)景

a）實(shí)驗(yàn)結(jié)果。如圖4所示，在超過 87% 的網(wǎng)絡(luò)條件中，本文提出的機(jī)制與CUBIC表現(xiàn)相近或更好 （?-0.1% ），在大BDP網(wǎng)絡(luò)條件下增益明顯;在超過 78% 的網(wǎng)絡(luò)條件中，本文提出的機(jī)制與BBR表現(xiàn)相近或更好（ ），在小BDP網(wǎng)絡(luò)條件下增益明顯；盡管無法在所有網(wǎng)絡(luò)環(huán)境中表現(xiàn)得比最佳值更好，但相比CUBIC和BBR都更能適應(yīng)不同的網(wǎng)絡(luò)條件。

b）原因分析。首先，本文機(jī)制相較于CUBIC在吞吐增益方面提升顯著，接近 28% 的區(qū)域增益達(dá)到 100%～1 000% 。這主要是由于在大BDP和淺Btlbuf的網(wǎng)絡(luò)環(huán)境中，容易發(fā)生丟包，導(dǎo)致對(duì)丟包敏感的CUBIC算法主動(dòng)降低發(fā)送速率；而本文機(jī)制基于BDP探測(cè)值來動(dòng)態(tài)調(diào)控發(fā)送速率，以適度的重傳為代價(jià)，換取了顯著的吞吐量優(yōu)勢(shì)。其次，本文機(jī)制相較于BBR在吞吐增益方面的提升主要集中在小BDP區(qū)域，這主要是由于在小BDP網(wǎng)絡(luò)中，RTT的波動(dòng)較為顯著，BBR的帶寬探測(cè)機(jī)制難以充分發(fā)揮作用，同時(shí)BDP較小，限制了BBR的性能表現(xiàn)；相比之下，本文提出的機(jī)制能夠準(zhǔn)確監(jiān)測(cè)網(wǎng)絡(luò)指標(biāo)，并平滑切換至CUBIC算法，不僅保證了算法在不同網(wǎng)絡(luò)條件下的適應(yīng)性，還顯著提升了吞吐表現(xiàn)的穩(wěn)定性。

2）瓶頸鏈路深緩沖區(qū)場(chǎng)景

a）實(shí)驗(yàn)結(jié)果。如圖5所示，在超過 95% 的網(wǎng)絡(luò)條件中，本文提出的機(jī)制與CUBIC表現(xiàn)相近或更好 （?-0.1% ），在大時(shí)延網(wǎng)絡(luò)條件下增益明顯；在超過 89% 的網(wǎng)絡(luò)條件中，本文提出的機(jī)制與BBR表現(xiàn)相近或更好 （?-0.1% ），在大BDP網(wǎng)絡(luò)條件下增益明顯；另外，相比前面瓶頸鏈路淺緩沖區(qū)實(shí)驗(yàn)結(jié)果，本文所提出的機(jī)制更能適應(yīng)不同網(wǎng)絡(luò)條件的變化，在超過84% 的網(wǎng)絡(luò)條件中與最優(yōu)值表現(xiàn)相近或更好（ ≥-0.1% ），其中，最差相對(duì)表現(xiàn)能控制在 -1% 以內(nèi)，而在大BDP條件下增益明顯。

b）原因分析。當(dāng)瓶頸鏈路緩沖區(qū)深度足夠時(shí)，丟包頻率顯著降低，在大BDP網(wǎng)絡(luò)條件下，CUBIC的表現(xiàn)優(yōu)于BBR。本文提出的機(jī)制可以平滑切換至CUBIC算法，充分利用深緩沖區(qū)的優(yōu)勢(shì)，突破BDP的限制，進(jìn)一步提升發(fā)送速率。此外，在小BDP網(wǎng)絡(luò)條件下，CUBIC與BBR的性能接近，本文提出的機(jī)制將保持原有策略，避免頻繁切換，從而確保傳輸?shù)姆€(wěn)定性。

3.3 穩(wěn)定性效果與分析

a）實(shí)驗(yàn)結(jié)果。本節(jié)對(duì)平滑往返時(shí)間和吞吐量指標(biāo)進(jìn)行歸一化處理，使不同算法或場(chǎng)景之間的比較更加直觀和公平。圖6展示了兩個(gè)指標(biāo)的關(guān)聯(lián)關(guān)系及其穩(wěn)定性表現(xiàn)。三種算法的橢圓都是向右下方傾斜，表示平滑往返時(shí)間和吞吐量呈負(fù)相關(guān)（當(dāng)平滑往返時(shí)間增加時(shí)，吞吐量減少）。本文提出的機(jī)制能夠獲得比其他擁塞控制算法更小的橢圓，這表明其在不同的網(wǎng)絡(luò)條件下具有更好的性能穩(wěn)定性。

b）原因分析。本文提出的機(jī)制的優(yōu)勢(shì)在于其動(dòng)態(tài)切換能力。當(dāng)BBR算法在部分網(wǎng)絡(luò)環(huán)境下表現(xiàn)不佳時(shí)，本文機(jī)制能夠動(dòng)態(tài)切換至CUBIC，從而確保吞吐量不會(huì)出現(xiàn)大幅下降，同時(shí)平滑往返時(shí)延也不會(huì)顯著超出最小往返時(shí)延，因此吞吐量和平滑往返時(shí)延兩個(gè)指標(biāo)均比BBR更穩(wěn)定。

在實(shí)際應(yīng)用中，擁塞控制算法動(dòng)態(tài)切換技術(shù)能夠顯著提升網(wǎng)絡(luò)傳輸?shù)男屎涂煽啃?。以全球?shù)據(jù)分發(fā)為例，不同地區(qū)的網(wǎng)絡(luò)條件差異顯著：部分海外國家網(wǎng)絡(luò)限速嚴(yán)重，而另一些地區(qū)則擁有高速專線。借助動(dòng)態(tài)切換技術(shù)，數(shù)據(jù)中心能夠根據(jù)實(shí)時(shí)網(wǎng)絡(luò)狀況，自適應(yīng)地為不同用戶選擇合適的擁塞控制算法（如BBR或CUBIC），確保數(shù)據(jù)分發(fā)的效率與穩(wěn)定性。此外，該機(jī)制還可應(yīng)用于移動(dòng)網(wǎng)絡(luò)等場(chǎng)景，尤其是在網(wǎng)絡(luò)波動(dòng)頻繁的情況下，傳統(tǒng)單一算法難以兼顧低延遲與高吞吐量要求，導(dǎo)致卡頓或畫質(zhì)下降。例如在視頻直播場(chǎng)景中，通過動(dòng)態(tài)切換算法，視頻直播系統(tǒng)能夠?yàn)椴煌脩魧?shí)時(shí)調(diào)整傳輸策略，在保證流暢性的同時(shí)提升畫質(zhì)。

未來的研究方向包括深入探討更多擁塞控制算法與其他算法的動(dòng)態(tài)切換效果，以及在動(dòng)態(tài)切換機(jī)制中考慮用戶體驗(yàn)質(zhì)量（qualityofexperience，QoE）指標(biāo)，以全面提升網(wǎng)絡(luò)傳輸性能和用戶滿意度。

4結(jié)束語

本文針對(duì)有線網(wǎng)絡(luò)環(huán)境，提出了一種基于QUIC的擁塞控制算法動(dòng)態(tài)切換機(jī)制，以適應(yīng)不斷變化的網(wǎng)絡(luò)條件。本文主要圍繞監(jiān)測(cè)器、選擇器、切換器三個(gè)核心組件展開。相比已有工作，本文新增考慮接收端可用緩沖區(qū)大小以適應(yīng)對(duì)端不同配置，同時(shí)進(jìn)一步研究了sRTT選擇時(shí)機(jī)、探測(cè)階段擁塞控制算法選擇、Btlbuf探測(cè)方法等監(jiān)測(cè)器調(diào)控因素；此外，本文在有線網(wǎng)絡(luò)的大量場(chǎng)景下對(duì)比了BBR和CUBIC的吞吐表現(xiàn)，并結(jié)合BBR和CUBIC的特性提出了從BBR到CUBIC的平滑切換方法。

參考文獻(xiàn)：

[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]蔣萬春，李昊陽，陳晗瑜，等．網(wǎng)絡(luò)擁塞控制方法綜述［J]．軟 件學(xué)報(bào)，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]王潔．自適應(yīng)擁塞控制：經(jīng)典算法和機(jī)器學(xué)習(xí)的融合研究［D]. 長沙：中南大學(xué)，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，F(xiàn)und 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.