手機淘寶在短視頻、圖片等多個情境下會用到CDN內容分發網路，手機淘寶技術和阿里雲CDN技術有非常多的共建合作，其中包括在IETF QUIC加速產品方向。本文以CDN產品為例，為您介紹手機淘寶使用IETF QUIC加速產品的應用情境和效果，以及配套的XQUIC庫的情況。
背景資訊
隨著互連網的快速發展，基礎網路環境也在發生變化，Web網路通訊協定也經歷了HTTP1.0、HTTP1.1、HTTP2.0以及即將迎來HTTP3.0。HTTP3.0將以QUIC協議替代TCP作為傳輸層，具備stream多工、握手0RTT、串連遷移以及使用者態擁塞演算法諸多優勢。CDN產品關注QUIC協議演化並實踐落地，從gQUIC協議到標準IETF QUIC協議已經部署在CDN邊緣節點，並在短視頻和圖片業務情境實踐有不錯的收益。
QUIC（全稱：Quick UDP Internet Connection），是基於UDP的多工且安全的新一代傳輸協議，具有更低的串連和傳輸延遲，擁有極佳的弱網效能，在丟包和網路延遲嚴重的情況下仍可提供可用的服務。本次發布會，阿里雲產品技術專家從QUIC技術特性、應用情境及客戶價值等維度進行全面闡述，並邀請手機淘寶技術人員分享技術實踐。阿里雲長期致力於推動QUIC的發展和落地，從而為客戶提供最佳體驗。
QUIC協議介紹
當我們訪問視頻網站和APP應用時，經常會遇到各種各樣的效能問題，網頁載入慢、視訊卡頓、網路出錯，其中關鍵影響因素就是網路通訊協定。
HTTP協議重要升級
HTTP協議作為互連網Web協議，經歷了幾次重要的升級：
HTTP1.0 → HTTP1.1：支援長串連，請求pipeline特性，通過減少了TCP三向交握，降低串連建立的開銷。
HTTP → HTTPS：增加TLS層握手，傳輸內容加解密，因增加安全特性，故增加建連延遲。
HTTP1.1 → HTTP2：H2特性是請求資料流的多工與頭部壓縮，提高了單串連的並發能力。
從HTTP1.0升級到HTTP2，其中傳輸層協議沒有變化都是基於TCP協議。TCP協議是可靠傳輸協議，需要三向交握狀態，還有隊頭阻塞問題，為瞭解決這些問題，基於UDP設計實現的一種可靠傳輸協議——QUIC協議應運而生。因此，HTTP協議再次升級。
HTTP2 → HTTP3：HTTP3基於QUIC協議，因此具備QUIC協議的傳輸特性，解決TCP隊頭阻塞問題，具備TLS1.30-RTT、H2多工能力，還具備串連遷移能力。QUIC協議已於2021年05月正式標準化，編號為RFC9000。
QUIC協議解決了哪些問題
低串連延時：QUIC基於UDP，無需TCP串連，在理想情況下，QUIC可以做到0RTT開啟資料轉送。而基於TCP的HTTPS，即使在TLS1.3的early data下仍然需要1RTT開啟資料轉送。然而對於常見的TLS1.2完全握手的情況，則需要3RTT開啟資料轉送。
無隊頭阻塞：雖然 HTTP/2實現了多工，但是傳輸層依然使用的是TCP，一旦出現某個報文丟包，將會影響多工下的所有請求流。然而QUIC基於UDP，在設計上就解決了隊頭阻塞問題。同時HTTP/3使用 QPACK編碼替換HPACK編碼，在一定程度上也減輕了HTTP要求標頭的隊頭阻塞問題。
使用者態擁塞控制：QUIC的傳輸控制不再依賴核心的擁塞控制演算法，而是實現在應用程式層上。這意味著可以根據不同的業務情境，實現配置不同的擁塞控制演算法以及參數，甚至同一個業務的不同QUIC串連也可以使用不同的擁塞控制演算法。
串連遷移：當實際使用者的網路發生變化時，從WIFI網路切換到4G網路時，使用者地址發生變化，基於TCP的 HTTP協議無法保持串連的存活；而QUIC基於串連CID作為串連標識, 仍然可以保證串連存活和資料正常收發。
QUIC協議與TCP協議對比
既然QUIC協議設計初衷是解決傳輸層協議問題，與其競對的就是TCP協議，那麼從傳輸協議特性分析兩種協議設計差異，可得出以下對比：
QUIC為每個加密層級使用單獨的包號空間，除了0-RTT和1-RTT密鑰使用相同的包號空間，隔離的包號空間可以確保使用一種加密層級發送包的ACK, 不會引起使用其他加密層級發送的包的虛假重傳問題。
QUIC的包號嚴格按照包號空間遞增，直接編碼傳輸順序。報文號越高表示報文發送時間越晚，報文號越低表示報文發送時間越早。當一個包含應答幀的包被檢測到丟失時，QUIC會在一個新的包中包含必要的幀，並添加一個新的包號，從而消除了當收到應答時確認哪個包的不確定性。因此，可以更精確地進行RTT測量，可以輕鬆地檢測到虛假重傳。
Quicack幀包含類似於TCP選擇性應答（sack）的資訊。然而QUIC不允許資料包的確認被違背，這大大簡化了雙方的實現，並降低了發送方的記憶體壓力。
與TCP的三個SACK範圍相反，QUIC支援許多ACK範圍。在高丟包環境中，這種方法可以加快恢複速度，減少虛假重傳。
TCPRTT測量使用發送包和確認包時間戳記計算，未考慮主機延遲問題，QUIC使用ACKDelay機制，使得路徑RTT測量更加準確。
QUIC使用PTO探測逾時機制，代替TCP的RTO&TLP。
TCP使用一個包的最小擁塞視窗。如果丟失單個資料包意味著發送方需要等待PTO來恢複，當接收方延遲確認時，發送一個單一的ack-eliciting包也增加了額外延遲。因此，QUIC建議最小擁塞視窗為兩個包。雖然這增加了網路負載，但它被認為是安全的，因為在持續擁塞的情況下，發送方仍然會以指數方式降低發送速率。
QUIC協議可以加速哪些情境
動態請求（API和信令傳輸情境）：降低動態互動耗時。
短視頻：提升首屏秒開率，降低卡頓率。
圖片檔案下載：降低檔案下載總耗時。
直播：降低播放卡頓率，提升推流穩定性。
QUIC協議的核心優勢
快速建聯：0-RTT的握手，減少TCP握手和TLS握手的時間，提升首屏效率。
多工：相比於HTTP/2，真正的單通道並行傳輸，徹底解決TCP協議中隊頭阻塞問題。
擁塞演算法：擁塞演算法靈活，不需要基於核心或作業系統，可直接在應用程式層改造
持續線上：頻繁切換網路的情況下，不會斷線，不需要重連，使用者無任何感知。
阿里雲CDN QUIC的演化
早在2018年左右，基於GQUIC，手機淘寶和阿里雲就開始合作，主要應用在手機淘寶的圖片和短視頻等內容分發的情境。在2019年初，當時大家有一個共同的判斷是要走標準化道路，一方面是因為從商業化產品角度，私人協議解決方案更難被使用者認可，另一方面整個標準化協議的設計和安全性都有更完備的考量。
在決定選擇標準化道路之後，當時市面上也沒有特別成熟並適用於移動端的IETF QUIC協議棧實現，所以手機淘寶就啟動了自研XQUIC專案，經過1年半的研發和打磨，於2020年的6月份開始全面上線，並且在2021年初與阿里雲CDN IETF QUIC產品實現對接，並在短視頻情境上開始逐步應用IETF QUIC技術。在2021年的9月份阿里雲CDN實現了IETF QUIC整套協議棧在短視頻情境下的規模化應用。之後，CDN產品經歷了同年雙十一的考驗，XQUIC和CDN產品的效能和穩定性都有了很好的驗證，因此在2022年的1月7號CDN完成了XQUIC開源，同時也在此支援CDN IETF QUIC新品發布。
目前主要在手機淘寶短視頻情境使用阿里雲CDN QUIC加速產品，最佳實務的技術方案是端側XQUIC協議棧和阿里雲CDN QUIC加速產品配套使用。針對手機淘寶短視頻情境，帶來的網路體驗最佳化效果，體現在短視頻分區下載耗時最佳化20%，卡頓率整體最佳化在10%。考慮到整體的最佳化效果非常明顯，阿里雲CDN團隊後續也會進一步在圖片等情境下應用這一套加速技術，同時也把這一套最佳實務貢獻給大家，希望能給雲產品的客戶帶來更好的網路加速體驗。
最佳實務端側使用的XQUIC庫
XQUIC是一個輕量、高效能、標準化的跨平台協議庫。
在輕量方面， XQUIC在Android和iOS雙端的編譯產物均小於400 KB，這減少了移動端App的包大小，降低了新使用者的安裝成本，因此XQUIC很適用於需要高效能但同時又對包大小敏感的移動端App情境。
在高效能傳輸方面，XQUIC已經在手機淘寶實現核心導購、短視頻鏈路大規模使用。例如，我們開啟手機淘寶的首頁，或搜尋我們感興趣的商品，亦或是開啟淘寶逛逛瀏覽達人的視頻，XQUIC都為這些情境的提供更快的網路資料轉送。
在標準化方面，XQUIC實現了整套IETF QUIC標準協議，包含傳輸層、加密層、應用程式層協議棧。
在跨平台方面，我們的網路程式庫支援Linux、Android、iOS、Mac等平台，後續也會支援Windows平台適配，用戶端可以通過SDK方式很方便地接入並使用。
XQUIC提供IETF QUIC標準包含的3層協議棧能力，它在用戶端以SDK的方式運行，在服務端，可以通過module對接到tengine/nginx架構使用。此外，針對移動端使用內容分發網路的情境，產品針對協議互連性、0-RTT比例提升、明文和密文模式相容等方面做了很多最佳化。例如，明文和密文模式相容方面，CDN除了支援標準TLS/1.3推薦的加密套件之外，也額外提供了明文模式，並且在握手階段可以實現自適應的協商，通過握手階段的alpn參數實現協商，並保證對標準密文模式的相容性。在0-RTT比例提升方面，CDN也針對server config以及token的緩衝策略進行了最佳化，0-RTT比例在無線端可以達到68%以上。
相信XQUIC協議庫與CDN QUIC加速產品的配合，能夠整體給使用者帶來更絲滑的網路傳輸體驗。配置QUIC協議，請參見配置QUIC協議。