QUIC（Quick UDP Internet Connection，快速UDP網絡連接）發音同 "quick"，是 Google 公司在 2012 年提出的使用 UDP 進行多路并發傳輸的協議。

2016 年，互聯網工程任務組 IETF 開始標準化 QUIC。

2017 年，Google 開發并部署了 QUIC 協議的初始設計 gQUIC。

2021 年，QUIC 協議的正式標準化版本 RFC900 發布。

QUIC協議的特性

從 QUIC 的命名中可以看到兩個關鍵詞——快速和 UDP。這個兩個關鍵詞概括了 QUIC 的特性，提供更快速、更可靠、更安全的數據傳輸方式。

快速：QUIC 比 TCP 更簡單，能夠更快速地連接。其安全性也不亞于 TCP+TLS。

UDP：QUIC 是建立在 UDP 之上的新型傳輸協議，一般在應用層發揮作用。

QUIC協議棧

QUIC協議的原理

一個 QUIC 數據包由頭部（Header）和數據（Data）組成。

QUIC數據格式

頭部（Header）中包含以下字段：

標志位（Flags）：用來指示該數據包的類型、狀態等信息。

連接ID（Connection ID）：用于唯一標識一個連接。

版本號（Version）：表示使用的協議版本號。

包編號（Packet Number）：表示數據包的順序。

數據（Data）被拆分成多個小的數據幀（Frame），每個數據幀都有自己的類型、長度和負載。數據幀通過 Stream ID 進行標識，以便于在多路復用時進行管理。

PING 幀：用于測試連接的可用性。

ACK 幀：用于確認收到數據包。

RESET_STREAM 幀：用于重置數據流的狀態。

STOP_SENDING 幀：用于停止向特定的數據流發送數據。

CRYPTO 幀：用于傳輸加密數據。

STREAM 幀：用于傳輸普通數據流。

STREAM幀結構

下面介紹 QUIC 協議中的三個核心特性原來：0-RTT 連接建立、無隊頭阻塞的多路復用、無歧義重傳。

0-RTT 連接建立

QUIC 協議使用了 0-RTT（零往返時間）連接建立技術，可以在客戶端發送第一個請求時就建立起安全連接，從而減少連接建立所需的時間。這個技術通過使用 TLS 的 Session Ticket，在服務端重啟后仍然保留連接狀態，從而避免了重新握手的過程。

傳統 HTTPs 握手包含了 TCP 和 TLS 握手，如下圖所示，總共需要 3 個 RTT。

TCP和TLS握手

從中可以看出，TLS 握手需要 1 個 RTT。通過 1 次 RTT，客戶端和服務端就協商好了通信密鑰。

客戶端：生成隨機數 a，選擇公開的大數 G 和 P，計算 A=a*G%P。發送 Client Hello 消息，將 A 和 G 傳遞給服務端。

服務端：生成隨機數 b，計算 B=b*G%P。發送 Server Hello 消息。將 B 傳遞給客戶端。

客戶端：通過秘鑰加密算法生成通信密鑰 KEY = aB = ab*G%P。

服務端：通過秘鑰加密算法生成通信密鑰 KEY = bA = ba*G%P。

QUIC 的握手是基于 TLS1.3 實現的，建立連接時也應該需要1次 RTT，那 QUIC 的 0-RTT 連接是如何實現的？

首次握手后，QUIC 的客戶端緩存了 Server Hello，那么在下次建連時，可以直接使用緩存數據計算通信密鑰，如下圖所示。

0-RTT連接

客戶端：生成隨機數 c，選擇公開的大數 G 和 P，計算 A=c*G%P。發送 Client Hello 消息，將 A 和 G 傳遞給服務器。

客戶端：直接使用緩存的 Server Hello 計算通信密鑰 KEY = cB = cb*G%P，加密并發送應用數據。

服務端：根據 Client Hello 消息計算通信密鑰 KEY = bA = bc*G%P。

通過緩存 Server Hello，在生成 Client Hello 的同時，加密了應用數據，所以客戶端不需要經過握手就可以發送應用數據，這就是 QUIC 的 0-RTT 連接。

無隊頭阻塞的多路復用

瀏覽器限制了同一個域名下的請求數量。當請求達到最大數量時，剩余的資源需要等待其他資源請求完成后才能發起請求，這就是隊頭阻塞（Head of Line Blocking）。

在傳統的 HTTP/1 協議中，每個 TCP 連接只能處理唯一的請求，因此當需要請求多個資源時，需要建立多個 TCP 連接。為了解決 HTTP/1 的核心問題，在 HTTP/2 中引入了多路復用的技術，這個技術可以只通過一個 TCP 連接就可以傳輸所有的請求數據，如下圖。

多路復用很好的解決了瀏覽器限制同一個域名下的請求數量的問題，從而提高網絡吞吐量。此外，QUIC 協議還支持數據流級別的擁塞控制，可以更精細地控制網絡擁塞。

TCP連接

HTTP/2 雖然通過多路復用解決了 HTTP 層的隊頭阻塞，但仍然存在 TCP 層的隊頭阻塞問題。在 HTTP/2 中，如果 TCP 連接中出現了丟包的情況，那么整個 TCP 都要開始等待重傳，后面的所有數據都將被阻塞。在這種情況下， HTTP/2 的表現情況反倒不如 HTTP/1 。

QUIC 通過為每個請求流都分配一個獨立的滑動窗口，解決 TCP 層的隊頭阻塞。如下圖，A 請求流上的丟包不會影響 B 請求流上的數據發送。

QUIC連接

無歧義重傳

為了保證可靠性，TCP 使用基于序號的 Sequence Number 和 Ack 來確認消息的有序到達。在 TCP 中，重傳包的 sequence number 和原始包的Sequence Number 是不變的，也正是因此這個特性，引發了 Tcp 重傳歧義問題。當超時事件 RTO 發生后，客戶端發起重傳，然后接收到了 Ack 數據。但由于 Sequence Number 是一樣的，這個接收到的 Ack 到底是原始請求的響應還是重傳請求的響應呢？這導致了 RTT 計算歧義。

TCP重傳歧義性

QUIC 則是采用了單向遞增的 Packet Number 來標識數據包，因此不會像 TCP 一樣，不會因為超時重傳了同樣序列的數據包，造成 RTT 和 RTO（Retransmission Time Out，重傳超時時間）的計算不準確。每個 Packet Number 都嚴格遞增，就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經不是 N，而是一個比 N 大的值。

QUIC的RTT計算

QUIC 對于 RTT 的計算更為準確，預估的超時時間能夠有效防止更多的重傳請求被錯誤地發送回客戶端。同時也給予了 QUIC 網絡更為快速的反應時間，及時通知客戶端重傳數據包。

但是單純依靠嚴格遞增的 Packet Number 肯定是無法保證數據的順序性和可靠性。

QUIC 引入了 Stream Offset 的概念，通過 Stream Offset 可以保證應用數據的順序。假設客戶端先后發送了 Pakcet N 和 Pakcet N+1，Stream Offset 分別是 x 和 x+y。如果 Packet N 丟失，引發重傳，重傳的 Packet Number 是 N+2，但是它的 Stream Offset 依然是 x，這樣就算 Packet N + 2 是后到的，依然可以將 Stream x 和 Stream x+y 按照順序組織起來，交給應用程序處理。

QUIC協議的應用場景

QUIC 為各種領域提供了可靠、高效和安全的數據傳輸方案，其中最具潛力的應用場景包括：

實時 Web 和移動應用

這些應用需要低延遲和可靠的數據傳輸。通過相互獨立的數據流和擁塞控制機制，QUIC 可以快速高效地發送和接收數據。在多路復用模式下，QUIC 同一連接內不同數據流之間的數據傳輸互不干擾。

與物聯網設備通信

物聯網設備通常使用 TCP 和 MQTT 等協議進行通信，在受限的網絡環境中可能存在高延遲和丟包等問題。相比之下，QUIC 可以極近實現 0-RTT，為高延遲和丟包的網絡環境，提供了更可靠和高效的替代方案。

支付和電子商務應用

這些應用需要安全可靠的數據傳輸。QUIC 通過 TLS 加密和可靠的數據流，使其成為這些應用的理想選擇，有助于保證數據安全完整地傳輸。從用戶的角度來看，QUIC 通過保證更快、更順暢的交易，優化了用戶體驗。

當前，QUIC 協議已經成為 IETF 標準化工作組的一個項目，并且越來越多的互聯網公司開始支持 QUIC 協議。隨著 QUIC 協議的普及，我們可以期待更快、更安全、更可靠的網絡體驗。

審核編輯：湯梓紅