首先介紹了QUIC多進程部署架構，隨后分析了QUIC網絡架構在生產應用中遇到的問題及其優(yōu)化方案。在性能提升方面，分享了QUIC全鏈路埋點監(jiān)控的實現(xiàn)思路及其收獲，QUIC擁塞控制算法開發(fā)與調優(yōu)思路等等。希望這些內容能夠幫助大家了解QUIC協(xié)議及其在實際應用中的優(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）多路復用：QUIC允許在單個連接上并行傳輸多個數(shù)據(jù)流，解決了TCP的隊頭阻塞問題，從而提高了傳輸效率；

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

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

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

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

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

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

1.2 QUIC高可用及性能提升

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

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

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

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

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

QUIC應用場景拓展：

• 支持攜程旅行App和商旅海外App接入QUIC，國內用戶和商旅用戶在海外場景下網絡成功率和性能大幅提升

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

二、QUIC網絡架構升級

2.1 容器化改造

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

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

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

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

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

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

容器化后的前期我們使用Consul作為QUIC Server的注冊中心，Server會在k8s提供的生命周期函數(shù)postStart和preStop中分別調用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的調用，故障Server無法在Consul中摘除自身ip，導致QUIC SLB無法感知到Server的下線，因此QUIC SLB的nginx.conf中依舊會保留故障的Server ip，這種情況在Nginx做TCP代理和UDP代理時所產生的影響不同：

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

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

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

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

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

2.3 推拉結合方式提升客戶端用戶側網絡容災能力

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

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

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

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

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

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

在完成QUIC網絡架構升級之后，只依靠上述日志體系遇到了下面兩類問題：

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

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

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

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

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

三、全鏈路埋點

3.1 落地實踐

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

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

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

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

3.1.2 改造服務端nginx源碼

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

1）連接生命周期時間線

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

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

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

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

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

4）用戶信息

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

3.2 分析挖掘

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

3.2.1 0-rtt連接存活時間異常，導致重復請求問題

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

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

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

兩者都會影響連接的關閉，其中c->read定時器存在續(xù)命邏輯，會隨著連接生命周期內，請求的不斷發(fā)生而刷新定時器。qc->close在源碼中不存在續(xù)命邏輯，有且僅有一處刪除邏輯，即在執(zhí)行ngx_quic_handle_datagram()函數(shù)過程中，若完成了ssl初始化，則調用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定時器設置之前，所以導致qc->close不能被正常移除，從而導致max_idel_timeout時間一到，連接立即關閉的現(xiàn)象；

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

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

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

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

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

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

經過Cronet升級及相關適配性改造，對線上升級前后版本進行對比，升級后用戶側95線請求耗時降低了18%。

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

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

四、擁塞控制算法探索

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

4.1 擁塞控制算法簡介

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

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

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

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

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

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

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

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

五、成果與展望

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

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

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

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

4）支持了攜程旅行App和商旅海外App接入QUIC，國內用戶和商旅用戶在海外場景下網絡成功率和性能也大幅提升；

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

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