QUIC协议的演进之路
當通過網絡傳輸數據時，一種新的協議QUIC（Quick UDP Internet Connection，快速UDP互聯網連接）正在成為FAANG的默認選擇。本篇文章描述了QUIC協議是如何克服其他版本HTTP的限制脫穎而出的。
?
FAANG是美國市場上五大最受歡迎和表現最佳的科技股的首字母縮寫，即Facebook、Apple、Amazon、Netflix和Google。
?
HTTP的演進
?
HTTP屬于應用層傳輸協議，運行于TCP/IP之上。現在它已成為萬維網中數據交換的基礎。HTTP包括4個穩定版本：HTTP/0.9、HTTP/1.0、HTTP/1.1 和HTTP/2。HTTP/3于2018年首次提出，目前已獲得全球2/3 web瀏覽器的支持。
HTTP/0.9（1991）
?
HTTP/0.9是HTTP的第一個版本，用作W3C的底層通信協議。它是一個非常簡單的客戶端-服務器、請求-響應、使用Telnet的協議，只支持GET命令（作為請求方法）和超文本協議（作為響應類型）。該協議不包含HTTP消息頭，且發送響應后，連接會立即斷開。
?
HTTP/1.0（1996）
?
?
?
?
HTTP/0.9極其簡單，且使用非常受限。新的HTTP版本HTTP/1.0引入了很多新特性，使它更加通用。這些新的特性包括：
?
每次HTTP 請求/響應都會重新建立TCP連接
添加了對 POST 和 HEAD 方法的支持
協議頭帶有版本號、協議類型、狀態碼字段
響應類型：超文本、腳本、媒體、樣式表
支持keep-alive連接，但默認情況下它是“關閉”的
?
HTTP/1.1（1997）
?
?
HTTP/1.0的主要缺陷是：它在每次請求\響應時都要建立新的TCP連接。這種做法非常耗時，且影響客戶端和服務器的性能。HTTP/1.1的出現解決了這一問題：
?
單個TCP連接上可以傳送多個HTTP請求和響應
添加了對 PUT、DELETE、TRACE、OPTIONS 方法的支持
默認持久連接
?
HTTP/2（2015）
?
隨著流媒體內容的增加，網站也開始變得越來越復雜。為了滿足這種需求，HTTP/1.1的功能不斷擴展：首次支持多個TCP連接，并試驗性地引入了管道機制（pipelining），即在同一個TCP連接里面，客戶端可以同時發送多個請求。但擴展不可能無止境，最終需要采用一個新的協議，于是HTTP/2出現了，該協議包括如下重大改進：
?
多路復用：這是HTTP/2的一個特性，允許同時通過單個TCP連接發起多重請求-響應消息。每次HTTP請求-響應都被分割成二進制幀，客戶端和服務器都以二進制幀為基本單位發送消息（請求和響應）。通過多路復用，客戶端無需再等待上一個請求完成就可以發送多重請求。這樣，HTTP/2便解決了HTTP隊頭阻塞（HoL）的問題。如圖所示：
?
?
頭部壓縮：使用 HPACK 壓縮消息頭
非阻塞下載
支持服務器推送
采用二進制分幀，不再是純文本
解決了隊頭阻塞問題
?
HTTP/3（2018）
?
通過多路復用，HTTP/2解決了隊頭阻塞問題。但如果TCP流中出現了丟包，根據TCP的擁塞控制機制，其他數據流就只能等待丟包被重新發送和接收。所以，TCP的隊頭阻塞問題在HTTP/2中依然存在。
?
HTTP/3通過使用基于UDP的傳輸協議QUIC解決了這一問題。
?
HTTP/3是自HTTP/2之后最新且最主要的HTTP版本。因為HTTP/3本身就是為QUIC協議設計的，所以也被描述為基于QUIC的HTTP/2。HTTP/3的目標是通過使用谷歌的QUIC協議提供快速、可靠安全的網絡連接。HTTP/3包括以下特性：
?
使用基于UDP的QUIC作為傳輸協議
解決了TCP隊頭阻塞問題
使用QPACK頭部壓縮機制
提供更快頁面加載時間
?
?
HTTP/2 VS HTTP/3
?
下圖展示了HTTP/2和HTTP/3兩者的對比：
?
?
?
相同點：
?
HTTP/2 和 HTTP/3 使用相同的語法和語義結構，并且適用于同一請求/響應方法、狀態碼和協議字段。此外，兩者都使用設計相似的頭部壓縮算法（HPACK 和 QPACK）。
?
不同點：
特性 | HTTP/2 | HTTP/3 |
傳輸層協議 | TCP | 基于UDP的QUIC |
頭部壓縮算法 | HPACK | QPACK |
隊頭阻塞問題 | 解決HTTP隊頭阻塞 | 同時解決HTTP和TCP 隊頭阻塞 |
握手協議 | TCP ?+ TLS | QUIC |
加密協商 | 可通過TLS（默認版本為1.2，后續版本可選）與ALPN協議擴展進行協商 | 使用用于QUIC協議的Alt-Svc（以 TLS 1.3 作為 TLS 的最低版本） |
握手時間 | 因為需要TCP和TLS 握手，所以更慢 | QUIC協議直接處理數據流，所以更快 |
QUIC是一種新的多路傳輸層網絡協議標準，建立在 UDP 之上。QUIC的主要目標是通過減少頁面加載時間提升用戶體驗，并提高HTTPS的傳輸性能。它在本質上是TCP+TLS+HTTP/2。
設計HTTP/3的目的就是要充分利用 QUIC 的優勢。QUIC 協議本身可以處理數據流，所以排除了 TCP 隊頭阻塞問題。
?
QUIC 的一些關鍵特性包括：
基于UDP
使用沒有隊頭阻塞的連接復用
重構TCP的關鍵機制（連接復用、連接建立、擁塞控制、可靠性），并成為可靠的傳輸協議
?
?
交換數據包
?
對于典型的QUIC協議，客戶端和服務器之間交換了三種類型的數據包，如下圖所示：
?
?
QUIC連接建立和安全的凈荷包
?
1. 安全的首包
首先，客戶端在一個CRYPTO?幀中傳輸包含TLS 1.3 Client Hello的首包。Client Hello包含不同類型的的擴展項，如目標服務器的SNI（Server Name Indication，服務器名稱指示 ）、QUIC 傳輸參數、壓縮證書等，以及客戶端支持的壓縮方法和不同的加密套件。
?
如果服務器接受QUIC和TLS 1.3參數，它也會在CRYPTO幀中發送包含對客戶端首包確認信息和TLS 1.3 Server Hello的首包信息。Server Hello中包含被服務器接收的加密套件和不同的擴展（如密鑰共享、支持的版本等）。在客戶端接收到 Server Hello后，會向服務器發送一個ACK確認包。
?
這三個首包都可能包含一個填充幀，以根據需要增加數據包的大小。
?
2. 握手包
客戶端和服務器之間的首包被交換以后，服務器會發送一個握手數據包，其中包含余下的服務器端消息，如證書、與服務器身份驗證相關的加密擴展。客戶端會驗證這些證書，然后QUIC 握手以客戶端發送的握手消息結束。
?
3. 安全的凈荷包
一旦安全的QUIC連接建立，客戶端與服務器之間的信息便可以安全傳輸。
?
QUIC 0-RTT
?
為了縮短建立新連接的時間，QUIC采用0-RTT。在這里，如果客戶端之前使用1-RTT連接到服務器，則服務器必須存儲與流量控制相關的傳輸參數的副本，如 initial_max_data、initial_max_stream_data_bidi_local 等。
?
下一次，在QUIC 0-RTT模式中，客戶端立即開始與服務器的數據傳輸，不需要等待握手完成。
?
然而，0-RTT也有設計上的缺陷：允許重放攻擊。
?
我們為什么要用QUIC？
?
傳統的TCP協議是建立在操作系統層和中間路由模塊之上實現的，它的握手階段信息很容易被這些中間模塊篡改而變得不安全。
?
但QUIC協議是在UDP之上的用戶級（如瀏覽器）中實現的，因此它更加靈活、對用戶更友好，并且能夠在短時間內支持更多設備。
?
在 QUIC 中，傳輸相關的信息被不同的保護層加密，握手包在傳輸鏈路上不容易被識別和修改。因此它提供了更安全的網絡數據傳輸。
延伸閱讀：
QUIC Version 1 (RFC 9000) 作為標準化版本現已發布
一文看懂WebTransport
QUIC助力Snapchat提升用戶體驗
新一代直播傳輸協議SRT
三十年TCP與七年QUIC 誰才是未來？
?
翻譯?/ Alex?
技術Review / 袁榮喜
原文鏈接：
https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2021/07/16/road_to_quic-DGa5.html
特別說明：原作者Anubhab Sahu已授權本文的翻譯與發布，特此感謝。
?
?詳情請掃描圖中二維碼或點擊閱讀原文了解大會更多信息。
超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生總結
以上是生活随笔為你收集整理的QUIC协议的演进之路的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 音视频、AI和5G等技术在东京奥运会中的
- 下一篇： 音视频技术开发周刊 | 207