當通過網絡傳輸數據時，一種新的協議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) 作爲標準化版本現已發佈
詳情請掃描圖中二維碼或點擊閱讀原文瞭解大會更多信息。
本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。