本文來自騰訊資深研發工程師羅成在InfoQ的技術分享。

本文首發InfoQ公眾號，系騰訊技術工程事業群與InfoQ合作的“騰訊技術工程”專欄第二篇文章，新的一年，我們將會為技術人員提供更多騰訊的技術干貨與落地實踐。

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

本文主要介紹 QUIC 協議在騰訊內部及騰訊云上的實踐和性能優化。欲了解 QUIC 協議產生的背景和核心特性，可閱讀今日二條推文。

寫在前面

如果你的 App，在不需要任何修改的情況下就能提升 15% 以上的訪問速度。特別是弱網絡的時候能夠提升 20% 以上的訪問速度。

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

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

如果這個新興的協議，它的名字就叫做“快”，并且正在標準化為新一代的互聯網傳輸協議。

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

QUIC 在騰訊的實踐

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

高性能。

• 復用 Nginx 全異步事件驅動框架。
• 私鑰代理計算集群加速簽名計算。
• 全局緩存提速，減少計算量的同時，提升訪問速度。

2.強大的功能。

• • 支持 Nginx 現有全部模塊指令，豐富的第三方模塊。
  • 復用 Nginx 模塊框架，非常靈活地新增第三方功能。

3.穩定性。

• • 代碼完全自主可控。
  • 正在經受騰訊億萬級并發流量的考驗。

同時我們也在騰訊很多業務包括 QQ 空間、WEB 游戲頁面、騰訊云 CLB 上灰度支持了 QUIC 協議。詳細的收益數據可以參考第 6 章。

QUIC 線下測試方案

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

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

頁面構造

根據?http://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 端的控制流程有所區別。分別簡介如下：

移動端測試流程

準備事項：

打開手機的 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 完成即可。

測試結論

由于公司內網的 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 握手。

但是會有兩個問題：

進程間 ID 數據無法共享。

多臺服務器間的 ID 數據無法共享。

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

SeverConfig Cache 集群

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

加密性能的優化

簽名計算

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

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

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

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

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

架構如下圖所示：

簽名代理計算

對稱加密的優化

相比非對稱密鑰交換算法來講，對稱加密算法的性能非常卓越（好 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%。

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

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

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

CLB-QUIC-DEMO

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

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

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

DEMO 的主要目的有兩個：

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

簡單對比 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。

總結

以上是生活随笔為你收集整理的让互联网更快的协议，QUIC在腾讯的实践及性能优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。