讓互聯網更快的協議，QUIC在騰訊的實踐及性能優化

寫在前面

若是你的 App，在不須要任何修改的狀況下就能提高 15% 以上的訪問速度。特別是弱網絡的時候可以提高 20% 以上的訪問速度。

若是你的 App，在頻繁切換 4G 和 WIFI 網絡的狀況下，不會斷線，不須要重連，用戶無任何感知。若是你的 App，既須要 TLS 的安全，也想實現多路複用的強大。

若是你剛剛纔據說 HTTP2 是下一代互聯網協議，若是你剛剛纔關注到 TLS1.3 是一個革命性具備里程碑意義的協議，可是這兩個協議卻一直在被另外一個更新興的協議所影響和挑戰。

若是這個新興的協議，它的名字就叫作「快」，而且正在標準化爲新一代的互聯網傳輸協議。

你願意花一點點時間瞭解這個協議嗎？你願意投入精力去研究這個協議嗎？你願意全力推進業務來使用這個協議嗎？

QUIC 在騰訊的實踐

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

1. 高性能。

• 複用 Nginx 全異步事件驅動框架。

• 私鑰代理計算集羣加速簽名計算。

• 全局緩存提速，減小計算量的同時，提高訪問速度。

強大的功能。

• 支持 Nginx 現有所有模塊指令，豐富的第三方模塊。

• 複用 Nginx 模塊框架，很是靈活地新增第三方功能。

穩定性。

• 代碼徹底自主可控。

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

同時咱們也在騰訊不少業務包括 QQ 空間、WEB 遊戲頁面、騰訊雲 CLB 上灰度支持了 QUIC 協議。詳細的收益數據能夠參考第 6 章。

QUIC 線下測試方案

在決定使用 QUIC 協議以前，咱們須要對 QUIC 協議的特性及性能作一個全面的測試，如何測試呢？這裏簡單說一下測試方案。

須要特別說明的測試是在 2016 年末進行的，目前全部域名已經失效，沒法再進行測試。

頁面構造

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

測試環境

手機：華爲 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




網站和客戶端分佈以下：

QUIC 測試框架

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

• ②表示從 html 裏發出的資源請求。

• ③表示數據上報請求。

測試流程

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

 移動端測試流程

準備事項：

1. 打開手機的 usb 調試選項。

2. 在 PC 端安裝 adb。

3. 在 PC 上經過 USB 鏈接手機，確保可以經過 adb  devices 命令發現設備。

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

自動化測試流程以下：

1. 啓動 android chrome。

2. 訪問 https://www.helloworlds.cc。

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

 PC 端流程

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

測試結論

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

QUIC 的優點很是明顯，即便在元素比較少（12 個元素）的狀況下，相比 HTTP 也能提高 9%，相比 HTTP2 提高 42%，相比 HTTPS 提高 52%。

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

QUIC 性能優化

QUIC 的特性雖然比較先進，可是實現起來卻很是複雜，在工程實現方面也有不少優化的空間。好比如何提高 0RTT 成功率，減小服務端的 CPU 消耗量，實現鏈接遷移和動態的擁塞控制算法等。

提高 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 握手。

加密性能的優化 簽名計算

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

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

1. 算法分離。剝離私鑰計算部分，不讓這個過程佔用本地 CPU 資源。

2. 異步執行。算法剝離和執行異步的，上層服務不須要同步等待這個計算過程的完成。

3. 並行計算。咱們使用配置了專用硬件的私鑰計算集羣來完成私鑰計算。

架構以下圖所示：

簽名代理計算

 對稱加密的優化

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

表格 1 經常使用對稱加密算法性能比較

如何優化呢？經過異步代理的方式顯然不可能。緣由是：

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

那有沒有同步的優化方式呢？有。相似 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。

鏈接遷移 (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 切換過程，對於用戶和業務來說，沒有任何感知。

動態的流量控制和擁塞控制

STGW 在鏈接和 Stream 級別設置了不一樣的窗口數。

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

性能統計

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

這些統計變量可以爲咱們的協議優化提供更加精細的數據支撐。

QUIC 線上灰度數據

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

Qzone QUIC 頁面

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

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

此外 quic 請求發出的時間 (reqStart) 比 h2 平均減小 250ms; 另外 quic 請求頁面加載完成的時間 (loadEnd) 平均減小 2s，因爲總體頁面比較複雜, 不少其它的資源加載阻塞，致使總體加載完成的時間比較長約 9s，性能提高比例約 22%。

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

1. 因爲咱們的頁面並無所有改形成 QUIC 協議，因此性能數據應該還能夠進一步提高。

2. 每一個業務的頁面構成不同，提高的性能數據也會有差異。

CLB-QUIC-DEMO

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

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

https://github.com/tencentyun/clb-quic-demo

DEMO 的主要目的有兩個：

1. 簡單說明一下在客戶端使用 QUIC。

2. 簡單對比 HTTP2 和 QUIC 的性能差異。

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

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

結    論

QUIC 協議很是複雜，由於它作了太多事情：

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

爲了實現傳輸的安全性，它又完全重構了 TLS 協議，包括證書壓縮，握手消息，0RTT 等。雖而後續可能會採用 TLS1.3 協議，可是事實上是 QUIC 推進了 TLS1.3 的發展。

爲了實現傳輸的併發性，它又實現了 HTTP2 的大部分特性，包括多路複用，流量控制等。

雖然如此複雜，可是 QUIC 做爲一個新興的協議，已經展示了很是強大的生命力和廣闊的前景。

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

咱們不只在服務端實現了 Quic 協議的支持，優化了 QUIC 協議方面的性能問題，同時也但願經過本身一些經驗的分享，推進 QUIC 協議的發展，構造一個更加安全更加快速的互聯網世界。

Let’Quic,  Make Web Faster。