揭開「QUIC」的神秘面紗
- 2022 年 1 月 4 日
- 筆記
作者：趙詠
QUIC的發音類似於Quick，實際上也確實很快。它可以很好地解決應用在傳輸層和應用層面臨的各種需求，包括處理更多的連接、安全性以及低延遲。
目前在互聯網領域，QUIC可以說颳起了新一代互聯網傳輸協議的風。對開發者而言，了解QUIC更是有助於時延敏感性應用以及音影片、購物支付等應用場景的體驗提升。
1 QUIC擁有兩大優勢
*** 0RTT，建立低延遲傳輸**
傳統的TLS協議，需要經過兩級握手實現用戶數據的傳輸。第一級包括TCP的三次握手，至少需要一個來回；第二級是TLS協議的握手，通過ClienHello、ServerHello幾次握手的數據包協商後才能開始用戶數據傳輸。
雖然TLS1.3在TLS握手階段進行了優化，支援在首包ClientHello傳輸數據，但TCP的握手還是無法節省。QUIC協議則拋棄了TCP協議，改用UDP作為底層傳輸協議，進一步壓縮了TCP三次握手所帶來的時延，達到了真正的0RTT。這一優勢對時延敏感型的應用很有吸引力，也給影片類應用提供了切換至QUIC協議的動力。
*** 加密傳輸**
大部分互聯網公司都十分注重用戶的安全隱私，始終持續推進數據的加密傳輸。這項工作需要兩個協議支撐，分別是HTTP協議和DNS協議。
（1） HTTP協議從1.1版本升級到2.0再到3.0，本身並沒有涉及加密的內容，僅在時延問題上改進。但與HTTP協議伴生的TLS協議專職進行加密，從TLS1.2升級到了TLS1.3，不僅增強了加密的強度，還將原先的明文握手部分進行了大幅加密。甚至，TLS協議計劃未來將所有的握手部分均加密。
（2） DNS協議與HTTP協議也是伴生狀態，但不可避免的會泄露HTTP協議中的域名資訊。因此，DNS的加密一般會同時進行。
目前主流的解決方案是使用TLS進行加密，但QUIC協議擁有和TLS類似的加密能力，且性能更好。這打破了TLS協議對加密的壟斷，成為其最大競爭者。
2 QUIC的使用情況
很多年前，Google和Meta（原Facebook）對QUIC協議分別進行了研究，甚至Facebook還實現了一個TCP版本的QUIC。後來，他們在研究上分列兩個陣營，一個是Google的gQUIC，另一個是IETF-QUIC。不過最後，他們達成了一致，均歸為IETF-QUIC陣營，也就是現今QUIC的雛形。
作為主推者，Google和Facebook旗下的App已大量使用QUIC進行通訊。那麼如今他們以及各大互聯網廠商都在QUIC上有哪些進展呢？
-
Google：作為使用廣泛的移動作業系統Android，其自帶瀏覽器組件Webview均默認支援QUIC，Chrome及其衍生瀏覽均支援QUIC。還有一些和用戶生活連接緊密的App也會嘗試使用QUIC，比如Youtube、Gmail、Google map、Google Play等。這些在支援使用的場景下都會默認進行QUIC的傳輸。
-
Facebook：Facebook、Messenger、Instagram、Whatsapp等旗下較為知名的App和Google使用類似的QUIC策略。
-
Apple：蘋果在QUIC上的策略沒有那麼激進，但已經將QUIC作為未來趨勢進行準備，包括QUIC上線所配套的DoH伺服器。另外，蘋果已經在最新的iCloud+ Private Relay中使用了QUIC作為代理傳輸協議。
-
CloudFlare：作為一個CDN廠商，ClouFlare一直大力推動QUIC的使用，覆蓋大量chrome+小網站模式下的流量，讓這些流量默認使用QUIC。
-
Snapchat：跟隨著Google的腳步，這款較為風靡的聊天軟體，也大量使用了QUIC。
-
中國互聯網廠商：快手、搜狐影片主力使用QUIC傳輸影片，目前是中國推進最快的。微信、淘寶、愛奇藝、抖音、百度已在部分流量或者部分時延場景下啟用QUIC。使用QUIC逐漸成為中國互聯網廠商的潮流。
3 QUIC協議格式
經過長時間的演變以及兩個陣營的研究，QUIC協議具有很多分支和變種。這裡我們省略一些前期變化的敘述，聚焦當前的情況展開。目前，QUIC協議主要有兩大分支版本。
- gQUIC版本，由Google打造並廣泛使用。QUIC的載荷內容能夠看到的只有ClientHello包和Rejection包，其他的數據包均是加密的，沒有秘鑰看不到。因此我們先介紹一下暴露在外面的內容，如下圖是gQUIC的ClientHello包結構，在wireshark裡面顯示的是IETF QUIC。這是因為兩個分支正在融合，在這部分是基本一致的，包括包頭、CRYPTO和PADDING三部分。包頭是一些基本資訊，重要的是版本號和Connection ID。
CRYPTO包含具體的握手參數，這是與gQUIC和IETF QUIC區別最大的地方。但它們的作用類似，都是提供域名、加密參數之類的握手所需要的資訊。下圖則是gQUIC中的格式，是Google自己定義的：
在IETF QUIC里的CRYPTO裝的是一個TLS的ClientHello，基本上直接複製了TLS的格式。下圖是IETF QUIC的CRYPTO格式，從外部格式看這是兩個QUIC分支最大的區別點：
外部能看到的格式介紹到這裡，已經說明了90%，其他部分在Wireshark裡面有比較明確的解釋。此外，最新版的QUIC（兩個分支）均使用了Encrypted ClientHello機制，前面介紹的ClientHello在流量裡面是「加密」狀態，看起來是一些隨機的位元組，只有最開始的幾個位元組用來區分不同的QUIC版本。但這個「加密」的秘鑰就藏在ClientHello包裡面，可以現場計算出真正的秘鑰並解密。因此，Wireshark能夠看到明文的ClientHello內容。這種「加密」類似當年的P2P協議，都是為了增加DPI設備的處理難度，最終需要拼CPU算力。如果CPU算力不夠則看不到明文。
4 QUIC的交互過程
Wireshark提供了QUIC流量的解密功能，有秘鑰就能看到加密前的具體內容。這樣我們也就能直觀的看到QUIC的交互過程。事實上，QUIC承擔了TCP的功能，主要是可靠性傳輸的保障能力。從下圖可以看出，內部會傳輸大量的ACK報文，用來確認數據已經收到，基於此再產生重傳等擁塞控制相關的能力。
除了可靠性傳輸的保障能力，QUIC內部存在stream機制。每個stream都可以被認為是一個獨立的流，這樣QUIC本身就是一個大的加密傳輸隧道。QUIC內部實際傳輸數據的協議一般是HTTP3，這讓QUIC和HTTP3產生了強綁定，很多時候大家會把這二者當成是一個東西。Wireshark目前並沒有解析HTTP3，只能看到一些二進位的數據。但HTTP3繼承了HTTP2，數據帶有壓縮，短短的幾個位元組可能就是一個巨大請求壓縮後的結果。
綜上所述，QUIC協議是一個結合多種優秀特性的互聯網傳輸新協議，自然也成為了互聯網各大廠商的新寵兒。對此，華為也推出了HMS Core網路加速套件——hQUIC Kit，幫助開發者在應用中快速支援QUIC協議，再輔以智慧擁塞演算法，最終為用戶提供更快的連接建立速度，更強的抗丟包能力以及更高的吞吐量。hQUIC適用遊戲、影片通話、在線TV/VOD、VR實時廣播等應用場景，其服務優勢有：
-
簡單易用：提供簡單易用的編程介面，屏蔽網路細節。
-
兼容性：兼容gQUIC協議，支援Cronet介面。
-
移動網路體驗提升：提升弱網環境對用戶的體驗。
更多hQUIC Kit 資訊，請參見：
//developer.huawei.com/consumer/cn/hms/huawei-hQUIC/?ha_source=hms1
了解更多詳情>>
訪問華為開發者聯盟官網
獲取開發指導文檔
華為移動服務開源倉庫地址：GitHub、Gitee
關注我們，第一時間了解 HMS Core 最新技術資訊~
