讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享

羅成：騰訊資深研發工程師。目前主要負責騰訊 stgw(騰訊安全雲網關）的相關工作，整體推進騰訊內部及騰訊公有雲，混合雲的七層負載均衡及全站 HTTPS 接入。對 HTTPS，SPDY，HTTP2，QUIC 等應用層協議、高性能服務器技術、雲網絡技術、用戶訪問速度、分布式文件傳輸等有較深的理解。（作者微博：點此進入）

4、QUIC 在騰訊的實踐

騰訊安全雲網關 (STGW) 和騰訊雲負載均衡器（Cloud Load Balance）在 2017 年 7 月份就已經在服務端上支持了 Quic 協議，在工程實現上也有很多優化點，同時在生產環境中也取得了較好的效果。相比現在幾個開源的方案，STGW 的實現主要有如下幾個優點。

1）高性能：

復用 Nginx 全異步事件驅動框架；

私鑰代理計算集群加速簽名計算；

全局緩存提速，減少計算量的同時，提升訪問速度。

2）強大的功能：

支持 Nginx 現有全部模塊指令，豐富的第三方模塊；

復用 Nginx 模塊框架，非常靈活地新增第三方功能。

3）穩定性：

代碼完全自主可控；

正在經受騰訊億萬級並發流量的考驗。

同時我們也在騰訊很多業務包括 QQ 空間、WEB 游戲頁面、騰訊雲 CLB 上灰度支持了 QUIC 協議。詳細的提升數據可以參考文中線上灰度數據一節。

5、QUIC 選型調研時的測試方案

在決定使用 QUIC 協議之前，我們需要對 QUIC 協議的特性及性能做一個全面的測試，如何測試呢？這里簡單說一下測試方案。

需要特別說明的測試是在 2016 年底進行的，目前所有域名已經失效，無法再進行測試。

5.1 頁面構造

根據 httparchive.org 的統計，構造了如下頁面：

5.2 測試環境

手機：華為 mate9

User-Agent：MHA-AL00 Build/HUAWEIMHA-AL00) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Mobile Safari/537.36

操作系統：Android 7.0

服務端 QUIC 程序：caddy 0.9.4

網站和客戶端分布如下：

① 表示客戶端主動發起的用戶請求；

② 表示從 html 里發出的資源請求；

③ 表示數據上報請求。

5.3 測試流程

整個測試流程通過 python 腳本和 adb shell 工具自動化進行，其中移動端和 PC 端的控制流程有所區別。現分別簡介如下。

【移動端測試流程】：

准備事項：

打開手機的 usb 調試選項；

在 PC 端安裝 adb；

在 PC 上通過 USB 連接手機，確保能夠通過 adb devices 命令發現設備；

在服務端配置 cache-control: no-cache, no-store。禁止客戶端緩存。

自動化測試流程如下：

啟動 android chrome；

訪問 https://www.helloworlds.cc；

待頁面加載完后會觸發 onload 事件，將各個時間點上報。

【PC 端流程】：

PC 端不需要 adb，使用 webbrowser 模塊控制 chrome 完成即可。

5.4 測試結論

由於公司內網的 WIFI 環境不穩定，多次測試發現數據跳動較大，4G 環境下的數據更加穩定可靠，所以主要結論參考 4G 網絡下的數據。

測試結果顯示，QUIC 的優勢非常明顯：

即使在元素比較少（12 個元素）的情況下：相比 HTTP 也能提升 9%，相比 HTTP2 提升 42%，相比 HTTPS 提升 52%；

在頁面元素增多的情況下：QUIC 的優勢就更加明顯，相比 HTTP 提升 36%，相比 HTTP2 提升 47%，相比 HTTPS 提升 64%。

5.5 優化空間

QUIC 的特性雖然比較先進，但是實現起來卻非常復雜，在工程實現方面也有很多優化的空間。比如如何提升 0RTT 成功率，減少服務端的 CPU 消耗量，實現連接遷移和動態的擁塞控制算法等。我們繼續看下節。

6、QUIC 性能優化1：提升 0RTT 成功率

安全傳輸層雖然能夠實現 0RTT，優勢非常明顯。但問題是，不是每一次連接都能實現 0RTT，對於我們的客戶端和服務端來講，如何最大程度地提升 0RTT 的成功率？

0RTT 能實現的關鍵是 ServerConfig。就像 TLS session resume 實現的關鍵是 session id 或者 session ticket 一樣。

ServerConfig 到達服務端后，我們根據 ServerConfig ID 查找本地內存，如果找到了，即認為這個數據是可信的，能夠完成 0RTT 握手。

但是會有兩個問題：

1）進程間 ID 數據無法共享；

2）多台服務器間的 ID 數據無法共享。

明確了問題，那工程層面就需要實現多進程共享及分布式多集群的 ID 共享。

SeverConfig Cache 集群如下圖所示：

如上圖所示，Stgw 在生成 ServerConfig ID 和內容時，會存儲到全局的 Cache 集群。用戶握手請求落到任意一台 STGW 機器，從全局 Cache 集群都能找到相應的內容，實現 0RTT 握手。

7、QUIC 性能優化2：加密性能的優化

7.1 簽名計算

QUIC 實現 0RTT 的前提是 ServerConfig 這個內容簽名和校驗都沒有問題。由於 ServerConfig 涉及到 RSA 簽名或者 ECDSA 簽名，非常消耗我們的 CPU 資源。根據之前的測試數據，RSA 私鑰簽名計算會降低 90% 的性能。

那如何優化呢？使用 RSA 或者 ECDSA 異步代理計算，核心思路也是三點：

算法分離：剝離私鑰計算部分，不讓這個過程占用本地 CPU 資源；

異步執行：算法剝離和執行異步的，上層服務不需要同步等待這個計算過程的完成；

並行計算：我們使用配置了專用硬件的私鑰計算集群來完成私鑰計算。

架構如下圖所示：

7.2 對稱加密的優化

相比非對稱密鑰交換算法來講，對稱加密算法的性能非常卓越（好 1 到 2 個數量級），但是如果應用層傳輸內容較大的話，特別是移動端的 CPU 計算能力較弱，對稱加密算法對性能的影響也不容忽視。

常用對稱加密算法性能比較：

如何優化呢？通過異步代理的方式顯然不可能。原因是：

會極大降低用戶訪問速度。由於應用層的每一個字節都需要對稱加解密，使用異步的方式實現會嚴重降低加解密的實時性。

那有沒有同步的優化方式呢？有：

類似 SSL 硬件加速卡，intel 針對 AES 算法實現硬件加速，並將它集成到了 CPU 指令里。

【AES-NI 指令】：

AES-NI 是 intel 推出的針對 AES 對稱加密算法進行優化的一系列指令，通過硬件計算實現計算速度的提升。

如何測試 AES-NI 的性能呢？

通過環境變量：aes-ni: OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-gcm 或者在代碼里將 crypto/evp/e_aes.c # define AESNI_CAPABLE (OPENSSL_ia32cap_P[1]&(1<<(57-32))) 進行設置。

aesni 對性能的提升約 20%，由 4.3W 提升到 5.1W。

這里需要注意的是，如果需要單獨使用 openssl 的 API 進行 AES 對稱加解密，最好使用 aes evp API，這樣才會默認開啟 AES-NI 指令。

【chacha20-poly1305】：

chacha20-poly1305 是由 Dan Bernstein 發明，並且由 google 推出的一種帶身份認證的對稱加密算法。其中 chacha20 是指對稱加密算法，poly1305 指身份認證算法。這個算法是對沒有 AES 硬件加速功能的移動平台的補充，比如 ARM 芯片。

從 google 公布的數據來看，chacha20-poly1305 能夠提升 30% 以上的加解密性能，節省移動端耗電量。當然，如果手機端支持 AES-NI 指令的話，chacha20 就沒有優勢了。

Openssl 在 1.1.0 版本中正式支持了 chacha20-poly1305。

8、QUIC 性能優化3：連接遷移 (Connection Migration) 的實現

那 STGW 服務端如何實現的呢？我們在 CLB 四層轉發層面實現了根據 ID 進行哈希的負載均衡算法，保證將相同 ID 的 QUIC 請求落到相同的 CLB7 層集群上，在 CLB7 上，我們又會優先根據 ID 進行處理。

QUIC 連接遷移圖示如下：

如上圖所述，客戶端最開始使用 4G 移動網絡訪問業務，源 IP 假設為 IP1，整個訪問流程使用藍色線條標識。

當用戶進入 WIFI 網絡時，源 IP 發生了變化，從 IP1 切換到了 IP2，整個訪問流程使用綠色線條標識。由於接入的 CLB4 有可能發生變化，但整個 CLB 集群統一使用 QUIC Connection ID 調度，只要 QUIC 連接的 ID 沒有發生變化，能夠將該請求調度到相同的 CLB7 層機器上。

同一台 CLB7 保存了相同的 Stream 及 Connection 處理上下文，能夠將該請求繼續調度到相同的業務 RS 機器。

整個網絡和 IP 切換過程，對於用戶和業務來講，沒有任何感知。

9、QUIC 性能優化4：動態的流量控制和擁塞控制

STGW 在連接和 Stream 級別設置了不同的窗口數。

最重要的是，我們可以在內存不足或者上游處理性能出現問題時，通過流量控制來限制傳輸速率，保障服務可用性。

10、STGW 針對 QUIC 的性能統計

STGW 針對 QUIC 的線上使用情況進行了很多的變量統計和分析，包括 0RTT 握手成功率，握手時間，密碼套件使用分布，QUIC 協議版本，stream 並發數量等。

這些統計變量能夠為我們的協議優化提供更加精細的數據支撐。

11、QUIC 線上灰度數據

QUIC 目前已經在 STGW 上線運行。我們針對騰訊幾個重要域名（包括 QQ 黃鑽頁面，游戲頁面）進行了灰度實驗。

Qzone QUIC 頁面：

如上圖所示，圖中紅色箭頭指向的綠色標識表示該頁面使用了 QUIC 協議。

灰度實驗的效果也非常明顯，其中 quic 請求的首字節時間 (rspStart) 比 http2 平均減少 326ms, 性能提升約 25%; 這主要得益於 quic 的 0RTT 和 1RTT 握手時間，能夠更早的發出請求。

此外 quic 請求發出的時間 (reqStart) 比 h2 平均減少 250ms; 另外 quic 請求頁面加載完成的時間 (loadEnd) 平均減少 2s，由於整體頁面比較復雜, 很多其它的資源加載阻塞，導致整體加載完成的時間比較長約 9s，性能提升比例約 22%。

上述數據有兩個問題，僅供參考，因為：

由於我們的頁面並沒有全部改造成 QUIC 協議，所以性能數據應該還可以進一步提升；

每個業務的頁面構成不一樣，提升的性能數據也會有差別。

12、我們開源了CLB-QUIC-DEMO的源碼

前面提到的 QUIC 實踐和優化都是針對服務端。為了方便廣大開發者進一步了解 QUIC 在客戶端的使用，我們提供了一個安卓客戶端的 DEMO，僅供參考。

DEMO 已經在 github 上開源，地址如下：

https://github.com/52im/clb-quic-demo

DEMO 的主要目的有兩個：

1）簡單說明一下在客戶端使用 QUIC；

2）簡單對比 HTTP2 和 QUIC 的性能差別。

Demo的使用界面比較簡單，如下所示：

如果有用戶想使用 QUIC 協議，客戶端做一下改造，服務端直接使用騰訊雲 CLB 負載均衡器就能實現了。

如前所述，CLB 在協議計算性能和訪問速度、安全性能方面，做了非常多優化。

13、本文小結

QUIC 協議非常復雜，因為它做了太多事情：

1）為了實現傳輸的可靠性，它基本上實現並且改進了整個 TCP 協議的功能，包括序列號，重傳，擁塞控制，流量控制等；

2）為了實現傳輸的安全性，它又徹底重構了 TLS 協議，包括證書壓縮，握手消息，0RTT 等。雖然后續可能會采用 TLS1.3 協議，但是事實上是 QUIC 推動了 TLS1.3 的發展；

3）為了實現傳輸的並發性，它又實現了 HTTP2 的大部分特性，包括多路復用，流量控制等。

雖然如此復雜，但是 QUIC 作為一個新興的協議，已經展現了非常強大的生命力和廣闊的前景。

目前國內外除了 Google 大規模采用外，還鮮有其他互聯網公司使用。STGW 作為騰訊的安全雲網關，我們有責任，有義務對業界先進的標准協議提供支持和優化。同時騰訊雲也是國內第一家支持 QUIC 協議的雲廠商，因為這個協議能切實改善客戶端的訪問速度和終端用戶體驗。

我們不僅在服務端實現了 Quic 協議的支持，優化了 QUIC 協議方面的性能問題，同時也希望通過自己一些經驗的分享，推動 QUIC 協議的發展，構造一個更加安全更加快速的互聯網世界。

Let’Quic, Make Web Faster。

附錄：有關微信、QQ的文章匯總

（本文同步發布於：http://www.52im.net/thread-1407-1-1.html）

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 【騰訊Bugly干貨分享】Android 新一代多渠道打包神器新一代圖像AI ISP技術新一代信息技術與利弊 E百科 | 第2期扒一扒能加速互聯網的QUIC協議互聯網協議總結互聯網服務架構分享（一） 11-02 互聯網協議互聯網基礎協議 - HTTP 互聯網前端開發技術棧互聯網的“ip分組交換技術”