2024年4月底，USENIX Annual Technical Conference（ATC）釋出最新錄用結果。作為電腦系統領域的頂級學術會議（CCF-A），USENIX ATC 2024吸引了來自不同領域的488篇論文投稿，最終精選出77篇具有代表性的論文。這些論文涵蓋了虛擬化、系統和網路故障管理、雲和邊緣計算、移動和無線技術等廣泛的研究領域。
其中，騰訊雲架構平台部套用框架組TQUIC(https://github.com/Tencent/tquic)團隊結合長期的開發和實踐經驗， 並與南方科技大學李清老師開展前沿研究探索，提出了一種
更高效的QUIC流量轉發框架QDSR
。
高動態內容請求和不斷增長的下行中繼轉發服務使得7層QUIC轉發工作負載過大，導致營運成本上升和端到端服務品質下降。
為了解決這一問題，QDSR采用了QUIC和直接伺服器返回（Direct Server Return，DSR）技術，使得真實伺服器能夠同時直接向客戶端發送數據，消除了傳統七層過重的冗余中繼轉發。
因此，QDSR不僅僅實作了高效能、低延遲，並且幾乎消除了額外的下行鏈路中繼開銷，為雲服務提供商提供了一種創新且高效的解決方案。
此項論文受到了USENIX ATC 2024高度認可並被錄用。
研究動因及技術解析
研究背景與動機
廣泛使用的Load Balancer(LB)利用了工作在套用層(L7)的反向代理，可以實作連線級甚至請求級的細粒度控制，其內容感知功能使其能夠實作更高級功能，如安全保護、支持粘著重新導向等。
對於雲服務提供商而言，最佳化終端使用者體驗至關重要，這包括降低延遲、提高吞吐量、縮短網頁載入時間等等。
例如，HTTP/2實作了流的多路復用，HTTP/3則采用QUIC替代TCP以實作更佳的並列效能，即使用者可以同時生成多個請求來加速網頁載入，但遺憾的是，七層的負載能力和並列性往往難以達到理想的平衡。
典型的七層負載技術是Proxy-based，如下圖所示。
LB負責維護與客戶端的連線狀態，並將連線劃分為請求粒度，然後，它將來自不同RS（Real Server）請求的資源整合，並轉發給客戶端。
就功能而言，由於LB中包含大量控制資訊和潛在的攻擊風險，將上行流量進行過濾和中繼是有充分理由的，然而，將下行流量再次處理則顯得冗余。
大量無意義的下行中繼會導致其迅速成為效能瓶頸，進而降低了吞吐量和端到端延遲。
解決冗余轉發問題的典型方案是DSR (Direct Server Return)技術，該技術允許RS直接與客戶端建立數據傳輸通道。目前網路中較為成熟的DSR技術實踐是DSR-TCP方案，如下圖所示。然而，由於沒有比TCP中的連線更細粒度的上下文(與QUIC中的流相比)，這意味著同時只有一個RS可以為一個連線同時向客戶端發送資源，使得HTTP/2和HTTP/3中多個HTTP請求的復用幾乎不可能在一個連線中有效工作。我們稱之為DSR-TCP的序列請求困境(serial request dilemma)。此外，這種DSR-TCP方案將整個傳輸狀態直接交給RS，包括TCP連線移交和TLS狀態移交，使RS直接暴露在廣域網路上，很容易直接受到攻擊。
為了解決L7 LB負載能力與並列性之間的矛盾，本論文提出了一種基於QUIC和DSR的高效能、高價效比的QUIC流量轉發框架QDSR。透過QUIC和DSR技術的結合，QDSR的細粒度請求處理方法可以同時平衡負載和並列性，如下圖所示。然而，QDSR的設計旨在解決以下挑戰:
並列傳輸與安全 : QDSR使用流切換代替連線切換，實作了對同一個連線的多個請求流的並列處理。 同時，為了避免廣域網路對RS的直接攻擊，我們設計了一種異構的上行/下行鏈路結構，使得廣域網路的攻擊無法直接到達RS。
保持連線一致性: 保留LB的由下而上的控制能力，會導致控制與數據分離，這給保持連線一致性帶來挑戰。 為了解決這一問題，QDSR和每個RS之間建立了輔助長連線，透過長連線以特殊的形式交換控制資訊。QDSR保證了分離的控制和數據能力不違反連線的一致性，保證了客戶端的透明傳輸。
包號空間隔離: 由於RS不知道共享同一連線的其他RS，因此不同RS的封包之間可能會發生包序號沖突。 由於路徑的異構性，簡單的預分配包號會導致包亂序和不必要的重傳。 為了解決該問題，本文提出了流包號空間隔離，其靈感來自多路徑QUIC的包號空間管理。 該方法允許每個RS獨立地分配分包號，並透過輔助長連線交換分配資訊。
QDSR技術架構解析
基於上文提到的問題和挑戰，QDSR的設計原則是：
1)為高效實作數據傳輸，RS直接打通和客戶端之間的單向數據傳輸隧道，使下行流量不再需要進行二次轉發。
2)為確保客戶端體驗的連貫性，多個RS應能同時響應客戶端發出的多個請求，同時，客戶端對伺服端的變化應保持無感知，如同客戶端始終在和LB通訊一樣。
3)為確保通訊過程中的連線一致性，LB和RS之間應靈活地交換連線和流狀態資訊，以避免潛在的通訊異常。
4)為確保安全性，所有上行流量必須先經過處理與轉發，防止RS直接暴露於廣域網路中，從而遭受惡意攻擊。
因此，QDSR的架構主要由重新導向和傳輸兩個階段組成，具體技術實作如下圖所示：
總結來說，當客戶端建立QUIC連線之後，QDSR會根據流ID將其組裝成HTTP請求並根據負載均衡策略選擇一個真實伺服器RS處理該請求，並透過其和RS之間的重新導向長連線將請求內容轉發給相應的RS。RS接收到相應的HTTP請求後，會將其重新解碼為QUIC連線狀態，並模擬該QUIC連線與客戶端之間構建單向數據傳輸隧道。由於一個QUIC連線中包含多個QUIC流，所以同一個QUIC連線的請求可以被多個RS共享，最終形成了多個RS為一個客戶端服務的多對一傳輸過程。
當客戶端收到來自於RS的數據後，會以MPQUIC ACK_MP幀的格式返回ACK。由於目前的客戶端並不知道他們的數據直接來自於RS，所以他們依舊會向LB發送ACK資訊，收到ACK資訊後，會根據CID分配表尋找相應的RS，並將解密後的ACK_MP幀轉發到相應的RS上。所以，RS發送的封包的傳輸環路由LB、RS和客戶端組成，RS利用MPQUIC的包空間隔離機制，實作了不亂序的並列請求服務。
我們分別在真實場景和Mahimahi仿真場景中進行了測試，結果如下圖所示：
實驗結果表明，相比於傳統方案， QDSR可以額外處理 4.8%-18.5% 的客戶端請求 ，當LB成為瓶頸後， QDSR可以獲得相比於傳統基於代理的方案 12.2 倍以上的吞吐並顯著降低端到端時延和首包時延。
論文評價
QDSR影響力
QDSR收到了來自ATC審稿人和學術委員會的一致好評和關註，以4434的較高分數被ATC接收
多位審稿人對QDSR的設計出發點、解決的問題以及良好的工程實作給予了肯定（摘錄）：
"I thought the core idea was well motivated and neat。It is certainly useful to reduce the meassive bloat and overhead we have introduced in our data centers"
「The paper was discussed at the PC meeting。The reviewers agreed that the paper addresses an important problem and the solution is well-engineered。The reviewers also found the rebuttal provided by the authors......」
最後
目前，QDSR大規模落地套用需要客戶端支持多路徑QUIC或支持包空間隔離。隨著多路徑研究的推廣和發展，未來客戶端支持多路徑是必然的趨勢。TQUIC開源計畫
(
GitHub - Tencent/tquic: A high-performance, lightweight, and cross-platform QUIC library
地址：
https://github.com/Tencent/tquic
）結合 EdgeOne的動態加速網路，為不同業務場景提供了多種可選的多路徑排程演算法與客戶端整合。我們也將繼續推動QDSR在業界的大規模部署及套用。
本工作受22-23年度犀牛鳥基礎平台技術專項研究計劃支持
【相關閱讀】 【正式開源！高效能輕量級跨平台QUIC協定庫TQUIC來啦！】 點選圖片↓↓↓
掃碼添加 「
鵝廠架構師小客服
」 ，加入【
鵝廠架構師圈
】，與技術愛好者、技術關註者分享交流，共同進步成長，歡迎大家！↓↓↓
關於我們
技術分享：關註微信公眾號 【鵝廠架構師】
