「網絡」淘寶HTTP3/QUIC技術演進與實踐

一、引言

下圖示為手淘網絡協定演進關鍵節點。2015年為優化标準TLS/1.2握手慢問題，我們自行研制上線了輕量級私有加密協定Slight SSL來優化握手與加密問題，在沒有重播攻擊風險時允許将會話協商和資料加密放在一個TCP封包中來實作0-RTT，目前手淘線上流量HTTP2+SlightSSL也是主要承載者。與此同時過往問題排查/業務接入/業務訴求面臨一些疑難或者無法滿足訴求問題，諸如 "WI-FI下長鍊全失敗降級短鍊https可以成功，切換到4G網長鍊正常使用（SlightSSL私有協定被wifi防火牆斷開）"、"你們計劃支援TLS1.3嗎？"、"我們域名接入服務端不支援部署SlightSSL"等；另一方面随着QUIC RFC9000、HTTP3 RFC9114正式釋出，将手淘網絡協定演進到HTTP3/QUIC不管是解決Slight SSL私有協定在業務上痛點，還是為了提高網絡傳輸性能提升使用者體驗，同時也是當下網絡協定向前演進的大勢所趨。私有化協定帶來高效網絡體驗的同時，歸納起來問題主要集中在以下三點：

• 私有化的協定意味着更定制，需要端到端的部署支援（侵入性）
• 不支援TLS1.3
• 偶有網絡中間裝置因私有協定同時斷開兩端連接配接

圖1.1 手淘網絡協定演進關鍵節點

二、TNET能力演進

TNET 全稱 TAOBAO NET，是在手淘無線化發展和演進中，逐漸形成的一套底層網絡基礎能力庫。目前承載了手淘 90%+的業務HTTPs資料流量（少量域名AMDC未配置長鍊協定），作為集團網絡服務在端側落地的基石，是端上到服務端的長鍊通道端側入口，同時也是端上網絡相關中間件的底層基礎。經過演進完善目前對上層提供豐富可組合的協定搭配，内部對不同協定進行實作&抽象适配，對外接口上提供統一的接口，外層隻需要在建聯時傳入不同組合協定類型即可，做到真正意義上的簡單易用。目前内部功能上主要有兩大塊：

• 一塊由SPDY/HTTP2/HTTP3/Custom/HTTP3/Tunnel對上層滿足HTTP網絡請求/上傳私有協定通道/ACCS消息網絡通道能力（其中标準TLS主要為海外等部分不支援SlightSSL部署業務使用，标準HTTP2目前采用分支維護未合入手淘主幹，原因主要基于手淘內建下包大小考慮，手淘下SlightSSL即滿足業務要求且性能更高）
• 另一塊為提供自實作DNS解析/traceroute/MTU探測/ICMP PING探測/IPv4&IPv6協定棧探測能力，主要偏網絡工具屬性滿足上層對網絡診斷/探測能力的支援，以及部分對原生DNS接口失敗情況下系統能力的補充。

圖2.1 TNET能力架構

三、HTTP3/QUIC協定更新提性能端雲更新技術改造方案

XQUIC作為手淘自研IETF QUIC标準的協定庫具備完全自主可控快速演進的優勢，關于XQUIC協定庫的設計部分組内同僚已有多篇文檔進行詳細的介紹不再重複，感興趣的可通過本文尾部的相關文章連結檢視。回到端上TNET網絡庫來說，通過适配XQUIC庫全面更新增加支援七層HTTP3協定和四層QUIC協定，同時對外屏蔽掉各協定實作上的差異，上層隻需建聯時選擇不同的協定類型即可，滿足多種業務場景下不同訴求。

圖3.1 XQUIC手淘內建改造方案

端側降級&快恢

端上會先從amdc拉取一組政策 (amdc可以了解為一個擴充的httpdns域名解析服務，不僅會傳回域名對應的ip，還有支援協定等擴充屬性)，這時amdc會同時下發http3&http2協定(端上優先使用http3，同時下發http2協定是為確定有兜底長鍊協定)，拿到http3協定後會先進行udp連通性探測規避udp受限問題，隻有目前網絡環境探測通過後的才會建立HTTP3長鍊，關于探測部分文章後面會有介紹。

圖3.2 用戶端降級政策

更新效果

大盤更新進度&效果

前年在手淘重點聯路完成IPv4流量部分的HTTP3更新覆寫，去年随着Aserver主站内網QUIC IPv6鍊路改造完成，我們将導購/交易/短視訊/上傳鍊路原先走TCP+IPv6這部分流量也全部切到QUIC，目前手淘裡這幾個重點場景已完成全部覆寫更新。效果上大盤/業務AB資料顯示HTTP3/QUIC在這些不同類型業務場景下都取得顯著提升，助力業務實作好網（傳輸速率/均值耗時）更好，弱網（長尾耗時&成功率）更優，為使用者帶來更順滑的網絡體驗。除此之外，阿裡集團内其他如菜鳥、手貓、AliExpress等APP也複用我們方案進行HTTP3更新覆寫，拿到更優網絡體驗的業務收益資料。以下是手淘上收益提升情況：

• 導購場景：網絡總耗時均值/P99降低22%/33%，一秒完成率提升1.2pt；
• 交易場景：網絡總耗時均值/P99降低23%/32%，一秒完成率提升0.55pt；
• 上傳場景：視訊/圖檔 上傳速率提升7.7%/21%，成功率提升0.18pt；
• 短視訊下載下傳：網絡總耗時均值/P99降低15%/16%，下載下傳速率提升18%；

圖3.3 MTOP RPC核心鍊路更新對比資料

圖3.4 上傳&短視訊内容鍊路更新對比資料

典型業務場景效果互動場景中斷率

在互動業務下AB實驗資料顯示更新HTTP3實驗桶可有效降低互動中斷UV數/流失UV數。Android HTTP3 AB實驗桶中斷UV數/中斷流失UV數分别降低 24.02%/22.89%，IOS端實驗桶分别降低20.91%/18.57%。

圖3.5 手淘互動場景之一笆芭農場

購物車&詳情

今年手淘購物車改版後為使用者下單帶來了便捷，但同時也面臨網絡傳輸體驗上耗時長的業務痛點問題，通過切換到HTTP3後從業務大盤耗時均值下降明顯，給業務帶來更多可能。如下圖所示為HTTP3更新推量後接口大盤耗時變化趨勢。其他詳情/首頁等接口也有類似表現，這正是由于更新後傳輸性能的提升所帶來。

圖3.6 業務接口耗時随着放量趨勢

落地問題&優化

UDP穿透性問題

因部分營運商和網絡中間裝置可能存在将udp包丢棄的政策，這将拉低大盤建聯成功率并導緻降級率顯著變高，往往需要等建聯逾時後才會降級重試成功，這顯然會增加重試耗時導緻不好使用者體驗。

對此我們設計了udp聯通性探測，在啟動階段或者絡環境發生切換時會觸發異步探測，該探測結果會根據網絡環境持久化到本地，在探測結果過期後會重新觸發探測更新。這樣確定了即使udp不通情況下，對上層業務體驗也不會有劣化影響，而在探測通的環境下使用HTTP3/QUIC将為使用者帶來更優的使用者體驗，線上全國大盤的udp穿透性探測成功率資料平均值一開始在95%左右，經過對UDP品質差的VIP治理/下線曆史不支援UDP端口特殊排程配置/營運商對某些UDP IP網段去黑名單處理，目前全國udp探測成功率均值提升到98%。

UDP端口NET-rebind問題

在TCP下五元組便唯一确定一條連接配接，過往我們SLB和CDN LVS的負載均衡分發基礎算法都是基于5元組來實作，這在TCP下可以很好的滿足要求。更新為QUIC協定後基于五元組轉發對連接配接遷移（Connection Migration）和 多路徑（Multipath QUIC）的能力就無法支援，因為在這兩類場景下5元組都會發生變化。比較理想的是基于CID進行一緻性hash轉發，這也是QUIC協定設計之初便與5元組解耦考慮，關于基于CID分發感興趣的可以檢視草案QUIC-LB。回到我們落地由于涉及到SLB/LVS基建改造周期較長，受此影響一開始在單路落地我們基于5元組轉發（舍棄掉連接配接遷移能力）進行業務應用，這在大多數情況下已經滿足要求但也面臨一些問題。NAT 網關針對 UDP 的 Session 存活時間普遍較短，在移動端因為使用者切背景空閑情況下容易發生UDP端口NET-rebind問題，這時通過5元組轉發下将無法分發到目标伺服器，便會出現因為找不到連接配接上下文而導緻連接配接中斷即使目前網絡正常。

如下圖所示，用戶端QUIC連接配接Q首先從NET裝置源出口端口1被SLB轉發到Server A上，連接配接Q從用戶端到Server A鍊路雙向轉發傳輸正常；某個時刻如果連接配接Q對應的UDP Session空閑（如使用者切背景）超過NET裝置保活時間，APP與出口端口1之間映射将失效；等使用者回前台觸發發包後，NET裝置重建立立起APP到出口端口2的新映射，此時用戶端上來的包将被SLB轉發到另一台Server機器C上，而在C機器上是找不到QUIC連接配接Q對應的上下文，這時會回複RESET導緻連接配接中斷，從我們資料看華為機型比例高于其他廠商。問題已經清楚通過CID轉發來確定端口NET-rebind前後路由的一緻性，當Servre端檢測到新的5元組後觸發連接配接遷移便可得到解決。

圖3.7、五元組轉發面臨問題

0RTT比例提升

在首次建連握手時，服務端會給用戶端傳回Session ticket和傳輸參數，用戶端在Session ticket緩存有效期内，下一次握手即可在client-hello之後直接發送加密資料。同時Session ticket自動到期失效後可以退回1-RTT更新，在減少握手延遲的前提下，相較于公鑰預置的方案更優，兼顧前向安全性。手淘上目前在完成首次1RTT建聯後，我們會将Session ticket和傳輸參數存儲在安全保镖中以確定緩存的安全性。在項目上線初期，提升效果并不那麼理想，網絡總耗時相較于H2提升約15%左右，分析資料在首包耗時方面與H2幾乎保持持平這顯然不符合預期，通過資料看0RTT連接配接比例一開始隻有40%左右，經過優化緩存有效率後0RTT比例由40%提升到了65%（該比例還有進一步提升空間，短視訊場景0RTT比例目前在80%+），網絡總耗時相較H2的提升由15%提高到了20%左右。

業務非加密訴求

對于一些短視訊業務，響應大小相比RPC場景更大，且基本都是明文傳輸對加密訴求弱，更關注視訊拉流的速率。為此我們在XQUIC中實作了加密/明文協商能力，在握手完成後如果協商結果為明文傳輸，則後續包都不再進行加密，這可有效降低server端/用戶端加解密的處理開銷，進而提升性能。

XQUIC協定棧性能優化

除前面優化外我們還對協定棧進行深度優化，就XQUIC庫本身協定處理性能提升85.93%，對比nginx-quic在處理性能上也有15.62%的提升。

圖3.8 XQUIC庫協定棧優化對比資料

XQUIC庫處理模型

下圖是XQUIC協定棧最簡化模型：對于發送方而言，XQUIC會把一段有序位元組流封裝成QUIC封包發送出去，對于接收方來說，是把一個個無序的QUIC封包組裝成一段有序的位元組流。

圖3.9 XQUIC庫處理簡化模型

整體性優化

我們思考下優化CPU開銷的核心是什麼？為了回答這個問題，我們先想想CPU上跑的是什麼？沒錯，就是指令集。那麼指令集是怎麼來的呢？它是由彙編語言生成的。彙編語言是怎麼來的呢？他是由進階程式設計語言生成的。是以，我們至少可以想到以下三個方面可以優化：

• 程式設計語言：也就是你的代碼，選擇一個合适的程式設計語言，然後想辦法寫的性能高一點
• 編譯
• 編譯優化，可以開的編譯優化選項都開起來
• 編譯器，選擇一個高性能的編譯器
• 指令集：這個我們能做的比較少，服務端一般都是X86
• 組包優化：回到上面的問題，優化CPU開銷的核心是什麼？本質上就是減少完成一個功能所需的指令數。注意看XQUIC的簡化模型，每收到一個QUIC封包，都需要一系列的函數操作，最終輸出一段流。相反的，每發送一段流，都需要調用一系列函數，最終輸出一個個QUIC封包。我們要完成的功能就是把一段流傳輸給對端，我們可以優化處理每個包的一系列函數的性能，但是減少函數調用次數是不是來的更高效。減少QUIC封包數能大幅提升性能，在協定允許的範圍内盡量填滿每一個封包。

圖3.10 XQUIC最初組包情況

圖3.11 裝填組包優化

圖3.12 去掉備援幀優化

局部性優化

• 能不能不調
• 避免無效計算
• 避免重複計算 ：每次加解密包都建立加解密上下文，并且初始化密鑰 -> 握手完成時或者密鑰改變時建立加解密上下文，并且初始化密鑰
• 能不能少調
• 減少記憶體拷貝：業務拷貝到H3層再拷貝到傳輸層 -> 業務拷貝到傳輸層
• 盡早退出循環：特别是周遊的清單很長時
• 優化函數性能
• 空間換時間 ：huffman解碼表 用4K數組存儲，每次解碼4bits -> 用64K數組存儲，每次解碼16bits
• 函數内聯
• 分支預測 ：likely()/unlikely()

四、集團全鍊路壓測協定更新

amazon全鍊路平台更新HTTP3

在手淘用戶端導購&交易場景HTTP3大規模放量後，随之而來的大促全鍊路壓測流量模型中協定占比也發生改變，全鍊路壓測需同時支援HTTP2+HTTP3協定，對此我們對集團全鍊路壓測引擎amazon平台進行一次大的改造更新支援HTTP3協定壓測。

不同于HTTP2基于TCP的已經過多年大促&壓測多輪驗證過的穩定鍊路，HTTP3基于UDP的全新鍊路在大促脈沖下的表現則顯得缺少大促經驗，确實通過壓測前驗證助力我們提前發現UDP新鍊路下一些問題，針對解決後最終確定雙十一大促HTTP3平穩順利。碰到的問題主要有：

• 1、udp_hash查找性能差問題：在quic連接配接數多的情況下，系統udp_hash查找的性能會急劇下降，易打滿系統軟中斷而無法及時處理逾時。核心對該問題進行過優化，4.19之前核心版本需要打patch，4.19及之後的版本已自帶，該查找優化需通過設定socket option 來啟用，為此我們更新核心版本到4.19。

setsockopt(s, SOL_UDP, 200, (const void *) &value, sizeof(int)
           

• 2、核心對udp丢包問題：更新4.19核心後在pps高的情況下又碰到udp丢包問題，原因在于4.19核心對udp記憶體存在限制。
• 具體原理：
• 1. 對每個UDP session核心會把使用的記憶體計數，并累積到一定值（與rcvbuf正相關）才釋放 2. 核心會記錄所有UDP的的記憶體計數和，當這個計數和大于限制值（與umem正相關 ）時 ，将會丢棄所有的UDP封包。
• 不難看出該問題會導緻我們單機長鍊數和應對突增流量的受限，為此我們兩個優化參數調節方向：
• 1、增加umem值 2、縮小recvbuf值。

五、 正在進行

HTTP3覆寫圖檔域名

目前我們完成導購、交易、短視訊、上傳鍊路的全量更新覆寫，圖檔域名的更新覆寫還在逐漸灰階覆寫中。

HTTP3 over MPQUIC規模化應用

MPQUIC改造涉及到用戶端、SLB、Aserver等基建的更新，目前RPC鍊路端到端整條鍊路已經改造完成。手淘Android已正式上線目前處在規模化放量階段，能力上提供兩種可選模式（長尾補償模式和多路并行加速模式），從灰階資料看加速模式下MPQUIC相比單路QUIC還有8%進一步速率提升，目前XQUIC實作的MPQUIC已對外開源。CDN鍊路MPQUIC支援改造Server端和LVS正在進行中。

圖5.1 WIFI+LTE雙路聚合傳輸示意圖

圖5.2 手淘通用設定網絡加速使用者開關

附錄

QUIC-LB: https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-15

RFC 9000：https://quicwg.org/base-drafts/rfc9000.html

RFC 9114：https://quicwg.org/base-drafts/rfc9114.html

XQUIC: https://github.com/alibaba/xquic

團隊介紹

網關與網絡技術隸屬于大淘寶技術-大淘寶平台技術-終端體驗平台團隊，希望能通過網絡技術演進給使用者帶來更絲滑的體驗。如果對XQUIC、網絡技術、高性能網絡傳輸、網絡成本優化等領域比較感興趣，歡迎點選“閱讀原文”關注我們的 GitHub 倉庫：https://github.com/alibaba/xquic。

文章來源：阿裡巴巴終端技術_https://mp.weixin.qq.com/s/uwMxy5v_uwQDCMAUWgWgPw