作者：趙詠
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的使用情況
很多年前，谷歌和Meta（原Facebook）對QUIC協議分別進行了研究，甚至Facebook還實現了一個TCP版本的QUIC。後來，他們在研究上分列兩個陣營，一個是谷歌的gQUIC，另一個是IETF-QUIC。不過最後，他們達成了一致，均歸為IETF-QUIC陣營，也就是現今QUIC的雛形。
作為主推者，谷歌和Facebook旗下的App已大量使用QUIC進行通訊。那麼如今他們以及各大網際網路廠商都在QUIC上有哪些進展呢？
- 谷歌：作為使用廣泛的移動作業系統Android，其自帶瀏覽器元件Webview均預設支援QUIC，Chrome及其衍生瀏覽均支援QUIC。還有一些和使用者生活連線緊密的App也會嘗試使用QUIC，比如Youtube、Gmail、Google map、Google Play等。這些在支援使用的場景下都會預設進行QUIC的傳輸。
- Facebook：Facebook、Messenger、Instagram、Whatsapp等旗下較為知名的App和谷歌使用類似的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版本，由谷歌打造並廣泛使用。QUIC的載荷內容能夠看到的只有ClientHello包和Rejection包，其他的資料包均是加密的，沒有祕鑰看不到。因此我們先介紹一下暴露在外面的內容，如下圖是gQUIC的ClientHello包結構，在wireshark裡面顯示的是IETF QUIC。這是因為兩個分支正在融合，在這部分是基本一致的，包括包頭、CRYPTO和PADDING三部分。包頭是一些基本資訊，重要的是版本號和Connection ID。
CRYPTO包含具體的握手引數，這是與gQUIC和IETF QUIC區別最大的地方。但它們的作用類似，都是提供域名、加密引數之類的握手所需要的資訊。下圖則是gQUIC中的格式，是谷歌自己定義的：
在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 資訊，請參見：
https://developer.huawei.com/...
開發指南：
https://developer.huawei.com/...
瞭解更多詳情>>
訪問華為開發者聯盟官網
獲取開發指導文件
華為移動服務開源倉庫地址：GitHub、Gitee
關注我們，第一時間瞭解 HMS Core 最新技術資訊~