首先介紹了QUIC多進程部署架構(gòu)，隨后分析了QUIC網(wǎng)絡(luò)架構(gòu)在生產(chǎn)應(yīng)用中遇到的問題及其優(yōu)化方案。在性能提升方面，分享了QUIC全鏈路埋點監(jiān)控的實現(xiàn)思路及其收獲，QUIC擁塞控制算法開發(fā)與調(diào)優(yōu)思路等等。希望這些內(nèi)容能夠幫助大家了解QUIC協(xié)議及其在實際應(yīng)用中的優(yōu)化思路，并從中獲得啟發(fā)。

一、前言

1.1 QUIC在Trip.com APP的落地簡介

QUIC（Quick UDP Internet Connections）是由Google提出的基于UDP的傳輸層協(xié)議，為HTTP3的標準傳輸層協(xié)議。相較于TCP協(xié)議，QUIC主要具備以下優(yōu)勢：

1）多路復(fù)用：QUIC允許在單個連接上并行傳輸多個數(shù)據(jù)流，解決了TCP的隊頭阻塞問題，從而提高了傳輸效率；

2）快速建連：新建連時，QUIC握手與TLS握手并行，避免了TLS單獨握手所消耗的1個RTT時延。當用戶連接過期失效且在PSK(pre-shared key)有效期內(nèi)再次建連時，QUIC通過驗證PSK復(fù)用TLS會話，實現(xiàn)0-RTT建聯(lián)，從而可以更快的建立連接，此特性在短連接，單用戶低頻請求的場景中收益尤為明顯；

3）連接遷移：TCP通過四元組標識一個連接，當四元組中的任一部分發(fā)生變化時，連接都會失效。而QUIC通過連接CID唯一標識一個連接，當用戶網(wǎng)絡(luò)發(fā)生切換(例如WIFI切換到4G)時，QUIC依然可以通過CID找到連接，完成新路徑驗證繼續(xù)保持連接通信，避免重新建連帶來的耗時；

4）擁塞控制：TCP的擁塞控制需要操作系統(tǒng)的支持，部署成本高，升級周期長，而QUIC在應(yīng)用層實現(xiàn)擁塞控制算法，升級變更加靈活；

上述優(yōu)質(zhì)特性推動了QUIC協(xié)議在IETF的標準化發(fā)展，2021年5月，IETF推出了QUIC的標準化版本RFC9000，我們于2022年完成了QUIC多進程部署方案在Trip.com APP的落地，支持了多進程下的連接遷移和0-RTT特性，最終取得了Trip.com App鏈路耗時縮短20%的收益，大大的提升了海外用戶的體驗。我們的初期網(wǎng)絡(luò)架構(gòu)如下：

其中有兩個重要組成部分，QUIC SLB和QUIC Server：

• QUIC SLB工作在傳輸層，具有負載均衡能力，負責接收并正確轉(zhuǎn)發(fā)UDP數(shù)據(jù)包至Server。當用戶進行網(wǎng)絡(luò)切換，導(dǎo)致連接四元組發(fā)生變化時，SLB通過從連接CID中提取Server端的ip+port來實現(xiàn)數(shù)據(jù)包的準確轉(zhuǎn)發(fā)，從而支持連接遷移功能；
• QUIC Server工作在應(yīng)用層，是QUIC協(xié)議的主要實現(xiàn)所在，負責轉(zhuǎn)發(fā)及響應(yīng)客戶端請求，通過Server集群共享ticket_key方案實現(xiàn)0-RTT功能；

1.2 QUIC高可用及性能提升

隨著全球旅游業(yè)的復(fù)蘇，攜程在國內(nèi)外的業(yè)務(wù)迎來了成倍的增長，業(yè)務(wù)體量越來越龐大，QUIC作為Trip.com APP的主要網(wǎng)絡(luò)通道，其重要性不言而喻。為了更好地應(yīng)對日益增長的流量，更穩(wěn)定地支持每一次用戶請求的送達，我們建立了QUIC高可用及性能提升的目標，最終完成了以下優(yōu)化內(nèi)容：

QUIC集群及鏈路高可用優(yōu)化：

• 完成QUIC Server容器化改造，具備了HPA能力，并定制化開發(fā)了適用于QUIC場景的HPA指標
• 優(yōu)化QUIC網(wǎng)絡(luò)架構(gòu)，具備了QUIC Server的主動健康監(jiān)測及動態(tài)上下線能力
• 通過推拉結(jié)合的策略，有效提升了客戶端App容災(zāi)能力，實現(xiàn)網(wǎng)絡(luò)通道和入口ip秒級切換
• 搭建了穩(wěn)定可靠的監(jiān)控告警體系

QUIC成功率及鏈路性能提升：

• 支持QUIC全鏈路埋點，使QUIC運行時數(shù)據(jù)更加透明化
• 通過優(yōu)化擁塞控制算法實現(xiàn)了鏈路性能的進一步提升
• 通過多Region部署縮短了歐洲用戶20%的鏈路耗時
• 客戶端Cronet升級，網(wǎng)絡(luò)請求速度提升明顯

QUIC應(yīng)用場景拓展：

• 支持攜程旅行App和商旅海外App接入QUIC，國內(nèi)用戶和商旅用戶在海外場景下網(wǎng)絡(luò)成功率和性能大幅提升

下文將詳細的介紹這些優(yōu)化內(nèi)容。

二、QUIC網(wǎng)絡(luò)架構(gòu)升級

2.1 容器化改造

改造前我們統(tǒng)一使用VM部署QUIC SLB和QUIC Server，具體部署流程如下：

QUIC實踐早期我們經(jīng)常需要在機器上執(zhí)行自定義操作，這種部署方案的優(yōu)點是比較靈活。但隨著QUIC服務(wù)端功能趨于穩(wěn)定，以及業(yè)務(wù)流量的日益增長，此方案部署時間長、不支持動態(tài)擴縮容的弊端日益顯現(xiàn)。為了解決以上問題，我們對QUIC SLB以及QUIC Server進行了容器化改造：

• QUIC Server承載了QUIC協(xié)議處理以及用戶http請求轉(zhuǎn)發(fā)這兩項核心功能，我們將其改造成了容器鏡像，并接入到內(nèi)部Captain發(fā)布系統(tǒng)中，支持了灰度發(fā)布，版本回退等功能，降低了發(fā)布帶來的風險，同時具備了HPA能力，擴縮容時間由分鐘級縮短到秒級

• QUIC SLB作為外網(wǎng)入口，主要負責用戶UDP包的轉(zhuǎn)發(fā)，負載較小，對流量變化不敏感。并且由于需要Akamai加速，QUIC SLB需要同時支持UDP以及TCP協(xié)議，當前容器是無法支持雙協(xié)議的外網(wǎng)入口的。因此我們將QUIC SLB改造成了虛擬機鏡像，支持在PaaS上一鍵擴容，大大降低了部署成本

2.2 服務(wù)發(fā)現(xiàn)與主動健康監(jiān)測

在QUIC SLB中，我們使用Nginx作為4層代理，實現(xiàn)QUIC UDP數(shù)據(jù)包的轉(zhuǎn)發(fā)以及連接遷移能力。

容器化后的前期我們使用Consul作為QUIC Server的注冊中心，Server會在k8s提供的生命周期函數(shù)postStart和preStop中分別調(diào)用Consul的注冊和刪除API，將自身ip在Consul中注冊或摘除。QUIC SLB會監(jiān)聽Consul中ip的變化，從而及時感知到每個Quic Server的狀態(tài)，并實時更新到Nginx的配置文件中，這樣就實現(xiàn)了QUIC Server的自動注冊與發(fā)現(xiàn)。

但在實際演練場景中，我們發(fā)現(xiàn)當直接對QUIC Server注入故障時，由于Server所在pod并沒有被銷毀，因此不會觸發(fā)preStop API的調(diào)用，故障Server無法在Consul中摘除自身ip，導(dǎo)致QUIC SLB無法感知到Server的下線，因此QUIC SLB的nginx.conf中依舊會保留故障的Server ip，這種情況在Nginx做TCP代理和UDP代理時所產(chǎn)生的影響不同：

• 當Nginx做TCP代理時，Nginx與故障Server之間建立的是TCP連接，Server故障時TCP連接會斷開，Nginx會與故障Server重新建聯(lián)但最終失敗，此時會自動將其拉出一段時間，并每隔一段時間進行探測，直至其恢復(fù)，從而避免了TCP數(shù)據(jù)包轉(zhuǎn)發(fā)至錯誤的Server，不會導(dǎo)致服務(wù)成功率下降；
• 當Nginx做UDP代理時，由于UDP是無連接的，QUIC SLB依舊會轉(zhuǎn)發(fā)數(shù)據(jù)包至故障Server，但SLB不會收到任何響應(yīng)數(shù)據(jù)包，由于UDP協(xié)議特性，此時QUIC SLB不會判定Server為異常，從而持續(xù)大量的UDP包被轉(zhuǎn)發(fā)到故障Server實例上，導(dǎo)致QUIC通道的成功率大幅下降；

經(jīng)過上述分析，我們知道了使用UDP進行健康監(jiān)測存在一定弊端，期望使用TCP協(xié)議對QUIC Server進行主動的健康檢測。所以開啟了新方案的探索，其需要同時支持UDP數(shù)據(jù)轉(zhuǎn)發(fā)，基于TCP協(xié)議的主動健康監(jiān)測，支持服務(wù)發(fā)現(xiàn)與注冊，并且能夠較好的適配QUIC SLB層。

調(diào)研了很多方案，其中較適配的是開源的Nginx UDP Health Check項目，其同時支持UDP數(shù)據(jù)包轉(zhuǎn)發(fā)和TCP的主動健康檢測，但是其不支持nginx.conf中下游ip的動態(tài)變更，也就是不支持QUIC Server的動態(tài)上下線，這直接影響了Server集群的HPA能力，因此舍棄了這個方案。

最終通過調(diào)研發(fā)現(xiàn)公司內(nèi)部的L4LB組件，既能同時支持TCP的主動健康檢測和UDP數(shù)據(jù)包轉(zhuǎn)發(fā)，還支持實例的動態(tài)上下線，完美適配我們的場景，因此最終采用了L4LB作為QUIC SLB和QUIC Server之間的轉(zhuǎn)發(fā)樞紐。

具體實現(xiàn)是為QUIC Server的每個group申請一個UDP的內(nèi)網(wǎng)L4LB入口ip，這些ip是固定不變的，那么對于QUIC SLB來說只需要將UDP數(shù)據(jù)包轉(zhuǎn)發(fā)至固定的虛擬ip即可。L4LB開啟TCP的健康檢測功能，這樣當group中的QUIC Server實例故障時，健康檢測失敗，L4LB就會將此實例拉出，后續(xù)UDP包就不會再轉(zhuǎn)發(fā)到此實例上，直至實例再次恢復(fù)到健康狀態(tài)。這樣就完美解決了QUIC Server的自動注冊與主動健康監(jiān)測功能。

2.3 推拉結(jié)合方式提升客戶端用戶側(cè)網(wǎng)絡(luò)容災(zāi)能力

Trip.com App的網(wǎng)絡(luò)請求框架同時支持QUIC/TCP/HTTP 三通道能力，其中80%以上的用戶請求都是通過QUIC通道訪問服務(wù)器的，日均流量達到數(shù)億，在現(xiàn)有的多通道/多IP切換能力的基礎(chǔ)上，進一步提升容災(zāi)能力顯得尤為重要。于是我們設(shè)計了一套推拉結(jié)合的策略方案，結(jié)合公司配置系統(tǒng)實現(xiàn)了秒級通道/IP切換。下面是簡化過程：

在客戶端App啟動和前后臺切換等場景，根據(jù)變動情況獲取最新的配置，網(wǎng)絡(luò)框架基于最新的配置進行無損通道或IP的切換。

同時當用戶APP處于前臺活躍狀態(tài)時，通過對用戶進行主動的配置更新推送，讓在線用戶可以立即感知到變化并切換至最新的網(wǎng)絡(luò)配置上面，且此切換過程對用戶是無感的。

這樣一來，我們的QUIC客戶端網(wǎng)絡(luò)框架進一步提升了容災(zāi)能力，當某個IP發(fā)生故障時，可以在秒級通知所有用戶切離故障IP，當某通道發(fā)生異常時，用戶亦可以無感的切換至優(yōu)質(zhì)通道，而不會受到任何影響。

2.4 監(jiān)控告警穩(wěn)定性保證及彈性擴縮容指標建設(shè)

QUIC數(shù)據(jù)監(jiān)控系統(tǒng)的穩(wěn)定性，對于故障預(yù)警、故障響應(yīng)起到至關(guān)重要的作用。通過將埋點數(shù)據(jù)寫至access log和error log來完成QUIC運行時埋點數(shù)據(jù)的輸出，再通過logagent將服務(wù)器本地的日志數(shù)據(jù)發(fā)送至Kafka，隨后Hangout消費并解析，將數(shù)據(jù)落入Clickhouse做數(shù)據(jù)存儲及查詢，這給我們做運行時數(shù)據(jù)觀察及數(shù)據(jù)分析提供了很大的便利性。

在完成QUIC網(wǎng)絡(luò)架構(gòu)升級之后，只依靠上述日志體系遇到了下面兩類問題：

第一，在應(yīng)用場景下，單純依靠這部分數(shù)據(jù)做監(jiān)控告警，偶發(fā)由于某些中間環(huán)節(jié)出現(xiàn)波動導(dǎo)致監(jiān)控告警不準確， 例如Hangout消費者故障導(dǎo)致流量驟降或突增的假象，這可能會影響監(jiān)控告警的及時性和準確性；

第二，容器化之后具備了彈性擴縮容能力，而HPA依賴于擴縮容數(shù)據(jù)指標，僅僅使用CPU、內(nèi)存利用率等資源指標，無法充足的反映QUIC服務(wù)器狀態(tài)。根據(jù)QUIC服務(wù)特性，仍需要自定義一些HPA數(shù)據(jù)指標，例如空閑連接占比，空閑端口號占比等，以建立更合理、更穩(wěn)定的擴縮容依賴；

基于上述兩方面的考量，在經(jīng)過調(diào)研之后，我們將Nginx與Prometheus進行整合，支持了關(guān)鍵數(shù)據(jù)指標、擴縮容數(shù)據(jù)指標通過Prometheus上報的方案。在Nginx中預(yù)先對成功率，耗時，可用連接數(shù)等等重要指標進行了聚合，只上報聚合數(shù)據(jù)指標，從而大大縮小了數(shù)據(jù)體量，使Nginx整合Prometheus的影響可以忽略不計。另外我們支持了空閑連接占比，空閑端口號占比等等HPA指標，使QUIC集群在流量高峰期，能夠非常準確迅速的完成系統(tǒng)擴容，在低流量時間段，也能夠縮容至適配狀態(tài)，以最大程度的節(jié)約機器資源。

這樣一來，QUIC系統(tǒng)的監(jiān)控告警數(shù)據(jù)來源同時支持Prometheus和Clickhouse，Prometheus側(cè)重關(guān)鍵指標及聚合數(shù)據(jù)的上報，Clickhouse側(cè)重運行時明細數(shù)據(jù)的上報，兩者相互配合互為補充。

在支持Prometheus過程中我們遇到了較多依賴項的版本搭配導(dǎo)致的編譯問題，以nginx/1.25.3版本為例，給出版本匹配結(jié)果：

三、全鏈路埋點

3.1 落地實踐

我們基于優(yōu)化用戶鏈路耗時，尋找并優(yōu)化耗時短板的目標出發(fā)，開始抽樣分析耗時較久的請求，并根據(jù)所需，在服務(wù)端access.log中逐漸添加了較多的數(shù)據(jù)埋點，nginx官方對單個http請求維度的數(shù)據(jù)埋點支持性較好，但僅僅分析單個請求維度的信息，難以看清請求所屬連接的各類數(shù)據(jù)，仍需要觀察用戶連接所處網(wǎng)絡(luò)環(huán)境，握手細節(jié)，數(shù)據(jù)傳輸細節(jié)，擁塞情況等等數(shù)據(jù)，來協(xié)助對問題進行定位。

QUIC客戶端之前僅有端到端的整體埋點數(shù)據(jù)，并且存在QUIC埋點體系和現(xiàn)有體系mapping的問題，我們收集過濾Cronet metrics的信息，整合進現(xiàn)有埋點體系內(nèi)。

3.1.1 收集過濾QUIC客戶端Cronet Metrics埋點數(shù)據(jù)

端到端流程支持了DNS、TLS握手、請求發(fā)送、響應(yīng)返回等環(huán)節(jié)細粒度的埋點，QUIC端到端各環(huán)節(jié)數(shù)據(jù)一目了然。

3.1.2 改造服務(wù)端nginx源碼

我們在連接創(chuàng)建到連接銷毀的全生命周期內(nèi)進行了詳細的數(shù)據(jù)埋點，另外通過連接CID實現(xiàn)了連接級別埋點和請求級別埋點數(shù)據(jù)的串聯(lián)，這對進行問題定位，性能優(yōu)化等提供了可靠的數(shù)據(jù)支持。下面分類列舉了部分服務(wù)端全鏈路埋點，并簡要概述了其用途：

1）連接生命周期時間線

連接類型(1-rtt/0-rtt)，連接創(chuàng)建時間(Server收到Client第一個數(shù)據(jù)包的時間)，連接發(fā)送第一個數(shù)據(jù)包的時間，連接收到第一個ack幀的時間，連接握手耗時，連接收到及發(fā)送cc幀(Connection Close Frame)的時間，連接無響應(yīng)超時時間，連接銷毀時間等等；這一類埋點主要幫助我們理清用戶連接生命周期中的各個關(guān)鍵時間點，以及握手相關(guān)的耗時細節(jié)。

2）數(shù)據(jù)傳輸細節(jié)

(以下皆為連接生命周期內(nèi))發(fā)送和接收字節(jié)、數(shù)據(jù)包、數(shù)據(jù)幀總數(shù)，包重傳率，幀重傳率等等。這類數(shù)據(jù)幫助分析我們的數(shù)據(jù)傳輸特性，對鏈路傳輸優(yōu)化，擁塞控制算法調(diào)整提供數(shù)據(jù)參考。

3）RTT(Round-trip time)和擁塞控制數(shù)據(jù)

平滑RTT，最小RTT，首次和最后一次RTT，擁塞窗口大小，最大in_flight，慢開始閾值，擁塞recovery_start時間等等。這些數(shù)據(jù)可用來分析用戶網(wǎng)絡(luò)狀況，觀察擁塞比例，評估擁塞控制算法合理性等等。

4）用戶信息

客戶端ip，國家及地區(qū)等。這幫助我們對用戶數(shù)據(jù)進行區(qū)域級別的聚合分析，找到網(wǎng)絡(luò)傳輸?shù)膮^(qū)域性差異，以進行一些針對性優(yōu)化。

3.2 分析挖掘

通過合并聚合各類數(shù)據(jù)埋點，實現(xiàn)了QUIC運行時數(shù)據(jù)可視化透明化，這也幫助我們發(fā)現(xiàn)了諸多問題及優(yōu)化項，下面列舉幾項進行詳述：

3.2.1 0-rtt連接存活時間異常，導(dǎo)致重復(fù)請求問題

通過篩選0-rtt類型的連接，我們觀察到此類連接的存活總時間，恰好等于QUIC客戶端和服務(wù)端協(xié)商之后的max_idel_timeout，而max_idel_timeout的準確定義為”連接無響應(yīng)（客戶端服務(wù)端無任何數(shù)據(jù)交互）超時關(guān)閉時間“，也就是說正常情況下，當一個連接上最后一次http請求交互完畢之后，若經(jīng)過max_idel_timeout時間仍未發(fā)生其他交互時，連接會進入關(guān)閉流程；當連接上不斷的有請求交互時，連接的存活時間必定大于max_idel_timeout(實際連接存活時間 = 最后一次請求數(shù)據(jù)傳輸完成時間 - 連接創(chuàng)建時間 + max_idel_timeout)。

為了論證上述現(xiàn)象，我們通過連接的dcid，關(guān)聯(lián)篩選出0-rtt連接生命周期中所有http請求列表，發(fā)現(xiàn)即使連接上的請求在不斷的進行，0-rtt連接仍然會在存活了max_idel_timeout時無條件關(guān)閉，所以斷定0-rtt連接的續(xù)命邏輯存在問題。我們對nginx-quic源碼進行閱讀分析，最終定位并及時修復(fù)了問題代碼：

在源碼ngx_quic_run()函數(shù)中，存在兩個連接相關(guān)的定時器：

兩者都會影響連接的關(guān)閉，其中c->read定時器存在續(xù)命邏輯，會隨著連接生命周期內(nèi)，請求的不斷發(fā)生而刷新定時器。qc->close在源碼中不存在續(xù)命邏輯，有且僅有一處刪除邏輯，即在執(zhí)行ngx_quic_handle_datagram()函數(shù)過程中，若完成了ssl初始化，則調(diào)用ngx_quic_do_init_streams()進行qc->close定時器的刪除操作；

• 若為1-rtt建聯(lián)，第一次執(zhí)行ngx_quic_handle_datagram()函數(shù)不會完成ssl初始化，所以qc->close的創(chuàng)建發(fā)生在ssl初始化完畢之前，在后續(xù)數(shù)據(jù)包交互過程中能夠正常完成刪除邏輯；
• 若為0-rtt建聯(lián)，第一次執(zhí)行ngx_quic_handle_datagram()函數(shù)會完成ssl初始化邏輯，所以僅一次的刪除邏輯，發(fā)生在了qc->close定時器設(shè)置之前，所以導(dǎo)致qc->close不能被正常移除，從而導(dǎo)致max_idel_timeout時間一到，連接立即關(guān)閉的現(xiàn)象；

這個bug除了導(dǎo)致較多無效0-rtt新建連之外，在我們的應(yīng)用場景下，經(jīng)過對全鏈路埋點數(shù)據(jù)聚合分析發(fā)現(xiàn)，還會導(dǎo)致重復(fù)請求問題，下面介紹發(fā)生重復(fù)請求的原因：

quic client發(fā)起某個request的第一次請求，quic server端收到并轉(zhuǎn)發(fā)給后端應(yīng)用，在server收到后端應(yīng)用response之前，恰好qc->close定時器到期，導(dǎo)致server立即向client發(fā)送cc幀，client在收到cc幀后，按照quic協(xié)議應(yīng)無條件立即關(guān)閉當前連接，所以client認為第一次請求失敗，從而發(fā)起新建連，開始第二次請求，從而導(dǎo)致重復(fù)請求問題。而這個過程從客戶端業(yè)務(wù)角度來說只請求了一次，但后端應(yīng)用卻連續(xù)收到兩次一模一樣的請求，這對于冪等性要求較高的接口影響較大。

我們在2024年2月發(fā)現(xiàn)并修復(fù)了上述定時器bug，修復(fù)之后連接復(fù)用比例提升0.5%，不必要的0-rtt建連比例降低7%。目前nginx-quic官方分支于2024/04/10也提交了對此問題的修復(fù)，Commit鏈接：https://hg.nginx.org/nginx-quic/rev/155c9093de9d

3.2.2 客戶端App Cronet升級給95線用戶帶來體驗提升

經(jīng)過數(shù)據(jù)分析發(fā)現(xiàn)，長尾用戶在0-RTT上占比不高，大多為1-RTT新建連接，經(jīng)過分析判斷可能和QUIC客戶端Cronet裁剪有關(guān)。Trip.com App上Cronet庫在優(yōu)化前使用的是2020年的舊版本，并且由于包大小問題對其進行了裁剪（比如：重構(gòu)了PSK相關(guān)邏輯，轉(zhuǎn)為session級別），在保留關(guān)鍵功能的前提下盡可能剔除了無用代碼十幾萬行。同時經(jīng)過與其他Cronet使用方溝通，得到Cronet升級后有不錯的性能提升表現(xiàn)，于是時隔近四年，客戶端對Cronet庫進行了一次大升級。

另外，由于Chromium官方在2023年11月份官宣不再提供iOS的Cli工具，所以此次升級目標就定位選一個盡可能靠近官方刪除iOS構(gòu)建工具之前的版本，最終我們選定了 120.0.6099.301。

經(jīng)過Cronet升級及相關(guān)適配性改造，對線上升級前后版本進行對比，升級后用戶側(cè)95線請求耗時降低了18%。

3.2.3 Nginx-quic分支中擁塞控制算法實現(xiàn)具有較大的優(yōu)化空間

通過對nginx-quic源碼的研究以及鏈路埋點的數(shù)據(jù)分析，我們發(fā)現(xiàn)源碼中的擁塞控制算法為Reno算法的簡化版，初始傳輸窗口設(shè)置較大為131054字節(jié)(若mtu為1200，初始就有109個包可以同時傳輸)。若發(fā)生擁塞事件，降窗的最小值仍為131054字節(jié)，在網(wǎng)絡(luò)較好時，網(wǎng)絡(luò)公平性不友好，在網(wǎng)絡(luò)較差時，這會加劇網(wǎng)絡(luò)擁堵。在發(fā)現(xiàn)此問題后，我們開始著手改造源碼中的擁塞控制算法邏輯，這一優(yōu)化內(nèi)容將在第四部分詳述。

四、擁塞控制算法探索

nginx-quic官方分支中，對于擁塞控制算法的實現(xiàn)目前仍處于demo級別，我們結(jié)合QUIC在應(yīng)用層實現(xiàn)擁塞控制算法而不依賴于操作系統(tǒng)的特性，對Nginx官方代碼中擁塞控制相關(guān)邏輯進行了抽象重構(gòu)，以方便拓展各種算法，并支持了可配置式的擁塞控制算法切換，可以根據(jù)不同的網(wǎng)絡(luò)狀況，不同的server業(yè)務(wù)場景配置不同的擁塞控制算法。

4.1 擁塞控制算法簡介

目前主流的擁塞控制算法大抵可分為兩類，一類是根據(jù)丟包做響應(yīng)，如Reno、Cubic，一類是根據(jù)帶寬和延遲反饋做響應(yīng)，如BBR系列。這里簡要介紹下Reno，Cubic和BBR的工作原理，適用場景及優(yōu)缺點：

1）Reno算法是TCP最早的擁塞控制算法之一，基于丟包的擁塞控制機制。它使用兩個閾值（慢啟動閾值和擁塞避免閾值）來控制發(fā)送速率。在慢啟動階段，發(fā)送方每經(jīng)過一個往返時間（RTT），就將擁塞窗口大小加倍。一旦出現(xiàn)擁塞，會觸發(fā)擁塞避免階段，發(fā)送速率會緩慢增長。當發(fā)生丟包時，發(fā)送方會認為發(fā)生了擁塞，將擁塞窗口大小減半；適用于低延時、低帶寬的場景，對于早期互聯(lián)網(wǎng)環(huán)境比較適用。其優(yōu)點是簡單直觀，易于理解和實現(xiàn)。缺點是對網(wǎng)絡(luò)變化反應(yīng)較慢，可能導(dǎo)致網(wǎng)絡(luò)利用率不高，且在丟包率較高時性能不佳。

2）Cubic算法在Reno算法的基礎(chǔ)上進行改進，利用網(wǎng)絡(luò)往返時間（RTT）和擁塞窗口的變化率來計算擁塞窗口的大小，使用擬立方函數(shù)來模擬網(wǎng)絡(luò)的擁塞狀態(tài)，并根據(jù)擁塞窗口的大小和時間來調(diào)整擁塞窗口的增長速率。適用于中度丟包率的網(wǎng)絡(luò)環(huán)境，對于互聯(lián)網(wǎng)主流環(huán)境有較好的性能表現(xiàn)。優(yōu)點是相對于Reno算法，能更好地適應(yīng)網(wǎng)絡(luò)變化，提高網(wǎng)絡(luò)利用率。缺點是在高丟包率或長肥管道環(huán)境下，發(fā)送窗口可能會迅速收斂到很小，導(dǎo)致性能下降。

3）BBR（Bottleneck Bandwidth and RTT）算法是Google開發(fā)的一種擁塞控制算法，通過測量網(wǎng)絡(luò)的帶寬和往返時間來估計網(wǎng)絡(luò)的擁塞程度，并根據(jù)擁塞程度調(diào)整發(fā)送速率。BBR算法的特點是能夠更精確地估計網(wǎng)絡(luò)的擁塞程度，避免了過度擁塞和欠擁塞的情況，提高了網(wǎng)絡(luò)的傳輸速度和穩(wěn)定性。適用于高帶寬、高延時或中度丟包率的網(wǎng)絡(luò)環(huán)境。優(yōu)點是能夠更精確地控制發(fā)送速率，提高網(wǎng)絡(luò)利用率和穩(wěn)定性。缺點是可能占用額外的CPU資源，影響性能，且在某些情況下可能存在公平性問題。

4.2 優(yōu)化實現(xiàn)及收益

源碼中有關(guān)擁塞控制邏輯的代碼分散在各處功能代碼中，未進行抽象統(tǒng)一管理，我們通過梳理擁塞控制算法響應(yīng)事件，將各個事件函數(shù)抽象如下：

我們基于上述抽象結(jié)構(gòu)，先后實現(xiàn)了目前主流的擁塞控制算法Reno，Cubic及BBR，并且我們根據(jù)埋點數(shù)據(jù)對擁塞控制算法進行了參數(shù)和邏輯調(diào)優(yōu)，包括設(shè)置合理的初始窗口和最小窗口，設(shè)置最優(yōu)的擁塞降窗邏輯等等，這些調(diào)整會引起包重發(fā)率和連接擁塞率的數(shù)據(jù)變化，而這些數(shù)據(jù)變化皆會影響到鏈路傳輸性能。

我們通過對QUIC擁塞控制算法的優(yōu)化，SHA環(huán)境連接擁塞比例降低了15個點，實現(xiàn)了SHA端到端耗時降低4%的收益。后續(xù)將繼續(xù)基于Trip.com的數(shù)據(jù)傳輸特性，根據(jù)每個IDC的不同網(wǎng)絡(luò)狀況進行適應(yīng)性定制化開發(fā)，并通過長期的AB實驗，探索每個IDC下最優(yōu)的擁塞控制邏輯。

五、成果與展望

我們不斷的優(yōu)化QUIC鏈路性能，不斷的提升QUIC通道穩(wěn)定性，旨在為Trip.com日益增長的業(yè)務(wù)提供優(yōu)質(zhì)的網(wǎng)絡(luò)服務(wù)，同時我們也在不斷的探索支持更多的QUIC應(yīng)用場景。

1）通過容器化改造，將擴縮容由手動改為自動，擴縮容時間縮短30倍，在20s內(nèi)就能拉起并上線大批服務(wù)器；

2）通過開發(fā)全鏈路埋點，聚合分析出了較多優(yōu)化項，修復(fù)0-rtt連接問題，連接復(fù)用比例提升0.5%，優(yōu)化擁塞控制算法，端到端耗時縮短4%；

3）通過在FRA(法蘭克福)部署QUIC集群，降低了歐洲用戶耗時20%以上，提高了網(wǎng)絡(luò)成功率0.5%以上；

4）支持了攜程旅行App和商旅海外App接入QUIC，國內(nèi)用戶和商旅用戶在海外場景下網(wǎng)絡(luò)成功率和性能也大幅提升；

5）客戶端升級Cronet之后，綜合上述優(yōu)化項，用戶側(cè)端到端整體耗時95線降低18%；

Trip.com在QUIC上的探索將持續(xù)的進行，我們將密切關(guān)注社區(qū)動態(tài)，探索支持更多的QUIC應(yīng)用場景，挖掘更多的優(yōu)化項目，為攜程國際化戰(zhàn)略貢獻力量。