通過敏捷快速實踐 QUIC ，網(wǎng)易新聞在3個月內(nèi)，將端內(nèi) QUIC 請求占比提升到 75%+，如圖1 所示，并將客戶端請求平均響應(yīng)時間 RT 降低了 45%，請求錯誤率降低了 50%+，視頻卡頓率降低了 25%+。

圖1 客戶端 QUIC 請求占比

（黃色部分為 QUIC 請求，藍(lán)色部分為其他協(xié)議請求）

如何做到以最小的成本、最小的風(fēng)險和最大的收益接入 QUIC，是本文討論的核心。

什么是QUIC？

QUIC 是 Quick UDP Internet Connections 的縮寫，意為“快速 UDP 網(wǎng)絡(luò)連接”。QUIC 由 google 實現(xiàn)于2013年，是一種網(wǎng)絡(luò)傳輸協(xié)議，旨在提升網(wǎng)絡(luò)傳輸速度。2015年，QUIC 被提交到 IETF，目標(biāo)是成為下一代的正式網(wǎng)絡(luò)規(guī)范，2018年，HTTP over QUIC 被 IETF 重命名為 HTTP/3。

在 UDP 之上，QUIC 實現(xiàn)了類似 TCP 的丟失重傳機(jī)制，QUIC 傳輸以數(shù)據(jù)包級報頭發(fā)送，并對每個包增加了單調(diào)遞增的數(shù)據(jù)包號來代表傳輸順序，當(dāng)檢測到必要幀丟失時，QUIC 會將必要幀綁定到新數(shù)據(jù)包重發(fā)。QUIC 對報文頭部和數(shù)據(jù)也都進(jìn)行了加密，且建聯(lián)時改進(jìn)使用了 DH 密鑰交換算法，在防劫持方面也具有一定優(yōu)勢。

所以，QUIC 雖然基于 UDP 實現(xiàn)，但在功能上等價于 TCP + TLS + HTTP/2，除此之外，相較于傳統(tǒng)的 HTTP + TCP，QUIC 還具有多項改進(jìn)網(wǎng)絡(luò)傳輸?shù)膬?yōu)勢，其部分優(yōu)勢如圖2 所示。

圖2 QUIC表現(xiàn)優(yōu)勢

QUIC 目前分為 gQUIC 與 iQUIC 兩種，gQUIC 即為最初的 Google QUIC，而 iQUIC 是后來 IETF 制定的通用傳輸協(xié)議，如圖3 所示。

圖3 QUIC分類

相較 iQUIC 而言，gQUIC 目前的應(yīng)用較為普遍、成熟，如 Cadddy 支持 gQUIC，客戶端還有 Chromium 的 Net 庫 Cronet 也可以支持 gQUIC，包括 ExoPlayer 等三方庫也都提供了對于 gQUIC 的擴(kuò)展支持。目前來看，選擇 gQUIC 對于渴望改善網(wǎng)絡(luò)傳輸情況的開發(fā)者來說，在接入成本和接入效率上具有優(yōu)勢。

QUIC 接入策略

為了快速接入并驗證 QUIC，在流量入口設(shè)計上，我們選擇用 Nginx + Caddy 方案實現(xiàn)；在客戶端網(wǎng)絡(luò)庫上，我們選擇了 Chromium 的網(wǎng)絡(luò)庫 Cronet，原因如下：

Google 對 Chromium 開源多年，已經(jīng)過眾多軟件團(tuán)隊的驗證，基礎(chǔ)功能穩(wěn)定良好；
作為 Chromium 的網(wǎng)絡(luò)庫，Cronet 的跨平臺性良好，在 Android 和 IOS 雙端可可直接接入；
gQUIC 相比 iQUIC，在各方面支持都更成熟，Cronet 也可以直接支持 gQUIC；

2.1 流量入口

流量入口設(shè)計上，由 Nginx 負(fù)責(zé)處理 HTTP 請求，Caddy 負(fù)責(zé)處理 UDP 請求，如圖4 所示。

圖4 流量入口設(shè)計

2.2 網(wǎng)絡(luò)庫方案設(shè)計

在客戶端網(wǎng)絡(luò)庫處理上，如何能保證侵入性最小，風(fēng)險性最低，并最快接入 QUIC，以驗證線上收益，成為了項目的主要目標(biāo)。

由于客戶端用戶規(guī)模較大，一些量級較小的第三方 QUIC 處理庫使用存在一定風(fēng)險性問題，而自研 QUIC 庫支持的成本和效率遠(yuǎn)遠(yuǎn)達(dá)不到預(yù)期，且 QUIC 的網(wǎng)絡(luò)改善收益對于 Team 來說是未知的，選擇一款穩(wěn)定可靠的網(wǎng)絡(luò)庫來快速達(dá)到 MVP（最小可行性）是首要目標(biāo)，所以在 Android 和 iOS 端，我們都選擇了使用 Cronet。

2.2.1 Android

Android 端目前使用的網(wǎng)絡(luò)庫是 OKHttp，為了更清晰有效地驗證 QUIC 的效果，我們在接入 Cronet 的同時，也保持了原有網(wǎng)絡(luò)庫 OKHttp 處理邏輯的不變，通過動態(tài)配置控制 AB 策略。上線后通過逐漸切量，一部分網(wǎng)絡(luò)請求走 Cronet，一部分網(wǎng)絡(luò)請求走 OKHttp，以清晰對比出二者的差異。

而端內(nèi)目前的兩套數(shù)據(jù)上報機(jī)制，一種基于 OKHttp 事件監(jiān)聽實現(xiàn)，一種通過 Hook OKHttp 的事件監(jiān)聽實現(xiàn)，而 Cronet 的上報與 OKHttp 事件回調(diào)可以對齊統(tǒng)一，可維護(hù)性良好，再次增加了我們選擇 Cronet 的理由。

2.2.2 iOS

Cronet 在 iOS 接入方面，API 設(shè)計友好，基于 NSURLProtocol 通過網(wǎng)絡(luò)攔截即可實現(xiàn)。iOS 的接入流程可以簡單分為初始化 Cronet 和注冊 NSURLProtocol 協(xié)議兩個部分。

2.3 網(wǎng)絡(luò)庫接入

2.3.1 Android

在接入 QUIC 時，Android 使用網(wǎng)絡(luò)庫 OKHttp 的攔截器（Intercept）機(jī)制來處理網(wǎng)絡(luò)請求較為便捷，當(dāng)網(wǎng)絡(luò)請求從業(yè)務(wù)頂層通過 OKHttp 傳輸?shù)?Cronet 對應(yīng)的攔截器時，會交由 Cronet 處理。

2.3.1.1 攔截器處理

OKHttp 攔截器（Intercept）設(shè)計基于責(zé)任鏈模式，由于在攔截器中接入 Cronet 后，網(wǎng)絡(luò)請求會被 Cronet 庫攔截處理，造成后續(xù)的攔截器短路，中斷 Request 與 Response 信息在攔截器中的傳遞，所以 Cronet 的攔截處理就應(yīng)盡量下沉，置于頂層應(yīng)用攔截器的最底部，如圖5 所示。

圖5 QUIC攔截器處理

而對于下層的默認(rèn)攔截器和自定義網(wǎng)絡(luò)攔截器都將被 QUIC 短路，默認(rèn)攔截器中主要提供了緩存、Gzip 解壓、建聯(lián)等處理，其中一部分處理策略由 Cronet 也可以替代實現(xiàn)，而重定向一類策略在 Cronet 監(jiān)聽回調(diào)中處理也較為便利。

使用 Cronet 發(fā)起請求提供兩種實現(xiàn)，一種是 CronetUrlRequest，另一種是符合 HttpURLConnection 標(biāo)準(zhǔn)的，在 CronetUrlRequest 基礎(chǔ)上封裝了流操作的 CronetHttpURLConnection，由于客戶端涉及多媒體場景較多，使用 CronetHttpURLConnection 更能滿足大部分需求場景。

目前，我們在視頻、圖集、列表通用業(yè)務(wù)網(wǎng)絡(luò)請求等范圍全面實現(xiàn)了 QUIC 的接入。

2.3.1.2 數(shù)據(jù)衡量

為了更明顯地對比出 QUIC 與 HTTP/HTTPS 之間的數(shù)據(jù)變化，我們使用了兩套網(wǎng)絡(luò)數(shù)據(jù)監(jiān)測機(jī)制：全鏈路統(tǒng)計和 APM ，以精準(zhǔn)捕獲特定請求事件的時間戳，來計算并上報建聯(lián)時間、響應(yīng)時間等信息。

通過 Cronet 提供的一些回調(diào)，可以實現(xiàn)與 OKHttp 上報監(jiān)聽的邏輯統(tǒng)一。Cronet 提供的 RequestFinishedInfo 可以獲得 Request 的建聯(lián)等信息，提供的 UrlRequest.Callback 可以獲得響應(yīng)等信息，而使用 RequestFinishedInfo 會增加一部分監(jiān)控邏輯，對 Cronet 有輕微的性能折損，僅使用 UrlRequest.Callback 返回的部分響應(yīng)信息也足夠得出 QUIC 性能數(shù)據(jù)，全鏈路上報 OKHttp 與 Cronet 監(jiān)聽對齊方案如圖6 所示。

圖6 全鏈路上報事件

由于 Android Cronet 的 CronetHttpURLConnection 在設(shè)計上較為封閉，擴(kuò)展性并不是十分良好，比如響應(yīng)回調(diào) UrlRequest.Callback，或是內(nèi)部實現(xiàn)的阻塞隊列控制 MessageLooper 都沒有暴露給開發(fā)者，在此基礎(chǔ)上定制一些功能實現(xiàn)，如全鏈路上報，或是 CronetHttpURLConnection 沒有提供的超時時間策略，都不是很方便。

為了解決這個問題，我們建立了一層代理和裝飾器，通過攔截 CronetEngine 可以拿到 CronetHttpURLConnection 的 UrlRequest.Callback，對此再做一層包裝，由包裝類進(jìn)行統(tǒng)一的事件分發(fā)，將 Response 事件分發(fā)到了 OKHttp 的全鏈路處理器中，進(jìn)而實現(xiàn)了全鏈路上報設(shè)計的統(tǒng)一。

2.3.1.3 遇到的問題

（1）超時時間處理

由于 CronetHttpURLConnection 提供的部分超時時間設(shè)置是空實現(xiàn)，而通過 Native Cronet 設(shè)置的超時時間也并不符合預(yù)期，通過 ConditionVariable 實現(xiàn)超時也未免過于冗余。

CronetHttpURLConnection 內(nèi)部維護(hù)了一個類似于安卓處理管理機(jī)制 Message + Looper 的 Task 處理器——MessageLooper，MessageLooper 中維護(hù)了一個阻塞隊列，并提供了超時的控制策略，通過建立同包名類間接繼承 package 訪問權(quán)限的 MessageLooper，通過反射替換封閉的 MessageLooper 為 NRMessageLooper，進(jìn)而可以獲得超時時間的靈活控制權(quán)，在此基礎(chǔ)上，我們增加了超時時間的動態(tài)下發(fā)，以便于風(fēng)控配置。

對 Cronet 庫的定制如圖7 所示。

圖7 網(wǎng)絡(luò)庫定制架構(gòu)圖

（2）請求占比優(yōu)化

最初，客戶端 QUIC 協(xié)議請求占比在統(tǒng)計上報上來的數(shù)據(jù)觀測中并不理想，為了提升 QUIC 占比，我們在與 CDN 共同排查后，優(yōu)化了雙方的處理方案，客戶端轉(zhuǎn)用 CronetHttpURLConnection 處理，CDN 側(cè)同時優(yōu)化處理，并對網(wǎng)絡(luò)節(jié)點也進(jìn)行了相應(yīng)調(diào)整，保證了兩側(cè)方案的統(tǒng)一性，并再次降低了平均響應(yīng)時間與錯誤率。

2.3.2 iOS

在 iOS 網(wǎng)絡(luò)庫接入方面，調(diào)用 Cronet 的 setMetricsEnabled 接口開啟 Metric，通過 URLSession 回調(diào)獲取 networkProtocolName 屬性，可以獲取當(dāng)前網(wǎng)絡(luò)請求的協(xié)議類型，以更有針對性地進(jìn)行數(shù)據(jù)衡量。

- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task
didFinishCollectingMetrics:(NSURLSessionTaskMetrics *)metrics API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))

QUIC 項目上線

3.1 切量控制

由于 QUIC 改善的擁塞控制與更低的建聯(lián)時間，都傳遞給我們了一個信息：QUIC 對改善視頻卡頓等場景有所增益，所以，我們最初的方案選取測試視頻域名，而最終視頻的卡頓率也有所優(yōu)化，在弱網(wǎng)場景則更加明顯。

由于切量到 QUIC 測試，視頻域名需要同步從 HTTP 切換到 HTTPS，這樣會增加 QUIC 測試干擾項，為了更好地觀察數(shù)據(jù)，我們設(shè)計了 QUIC 的兩套切量策略，保持一部分原有域名的請求，并將又一部分原有域名也切換到 HTTPS，而 QUIC 測試將另一部分原有域名切換為 CDN 域名進(jìn)行測試，切量控制如圖8 所示。

圖8 QUIC動態(tài)配置

而由于 QUIC 存在較高的未知性，切換網(wǎng)絡(luò)庫對于大量級的網(wǎng)易新聞來說，存在的風(fēng)險較高，而產(chǎn)生異常對用戶影響也極大，所以 Team 采取了 CDN 先預(yù)熱，后動態(tài)下發(fā)配置，篩選目標(biāo)用戶進(jìn)行逐步放量的模式，歷經(jīng)三個版本，完成 QUIC 的測試。

3.2 項目里程

QUIC 立項前開始零零散散的一段調(diào)研期，而后4月中旬接入，各方1周完成敏捷開發(fā)，以 MVP 最小可行性原則快速完成功能開發(fā)，后續(xù)聯(lián)調(diào)、上線測試和逐步迭代改進(jìn)，持續(xù)共計 3 個月左右，以團(tuán)隊預(yù)期的速度穩(wěn)定探索，最終取得了較為理想的測試效果。

數(shù)據(jù)表現(xiàn)

4.1 平均響應(yīng)時間與錯誤率

通過全鏈路上報的信息，可以很直觀的導(dǎo)出 QUIC 與原有請求傳輸方式的對比信息，通過放量控制，同一 Host 下，我們使 QUIC 協(xié)議請求量與 H2 對齊，其 Count 曲線如圖9 所示。

（以下圖中，藍(lán)色皆為H2曲線，黃色皆為QUIC曲線）

圖9 請求量對比

得出的 QUIC 與 H2 平均響應(yīng)時間對比如圖10 所示，可以直觀的看到，QUIC 平均響應(yīng)時間較 H2 縮減了約 45%。

圖10 平均響應(yīng)時間對比

而 QUIC 帶來的錯誤率也大幅降低，在錯誤率表現(xiàn)上同樣優(yōu)秀，如圖11 所示。

圖11 錯誤率對比

4.2 弱網(wǎng)表現(xiàn)

基于業(yè)界的部分研究結(jié)論，我們對 QUIC 在弱網(wǎng)的表現(xiàn)也進(jìn)行了監(jiān)控。

這里的網(wǎng)絡(luò)情況以獲取到的 手機(jī)網(wǎng)絡(luò)信號強(qiáng)度 LTE 等級 為依據(jù)，如下數(shù)據(jù)觀測基于網(wǎng)絡(luò)信號強(qiáng)度劃分的 6 個等級，其中：

0、1、2 這三級代表弱網(wǎng)情況；
4、5 這兩級代表一般網(wǎng)絡(luò)情況。

4.2.1 平均響應(yīng)時間

同樣保持請求量對齊，在該數(shù)據(jù)觀測定義的弱網(wǎng)場景下，QUIC 與 H2 的平均響應(yīng)時間對比曲線如圖12 所示。

（以下圖中，藍(lán)色皆為H2曲線，黃色皆為QUIC曲線）

圖12 弱網(wǎng)場景下RT

在該數(shù)據(jù)觀測定義的一般網(wǎng)絡(luò)場景下，QUIC 與 H2 的平均響應(yīng)時間對比曲線如圖13 所示。

圖13 一般網(wǎng)絡(luò)場景下RT

從弱網(wǎng)場景統(tǒng)計曲線的更大差值，可以粗略得出結(jié)論，QUIC 在弱網(wǎng)場景下，請求響應(yīng)時間優(yōu)化更明顯。

4.2.2 錯誤率

在該數(shù)據(jù)觀測定義的弱網(wǎng)場景下，QUIC 與 H2 的錯誤率對比曲線如圖14 所示。

圖14 弱網(wǎng)場景下錯誤率

在該數(shù)據(jù)觀測定義的一般網(wǎng)絡(luò)場景下，QUIC 與 H2 的錯誤率對比曲線如圖15 所示。

圖15 一般網(wǎng)絡(luò)場景下錯誤率

從弱網(wǎng)場景統(tǒng)計曲線的更大差值，同樣可以粗略得出結(jié)論，QUIC 在弱網(wǎng)場景下，錯誤率優(yōu)化更明顯。

4.3 視頻性能

在視頻性能方面，我們分別針對卡頓率和1秒率進(jìn)行了監(jiān)控。

4.3.1 卡頓率

從圖16 可見，QUIC 在視頻性能表現(xiàn)上，相比 H2 請求，卡頓率下降約為25%+。

（以下圖中，藍(lán)色皆為H2曲線，黃色皆為QUIC曲線）

圖16 視頻卡頓率

4.3.2 1秒率

這里的 1秒率是指視頻在1秒內(nèi)達(dá)到播放狀態(tài)的比例，從圖17 可見，QUIC 在1秒率表現(xiàn)上，相比 H2 請求有一定幅度提升。

圖17 視頻1秒率

后續(xù)展望

對于在 Cronet 的定制和處理方面，還有更多的改進(jìn)空間，如協(xié)商過程的優(yōu)化，DNS 的定制優(yōu)化處理等，后續(xù)我們會逐步精進(jìn)，繼續(xù)深入挖掘 QUIC，期待發(fā)現(xiàn)更多的驚喜。

作者簡介

李云鵬 2016年加入網(wǎng)易傳媒，目前主要負(fù)責(zé)架構(gòu)和性能優(yōu)化相關(guān)工作。QCon 大會講師，著有《移動開發(fā)架構(gòu)設(shè)計實戰(zhàn)》等書籍。

李鑫飛網(wǎng)易新聞客戶端 iOS 架構(gòu)組組長，負(fù)責(zé)客戶端基礎(chǔ)架構(gòu)，組件化及性能優(yōu)化等工作。

張鑫網(wǎng)易資深應(yīng)用運維工程師，負(fù)責(zé)網(wǎng)易新聞內(nèi)容發(fā)布系統(tǒng)運維工作，在內(nèi)容發(fā)布、流媒體點播、直播、CDN運維、全鏈路監(jiān)控、大數(shù)據(jù)運維、業(yè)務(wù)容器化方面有豐富運維經(jīng)驗。