2024年4月底，USENIX Annual Technical Conference（ATC）發(fā)布最新錄用結(jié)果。作為計(jì)算機(jī)系統(tǒng)領(lǐng)域的頂級學(xué)術(shù)會議（CCF-A），USENIX ATC 2024吸引了來自不同領(lǐng)域的488篇論文投稿，最終精選出77篇具有代表性的論文。這些論文涵蓋了虛擬化、系統(tǒng)和網(wǎng)絡(luò)故障管理、云和邊緣計(jì)算、移動和無線技術(shù)等廣泛的研究領(lǐng)域。

其中，騰訊云架構(gòu)平臺部應(yīng)用框架組 TQUIC(https://github.com/Tencent/tquic)團(tuán)隊(duì)結(jié)合長期的開發(fā)和實(shí)踐經(jīng)驗(yàn)， 并與南方科技大學(xué)李清老師開展前沿研究探索，提出了一種更高效的 QUIC 流量轉(zhuǎn)發(fā)框架 QDSR。高動態(tài)內(nèi)容請求和不斷增長的下行中繼轉(zhuǎn)發(fā)服務(wù)使得7層 QUIC 轉(zhuǎn)發(fā)工作負(fù)載過大，導(dǎo)致運(yùn)營成本上升和端到端服務(wù)質(zhì)量下降。為了解決這一問題，QDSR 采用了 QUIC 和直接服務(wù)器返回（Direct Server Return，DSR）技術(shù)，使得真實(shí)服務(wù)器能夠同時直接向客戶端發(fā)送數(shù)據(jù)，消除了傳統(tǒng)七層過重的冗余中繼轉(zhuǎn)發(fā)。因此，QDSR 不僅僅實(shí)現(xiàn)了高性能、低延遲，并且?guī)缀跸祟~外的下行鏈路中繼開銷，為云服務(wù)提供商提供了一種創(chuàng)新且高效的解決方案。此項(xiàng)論文受到了 USENIX ATC 2024高度認(rèn)可并被錄用。

01

研究動因及技術(shù)解析

   1.1 研究背景與動機(jī)

廣泛使用的 Load Balancer(LB)利用了工作在應(yīng)用層(L7)的反向代理，可以實(shí)現(xiàn)連接級甚至請求級的細(xì)粒度控制，其內(nèi)容感知功能使其能夠?qū)崿F(xiàn)更高級功能，如安全保護(hù)、支持粘著重定向等。對于云服務(wù)提供商而言，優(yōu)化最終用戶體驗(yàn)至關(guān)重要，這包括降低延遲、提高吞吐量、縮短網(wǎng)頁加載時間等等。例如，HTTP/2實(shí)現(xiàn)了流的多路復(fù)用，HTTP/3 則采用 QUIC 替代 TCP 以實(shí)現(xiàn)更佳的并行性能，即用戶可以同時生成多個請求來加速網(wǎng)頁加載，但遺憾的是，七層的負(fù)載能力和并行性往往難以達(dá)到理想的平衡。典型的七層負(fù)載技術(shù)是 Proxy-based，如下圖所示。LB 負(fù)責(zé)維護(hù)與客戶端的連接狀態(tài)，并將連接劃分為請求粒度，然后，它將來自不同 RS（Real Server）請求的資源整合，并轉(zhuǎn)發(fā)給客戶端。就功能而言，由于 LB 中包含大量控制信息和潛在的攻擊風(fēng)險，將上行流量進(jìn)行過濾和中繼是有充分理由的，然而，將下行流量再次處理則顯得冗余。大量無意義的下行中繼會導(dǎo)致其迅速成為性能瓶頸，進(jìn)而降低了吞吐量和端到端延遲。

解決冗余轉(zhuǎn)發(fā)問題的典型方案是 DSR (Direct Server Return)技術(shù)，該技術(shù)允許 RS 直接與客戶端建立數(shù)據(jù)傳輸通道。目前網(wǎng)絡(luò)中較為成熟的 DSR 技術(shù)實(shí)踐是 DSR-TCP 方案，如下圖所示。然而，由于沒有比 TCP 中的連接更細(xì)粒度的上下文(與 QUIC 中的流相比)，這意味著同時只有一個 RS 可以為一個連接同時向客戶端發(fā)送資源，使得 HTTP/2和 HTTP/3中多個 HTTP 請求的復(fù)用幾乎不可能在一個連接中有效工作。我們稱之為 DSR-TCP 的串行請求困境(serial request dilemma)。此外，這種 DSR-TCP 方案將整個傳輸狀態(tài)直接交給 RS，包括 TCP 連接移交和 TLS 狀態(tài)移交，使 RS 直接暴露在廣域網(wǎng)上，很容易直接受到攻擊。

為了解決 L7 LB 負(fù)載能力與并行性之間的矛盾，本論文提出了一種基于 QUIC 和 DSR 的高性能、高性價比的 QUIC 流量轉(zhuǎn)發(fā)框架 QDSR。通過 QUIC 和 DSR 技術(shù)的結(jié)合，QDSR 的細(xì)粒度請求處理方法可以同時平衡負(fù)載和并行性，如下圖所示。然而，QDSR 的設(shè)計(jì)旨在解決以下挑戰(zhàn)：

并行傳輸與安全：QDSR 使用流切換代替連接切換，實(shí)現(xiàn)了對同一個連接的多個請求流的并行處理。同時，為了避免廣域網(wǎng)對 RS 的直接攻擊，我們設(shè)計(jì)了一種異構(gòu)的上行/下行鏈路結(jié)構(gòu)，使得廣域網(wǎng)的攻擊無法直接到達(dá) RS。

保持連接一致性：保留LB的上行控制能力，會導(dǎo)致控制與數(shù)據(jù)分離，這給保持連接一致性帶來挑戰(zhàn)。為了解決這一問題，QDSR 和每個 RS 之間建立了輔助長連接，通過長連接以特殊的形式交換控制信息。QDSR 保證了分離的控制和數(shù)據(jù)能力不違反連接的一致性，保證了客戶端的透明傳輸。

包號空間隔離：由于RS不知道共享同一連接的其他 RS，因此不同 RS 的數(shù)據(jù)包之間可能會發(fā)生包序號沖突。由于路徑的異構(gòu)性，簡單的預(yù)分配包號會導(dǎo)致包亂序和不必要的重傳。為了解決該問題，本文提出了流包號空間隔離，其靈感來自多路徑 QUIC 的包號空間管理。該方法允許每個 RS 獨(dú)立地分配分包號，并通過輔助長連接交換分配信息。

   1.2 QDSR 技術(shù)架構(gòu)解析

基于上文提到的問題和挑戰(zhàn)，QDSR 的設(shè)計(jì)原則是：

1. 為高效實(shí)現(xiàn)數(shù)據(jù)傳輸，RS 直接打通和客戶端之間的單向數(shù)據(jù)傳輸隧道，使下行流量不再需要進(jìn)行二次轉(zhuǎn)發(fā)。
2. 為確保客戶端體驗(yàn)的連貫性，多個 RS 應(yīng)能同時響應(yīng)客戶端發(fā)出的多個請求，同時，客戶端對服務(wù)端的變化應(yīng)保持無感知，如同客戶端始終在和LB通信一樣。
3. 為確保通信過程中的連接一致性，LB 和 RS 之間應(yīng)靈活地交換連接和流狀態(tài)信息，以避免潛在的通訊異常。
4. 為確保安全性，所有上行流量必須先經(jīng)過處理與轉(zhuǎn)發(fā)，防止 RS 直接暴露于廣域網(wǎng)中，從而遭受惡意攻擊。

因此，QDSR 的架構(gòu)主要由重定向和傳輸兩個階段組成，具體技術(shù)實(shí)現(xiàn)如下圖所示：

總結(jié)來說，當(dāng)客戶端建立 QUIC 連接之后，QDSR 會根據(jù)流 ID 將其組裝成 HTTP 請求并根據(jù)負(fù)載均衡策略選擇一個真實(shí)服務(wù)器 RS 處理該請求，并通過其和 RS 之間的重定向長連接將請求內(nèi)容轉(zhuǎn)發(fā)給相應(yīng)的 RS。RS 接收到相應(yīng)的HTTP請求后，會將其重新解碼為 QUIC 連接狀態(tài)，并模擬該 QUIC 連接與客戶端之間構(gòu)建單向數(shù)據(jù)傳輸隧道。由于一個 QUIC 連接中包含多個 QUIC 流，所以同一個 QUIC 連接的請求可以被多個 RS 共享，最終形成了多個 RS 為一個客戶端服務(wù)的多對一傳輸過程。

當(dāng)客戶端收到來自于 RS 的數(shù)據(jù)后，會以 MPQUIC ACK_MP 幀的格式返回ACK。由于目前的客戶端并不知道他們的數(shù)據(jù)直接來自于 RS，所以他們依舊會向 LB 發(fā)送 ACK 信息，收到 ACK 信息后，會根據(jù) CID 分配表查找相應(yīng)的 RS，并將解密后的ACK_MP幀轉(zhuǎn)發(fā)到相應(yīng)的 RS 上。所以，RS 發(fā)送的數(shù)據(jù)包的傳輸環(huán)路由 LB、RS 和客戶端組成，RS 利用 MPQUIC 的包空間隔離機(jī)制，實(shí)現(xiàn)了不亂序的并行請求服務(wù)。

我們分別在真實(shí)場景和 Mahimahi 仿真場景中進(jìn)行了測試，結(jié)果如下圖所示：

實(shí)驗(yàn)結(jié)果表明，相比于傳統(tǒng)方案，QDSR 可以額外處理4.8%-18.5%的客戶端請求，當(dāng) LB 成為瓶頸后，QDSR 可以獲得相比于傳統(tǒng)基于代理的方案12.2倍以上的吞吐并顯著降低端到端時延和首包時延。

02

論文評價

   2.1 QDSR 影響力

QDSR 收到了來自 ATC 審稿人和學(xué)術(shù)委員會的一致好評和關(guān)注，以4434的較高分?jǐn)?shù)被 ATC 接收。

多位審稿人對 QDSR 的設(shè)計(jì)出發(fā)點(diǎn)、解決的問題以及良好的工程實(shí)現(xiàn)給予了肯定（摘錄）：

"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......”

   2.2 最后

目前，QDSR 大規(guī)模落地應(yīng)用需要客戶端支持多路徑 QUIC 或支持包空間隔離。隨著多路徑研究的推廣和發(fā)展，未來客戶端支持多路徑是必然的趨勢。TQUIC 開源項(xiàng)目(GitHub - Tencent/tquic: A high-performance, lightweight, and cross-platform QUIC library  地址：https://github.com/Tencent/tquic）結(jié)合 EdgeOne 的動態(tài)加速網(wǎng)絡(luò)，為不同業(yè)務(wù)場景提供了多種可選的多路徑調(diào)度算法與客戶端集成。我們也將繼續(xù)推動 QDSR 在業(yè)界的大規(guī)模部署及應(yīng)用。

本工作受22-23年度犀牛鳥基礎(chǔ)平臺技術(shù)專項(xiàng)研究計(jì)劃支持

-End-

????歡迎加入騰訊云開發(fā)者社群，享前沿資訊、大咖干貨，找興趣搭子，交同城好友，更有鵝廠招聘機(jī)會、限量周邊好禮等你來~

（長按圖片立即掃碼）