6月7日早晨(UTC時間Mon, 06 June 2022 20:09)，HTTP/3 標準RFC9114 由IETF標準化工作組正式釋出，由此QUIC第一代協議族6大基礎標準（不變數/傳輸框架/擁塞控制和恢復/TLS/HTTP3/QPACK壓縮）全部完成RFC化，開啟一段新的網路時代。在淘寶，我們從18年開始嘗試QUIC，到21~22年實現IETF QUIC及HTTP3標準的規模化應用，針對導購和交易核心鏈路場景拿到15~20%的網路耗時優化收益，同時沉澱自研的標準協議庫實現XQUIC，並於年初開源。筆者想借由本文談一談對於網路7層模型中傳輸層的發展方向看法，以及對於底層技術發展過程中可能碰到的困難及問題提出一點可行的建議。

開源倉庫：http://github.com/alibaba/xquic

什麼場景下適合選擇QUIC作為TCP的替代品

今年我們聽到大量的國內外聲音，支援QUIC作為TCP的全面替代品，同時也針對QUIC成為網路傳輸技術新一代的顛覆者，提出支援性的觀點。筆者作為XQUIC(一個包含QUIC和HTTP/3標準實現的協議庫)專案的發起人和持續建設者，雖然立場相關，但是仍然從客觀角度做一下分析。

最近一到兩年也有很多研發者找到XQUIC專案，希望這個專案能一舉解決大家碰到的所有網路問題；筆者的觀點是，這個世界上沒有銀彈，沒有任何技術可以解決所有場景的問題，每一項技術都有它適合的場景和它的侷限性。

那麼到底什麼場景下適合使用QUIC呢？答案是公網傳輸鏈路下，作為TCP的替代品，確實具備理想的優勢 。 我們知道公網的特性是鏈路長（反應在Round-Trip-Time上）、鏈路複雜性高（反應在各個節點可能存在的丟包/排隊及多流的競爭上）、以及手機端常見的無線訊號波動帶來的吞吐量抖動（體現在丟包/亂序上），這些問題的解法都是QUIC的強項領域。而在資料中心內部，在鏈路網路裝置可控的情況下，同時追求低效能開銷與低成本，TCP/DCTCP仍然表現不錯，基於RDMA的一些DC內部解決方案同樣也會具備優勢。

從原理本質上來說，QUIC帶來的最大的原理變化是：將傳輸層從核心態提到使用者態 ， 使得傳輸層可以與應用層進行高度配合，這在過去是無法可想的。這打開了傳輸層對於應用層傳輸需求和傳輸內容理解的天花板，使得傳輸行為與應用層需求高度匹配具備可行性。有人可能會說這有什麼牛逼之處麼？我們知道WebRTC在音影片場景下表現出色，其中一部分關鍵原因就是其RTP的協議傳輸設計和工程實踐，是充分結合音影片內容的傳輸需求和特性來設計的。因此具備使用者態靈活演進的能力，並且能夠貼合應用場景進行傳輸特性的設計，是非常重要的發展和探索方向。此外它基於UDP的多路複用、以及對Steam/Datagram分別支撐 可靠傳輸 與 非可靠/半可靠場景的傳輸能力設計，包括0-RTT降低握手延遲這些基礎的協議特性帶來的優勢，就不再多說。

談談自研、標準與開源

對於任何一項好用的技術來說，能夠先應用起來並且服務好業務需求，永遠是第一步。對於任何具備深度和一定壁壘的技術（碰巧網路也屬於），一般我們都會經歷4個發展階段：

1. 第一階段，用好這項技術，首先能用好並切實在業務場景下拿到收益。在當前這個鼓勵開源的時代，第一步通過這個領域下已有的開源方案，來驗證技術的可行性，並拿到一些初步收益來驗證判斷和觀點，是最快的方式。
2. 第二階段，原理理解透徹，能夠充分理解透徹這項技術的底層原理和機制，並針對業務需求做出調整。在這個階段往往大家會有兩條分叉路徑：在已有開源專案上繼續修改並發展自己的分支；或者 籌備自研。在這個階段是選擇前者還是後者，核心依據有2個：一方面是 是對這項技術長期發展所能帶來的紅利，是否可以cover前期的投入；另一方面是，是否具備自研能力。
3. 第三階段，具備自研能力， 如果從2到3的判斷能夠滿足自研的前提，就會走上自研道路 。 因此我們可以看到絕大部分一線網際網路大廠，都會對戰略性的技術投入方向進行自研，同樣自研也能夠帶來技術壁壘的積累。這一步也是第四階段的前置門檻。
4. 第四階段，引領前沿發展， 這個階段往往又存在兩種型別（或兩者兼有）：通過開源逐步成為事實標準，或者是參與到行業標準的制定當中。

筆者個人的觀點是，每個階段都需要投入不同的精力，對應著領域的持續深挖和人才的長期培養與團隊建設。選擇走到哪個階段，沒有絕對的好與壞，而是應該根據實際的訴求、可持續投入情況 和 發展的觀點來判斷。

另一方面，作為一個技術人，我們也應當充分尊重技術本身的深度，尊重願意為了走到第三/四階段，而投入精力、克服重重困難的技術產品和團隊，而非通過一些短期包裝和走捷徑的方式，避免最終在技術上逐漸空心化，影響技術大環境的發展。如何維護技術環境的一片淨土，使得健康的種子能夠具備萌芽的條件，這也是技術管理者需要考慮和反思的。

如何應用QUIC/HTTP3來提升傳輸效能表現

這次IETF釋出的RFC 9114和9204分別描述的是HTTP/3.0和配套的Header壓縮演算法QPACK的協議機制。HTTP/3.0相對於HTTP/2到底有什麼本質提升？這需要從HTTP/3底層的QUIC傳輸機制講起。

我們都知道，QUIC基於UDP之上的多流（Stream）傳輸，實現解決原來TCP大管道下的Head-of-Line問題[3]，同時0-RTT等握手機制可以保證連線會話的快速建立和首包的加速。QUIC提供了兩種傳輸模式，基於Steam的可靠傳輸，和基於Datagram的非可靠傳輸。基於Stream的模式下，傳送方和接收方基於Steam的Offset進行流資料的重排和有序還原，並確保投遞給應用層的是有序可靠資料。基於Datagram的模式則適用於實時流媒體型別的場景，針對延遲有強訴求的同時不要求資料完全可靠有序的這類場景，Datagram提供了一種資料封裝和ACK通知的方式，幫助半可靠訴求的場景實現資料的快速投遞，並嚮應用層反饋送達情況。

[3] TCP Head-of-line頭部阻塞問題：原因是TCP是一條大的傳輸管道，基於TCP傳輸的資料，由於TCP的傳輸機制，需要等待前面的資料包完成送達，後續的資料包才能被完成送達和嚮應用層投遞。這在多路複用的場景下，會導致不同的流資料之間互相block，這在HTTP/2是一個沒有被完全解決的問題。

QUIC在丟包檢測和重傳機制方面也有較大革新。在丟包檢測方面，QUIC提供了兩大類丟包檢測方式，基於packet number的閾值檢測，和基於定時器的超時丟包檢測。這兩類機制相對於傳統的TCP檢測方式可以帶來更快的丟包感知和恢復。在重傳恢復方面，QUIC針對每一個packet分配獨立的packet number，避免了過去TCP因重傳包和原始包複用相同的sequence，導致的RTT測量不準確的問題。準確測量的RTT，作為擁塞控制演算法的一維重要輸入，能夠使得演算法對瓶頸段擁塞狀況的檢測更加準確。

這次釋出的HTTP3 RFC，則是在QUIC基礎之上，描述了HTTP請求如何通過跟QUIC steam的對映，實現完整的HTTP語義，以及針對基於UDP的多流機制設計的專用頭部壓縮。因此所有QUIC在UDP之上實現的傳輸機制革新，HTTP3都可以享受到紅利。

那麼如何把這項革新的技術用起來呢？XQUIC針對QUIC和HTTP/3協議棧提供了完整的能力實現，並且完全符合IETF標準，並通過了IETF工作組的互通性驗證[4]。在手機淘寶我們提供了整套的網路解決方案，包含客戶端的SDK和服務端閘道器的能力支援，各類業務場景核心關注開關和放量情況即可。對於外部開發者，可以移步到XQUIC在github的開源倉庫[5]，開源倉庫有相對完整的文件說明和RFC譯文，同時後續開源版本我們也將逐步更新IETF工作組版本的Multipath[8]多路傳輸能力，以及Tengine相關的適配版本和模組，方便外部開發者能夠更方便地使用。

如何解決服務端UDP效能問題

相信已經在嘗試應用QUIC/HTTP3的服務端開發者，或多或少都會經歷UDP在核心方面的效能瓶頸問題，考慮到UDP是在近幾年才隨著QUIC和流媒體傳輸的場景的逐漸流行，才被逐漸廣泛地應用起來，因此核心UDP在效能方面很難與優化了三十年的TCP相抗衡，同時核心的複雜性和通用性要求，也導致一些新的高效能修改難以被迅速接收。因此，在UDP效能優化方面，我們和龍蜥社群的Anolis核心團隊聯合做了一版bypass核心的使用者態高效能udp收發方案。

首先我們需要了解到，ebpf[6]有一類專門用於網絡卡驅動處理的filter叫XDP[7]，可以實現對於網絡卡接收和傳送的packet進行劫持處理；Anolis核心團隊基於XDP實現了一套UDP packet解除安裝和封裝邏輯並封裝為XUDP[8]庫，而我們則基於XUDP進行UDP packet的收取和傳送，實現完全bypass核心的高效能UDP收發。

這一套方案相較於Linux核心預設的UDP收發 + 四元組hash查詢優化的方案，可以在真實場景下，再提升26.3%以上的伺服器協議棧處理效能。Tengine + XUDP + XQUIC的打包處理方案，我們後續也會在Tengine社群提供開源版本以供外部開發者參考。

寫在最後

希望大家都能在自己的領域，享受技術前進的快樂。

參考文獻

[1] HTTP3: http://datatracker.ietf.org/doc/rfc9114/

[2] QPACK: http://datatracker.ietf.org/doc/rfc9204/

[4] 互通性驗證：http://interop.seemann.io/

[5] XQUIC開源倉庫：http://github.com/alibaba/xquic

[6] XDP: http://dl.acm.org/doi/pdf/10.1145/3281411.3281443

[7] XUDP: http://codeup.openanolis.cn/codeup/hpn/ExpressUDP

[8] Multipath Extension for QUIC: http://datatracker.ietf.org/doc/draft-ietf-quic-multipath/