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

 

https://mp.weixin.qq.com/s/44ysXnVBUq_nJByMyX9n5A

讓互聯網更快：通往QUIC之路

原創： 史天 翻譯 雲技術實踐 8月15日

QUIC（Quick UDP Internet Connections）是一種默認加密的新互聯網傳輸協議，它提供了多項改進，旨在加速HTTP傳輸並使其更加安全，目標是想最終取代TCP和TLS協議。在本文中，咱們將概述QUIC協議的一些關鍵特性和它們給Web帶來的好處，以及支持這一全新協議過程當中遇到的一些挑戰。

實際上有兩個協議共享QUIC這個名稱，其一是「Google QUIC」（下稱「gQUIC」），是Google工程師幾年前設計的原始協議，通過多年的實驗，現已被IETF（Internet Engineering Task Force）採用並正在進行標準化。

 

另外一個是「IETF QUIC」（下稱「QUIC」），因爲和gQUIC有着顯著的差異，所以能夠認爲它是一個單獨的協議。經過許多組織和我的的協做努力，從數據傳輸格式到握手和HTTP映射，QUIC改進了原有的gQUIC設計，但共同目標仍然是儘量讓互聯網變得更快、更安全。那麼，QUIC都提供了哪些改進呢？

 

內置的安全和性能機制

 

QUIC與如今經常使用的TCP相比，一個完全的改變是它的設計目標：默認提供安全的傳輸協議。QUIC經過在傳輸層提供安全特性（如身份驗證和加密）來實現，而以往這些功能一般由更高層的協議（如TLS）處理。

 

最初的QUIC握手方式結合了TCP經典的三次握手與TLS 1.3對端點的認證以及加密參數的協商。對於熟悉TLS協議的人來講，QUIC實際上是取代了TLS記錄協議，保留了TLS握手協議。

 

這不只確保了鏈接始終被認證和加密，並且還使得初始鏈接創建更快：與TCP和TLS 1.3握手相結合所需的兩次往返相比，典型的QUIC握手只須要在客戶端和服務器之間完成一次往返。

不只如此，QUIC還加密了可能被中間設備濫用而干擾鏈接的其它元數據。例如，當使用鏈接遷移時，被動式攻擊可使用數據包序號來關聯多個網絡路徑上的用戶活動（見下文）。經過加密數據包序號，QUIC能夠確保它們不能被鏈接端點以外的任何實體關聯活動。

 

加密也能夠成爲僵化問題（ossification）的有效補救措施，這使得協議的靈活性（例如可以協商不一樣版本的協議）因爲錯誤的假設而在實踐中不能被使用。僵化問題致使了TLS 1.3部署的長期延遲，而在幾回更改（防止中間設備錯誤地阻止新版本的TLS協議）被採用以後才使得部署變得可能。

 

隊頭阻塞

 

HTTP/2提供的重要改進之一是可以將不一樣的HTTP請求複用同一個TCP鏈接，這使得HTTP/2應用程序能夠並行處理請求並更好地利用可用的網絡帶寬。

 

這是一項重大改進，若是想要同時處理多個HTTP/1.1請求（例如當瀏覽器須要同時獲取CSS和JavaScript資源渲染網頁時），應用程序須要啓動多個TCP + TLS鏈接。建立新鏈接須要重複屢次初始握手，以及初始擁塞窗口加速，這意味着網頁的渲染速度會下降，而多路複用HTTP則避免了這些問題。

然而，它也有一個缺陷，因爲多個請求/響應使用相同的TCP鏈接傳輸，因此它們都受到數據包丟失的影響（例如因爲網絡擁塞），即便丟失的數據僅涉及單個請求。這種現象被稱爲「隊頭阻塞」。

 

QUIC更進一步爲多路複用提供了良好的支持，使得不一樣的HTTP流能夠依次映射到不一樣的QUIC傳輸流，可是它們仍然共享相同的QUIC鏈接，所以不須要進行額外的握手，而且共享擁塞狀態， QUIC流是獨立傳遞的，所以在大多數狀況下，一個流的數據包丟失不會影響其它傳輸流。

 

這能夠大大減小例如渲染完整網頁（包括CSS、JavaScript、圖片和其它類型資源）所需的時間，特別是在經過具備較高丟包率的高擁塞網絡時。

 

這很簡單，呃？

 

爲了實現這些目標，QUIC協議須要打破許多網絡應用程序認爲理所固然的一些假設，這可能使QUIC的實現和部署更加困難。

 

QUIC的設計基於UDP數據報來簡化部署，同時避免部分網絡設備丟棄未知協議數據包的問題，由於絕大多數設備已經支持UDP。這也容許了QUIC在用戶空間中實現，例如，瀏覽器可以實現新的協議功能併發送給用戶，而無需等待操做系統更新。

 

然而，儘管預期的目標是避免破壞，但它仍在防止濫用並將數據包路由到正確的端點方面極具挑戰性。

 

經過一個NAT問題深刻理解

 

典型的NAT路由器可使用傳統的4元組（源IP地址和端口，目的IP地址和端口）跟蹤經過它們的TCP鏈接，並經過觀察傳輸的TCP SYN、ACK和FIN數據包，能夠檢測到鏈接的創建和終止。這樣能夠精確地管理NAT綁定的生命週期和內外部IP地址和端口的關聯關係。

可是這在QUIC還不能實現，由於目前部署的NAT路由器不瞭解QUIC，所以它們一般會回退到默認配置，而後對UDP流處理的不太準確，一般會使用任意的，有時很是短的超時，可能會影響長時間運行的鏈接。

 

當NAT從新綁定時（例如超時），NAT外部的端點將看到來自與最初創建鏈接時觀察到的源端口不一樣的數據包，這使得僅使用4元組沒法跟蹤鏈接。

不只僅是NAT！QUIC旨在提供的功能之一稱爲「鏈接遷移」，容許QUIC端點隨意遷移到不一樣IP地址和網絡路徑的鏈接。例如，當已知的Wi-Fi網絡可用時（例如，當用戶進入他們喜歡的咖啡店時），移動客戶端可以在蜂窩數據網絡和Wi-Fi之間遷移QUIC鏈接。

 

QUIC試圖經過引入鏈接ID的概念來解決這個問題：一個由QUIC數據包攜帶的可變長度的opaque blob，可用於標識鏈接。端點可使用此ID來跟蹤它們負責的鏈接，而無需檢查4元組（實際上，可能有多個ID標識相同的鏈接，例如，爲了不在使用鏈接遷移時連接不一樣的路徑， 但這種行爲是由端點而不是中間設備控制的）。

 

可是，這也給使用anycast尋址和ECMP路由的網絡運營商帶來了問題，其中單個目標IP地址可能潛在地識別數百甚至數千個服務器。因爲這些網絡使用的邊緣路由器還不知道如何處理QUIC流量，所以可能會發生UDP數據包雖然屬於相同的QUIC鏈接（即具備相同的鏈接ID）但具備不一樣的4元組（因爲 NAT從新綁定或鏈接遷移）被路由到不一樣的服務器，從而破壞了鏈接。

爲了解決這個問題，網絡運營商可能須要採用更智能的4層負載均衡解決方案，它們能夠經過軟件實現，而無需接觸邊緣路由器便可部署（參見Facebook的Katran項目）。

 

QPACK

 

HTTP/2帶來的另外一個好處是頭部壓縮（header compression或HPACK），它容許HTTP/2端點經過從HTTP請求和響應中刪除冗餘來減小網絡傳輸的數據量。

 

特別是，在其它技術中，HPACK使用以前的HTTP請求（或響應）發送（或接收）的報頭動態填充表項，容許端點在新請求（或響應）中引用先前遇到的報頭，而不是再次傳輸。

 

HPACK的動態表須要在編碼器（發送HTTP請求或響應的一方）和解碼器（接收它們的一方）之間同步，不然解碼器將沒法解碼它接收的內容。

 

對於TCP上的HTTP/2，這種同步是透明的，由於傳輸層（TCP）負責以與發送它們相同的順序提供HTTP請求和響應，更新表的指令能夠簡單地由編碼器做爲部分請求（或響應）自己，使得編碼很是簡單。但對於QUIC來講，這有些複雜。

 

QUIC能夠獨立地在不一樣的流上處理多個HTTP請求（或響應），這意味着雖然就單個流而言它負責按順序交付數據，可是跨多個流是沒有順序保證的。

 

舉例來講，若是客戶端經過QUIC流A發送HTTP請求A，而後經過流B發送請求B，因爲網絡中的數據包從新排序或丟失，可能會發生服務器在請求A以前接收到請求B，而且請求B被編碼引用了來自請求A的頭，那麼服務器將沒法解碼它，由於它尚未接收到請求A。

 

在gQUIC協議中，經過簡單地在同一gQUIC流上串行化全部HTTP請求和響應頭（不是body）來解決這個問題，這意味着不管如何都會按順序傳遞報頭。這是一個很是簡單的方案，能夠實現重用大量現有的HTTP/2代碼，但另外一方面它增長了QUIC指望減小的隊頭阻塞。所以，IETF QUIC工做組設計了一組HTTP和QUIC之間（「HTTP/QUIC」）的新映射關係，以及稱爲「QPACK」的新報頭壓縮方案。

 

在HTTP/QUIC映射和QPACK規範的最新草案中，每一個HTTP請求/響應交換使用自身的雙向QUIC流，所以沒有隊頭阻塞。此外，爲了支持QPACK，每端須要額外建立兩個單向QUIC流，一個用於向另外一個對等體發送QPACK表更新，另外一個用於確認另外一方接收的更新。這樣，QPACK編碼器只有在解碼器明確確認以後才能使用動態表引用。

 

應對反射攻擊

 

基於UDP的協議中的一個常見問題是它們容易受到反射攻擊，攻擊者經過源IP地址欺騙（它們看起來像是發送自受害者）誘使一些服務器向第三方受害者發送大量數據。

當服務器發送的響應大於收到的請求時，這種攻擊很是有效，這種狀況咱們稱爲「放大」。

TCP一般不受這種攻擊影響，由於在握手期間發送的初始數據包（SYN，SYN+ACK，...）具備相同的長度，因此它們不具備任何放大的潛力。

 

另外一方面，QUIC的握手是很是不對稱的：像TLS同樣，在第一次傳輸中，QUIC服務器一般發送本身的證書鏈，這可能很是大，而客戶端只須要發送幾個字節（QUIC包中嵌入的TLS ClientHello消息）。所以，客戶端發送的初始QUIC數據包必須填充到特定的最小長度（即便數據包的實際內容要小得多）。然而，這種緩解仍然不夠，由於常見的服務器響應會跨多個數據包，可能仍遠遠大於客戶端填充後的數據包。

 

QUIC協議還定義了一種顯式的源地址驗證機制，服務器先不發送長響應，而是僅發送一個小得多的retry數據包，其中包含一個惟一的加密令牌，而後客戶端必須在新的初始數據包中迴應它。這樣，服務器就更方便確認客戶端不會進行源IP地址欺騙（由於它收到了retry數據包），而且能夠完成握手。這種緩解方法的缺點是它將初始握手持續時間從單次往返增長到兩次。

 

另外一種解決方案經過減小服務器響應下降反射攻擊效果，例如採用ECDSA證書（一般比RSA小不少）。此外，也能夠嘗試經過現成的壓縮算法（如zlib和brotli）壓縮TLS證書，這也是gQUIC最初引入的特性，但目前在TLS中還不可用。

 

UDP性能

 

QUIC常常出現的問題之一是已經部署的硬件和軟件沒法識別它。前面介紹了QUIC如未嘗試解決路由器等網絡中間設備問題，但另外一個可能存在的問題是在QUIC端點上經過UDP發送和接收數據的性能。多年來，不少工做旨在優化TCP，包括在軟件（如操做系統）和硬件（如網絡接口）中構建卸載功能，但目前這些功能都不適用於UDP。

 

然而，QUIC具有這些功能只是時間問題。以最近在Linux上實現UDP通用分段卸載（Generic Segmentation Offloading）的工做爲例，這將容許應用程序在用戶空間和內核空間網絡堆棧之間聚集和傳輸多個UDP段轉換爲單個（或者近似）UDP段。此外，還有在Linux上添加zerocopy套接字支持的例子，這將使應用程序避免將用戶空間內存複製到內核空間。

 

結論

 

與HTTP/2和TLS 1.3同樣，QUIC將提供多項旨在提升網站性能和安全等方面的新功能，目前IETF工做組計劃在今年年末前提供QUIC規範的初版。

 

原文連接：

https://blog.cloudflare.com/the-road-to-quic/

 

https://mp.weixin.qq.com/s/_RAXrlGPeN_3D6dhJFf6Qg

原創： 羅成 InfoQ 1月2日

 

做者｜羅成編輯｜小智本文主要介紹 QUIC 協議在騰訊內部及騰訊雲上的實踐和性能優化。欲瞭解 QUIC 協議產生的背景和核心特性，可閱讀今日二條推文。寫在前面

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

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

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

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

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

QUIC 在騰訊的實踐

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

1. 高性能。

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

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

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

2. 強大的功能。

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

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

3. 穩定性。

• 代碼徹底自主可控。

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

同時咱們也在騰訊不少業務包括 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。