QUIC（Quick UDP Internet Connections）是一種基于UDP的傳輸層協議，旨在減少網絡延遲、提升安全性并優化多路復用能力。它由Google開發，后被IETF標準化為HTTP/3的底層協議。
1、QUIC是什么？
QUIC（Quick UDP Internet Connections）（發音同“quick”）是由Google發起、IETF標準化的基于UDP的新一代傳輸層協議，旨在替代傳統的TCP + TLS組合，解決其性能瓶頸。
目標：
降低連接延遲、提升傳輸性能、支持多路復用、避免隊頭阻塞。
2、傳統HTTP/TCP/TLS的問題
在理解QUIC之前，先看傳統方案的痛點：
總延遲：2~3RTT才能開始傳輸數據，移動端或高延遲網絡下體驗差。
3、QUIC的核心優勢（一句話總結）
QUIC = UDP + TLS 1.3 + HTTP/3 + 多路復用 + 連接遷移，在0-RTT或1-RTT內完成安全連接并傳輸數據。
4、QUIC的架構與分層
注意：QUIC運行在用戶空間（不是內核TCP），可快速迭代，無需操作系統支持。
5、QUIC的核心工作機制
1、基于UDP，避免內核TCP擁塞控制限制
- 使用UDP作為底層傳輸，繞過操作系統內核的TCP協議棧。
- QUIC自己實現可靠傳輸、重傳、擁塞控制等邏輯（在應用層）。
優勢：可快速升級、定制擁塞算法（如BBR）、支持0-RTT。
2、加密與傳輸一體化（TLS 1.3內嵌）
QUIC將加密（TLS 1.3）直接集成在協議中：
- 加密握手與連接建立合并，減少RTT。
- 所有QUIC包（包括握手包）都加密，提升安全性。
- 支持0-RTT快速重連（類似會話恢復）。
對比：
- TCP + TLS 1.3：1-RTT（或0-RTT）
- QUIC + TLS 1.3：首次1-RTT，重連可0-RTT
3、多路復用（Multiplexing）徹底解決隊頭阻塞
在HTTP/2中，多個請求復用一個TCP連接，但一旦某個數據包丟失，所有流都阻塞（TCP層隊頭阻塞）。
QUIC的解決方案：
- 每個“流”（Stream）獨立傳輸。
- 一個流的數據包丟失，不影響其他流。
- 實現真正的“無隊頭阻塞”多路復用。
示例：
- 流1：圖片加載（丟包）→ 重傳，不影響流2：JS文件加載
4、連接遷移（Connection Migration）
**傳統TCP基于四元組（源IP:端口, 目的IP:端口）**標識連接。
手機從Wi-Fi切換到4G，IP改變 → TCP連接中斷。
QUIC使用連接ID（Connection ID）唯一標識連接：
- 即使IP或端口變化，只要Connection ID不變，連接可繼續。
- 實現“無縫切換網絡”。
適用于移動設備、弱網環境。
5、可插拔的擁塞控制
QUIC在用戶空間實現擁塞控制，支持動態更換算法：
- 支持：Cubic、BBR、Reno等
- 可根據網絡狀況動態調整
傳統TCP擁塞控制在內核中，難以修改。
6、QUIC的通信流程
1、連接建立階段
QUIC的連接建立分為兩種模式：首次連接（1-RTT）和重連（0-RTT）。
1、首次連接（1-RTT）
交互示例圖：
說明：
- CH: Client Hello
- SH: Server Hello
- SC: Server Certificate
- SE: Server Encrypted Extensions
- 所有包都加密（AEAD）
- 客戶端在第一個包就發送應用數據（1-RTT完成）
具體解釋：
(1)、客戶端發送Initial Packet
數據包含：
- ClientHello（TLS 1.3握手消息）。
- 客戶端支持的QUIC版本號。
- 初始加密密鑰（TLS 1.3的Key Share擴展）。
示例：
客戶端生成臨時密鑰對（如X25519曲線），在Key Share中發送公鑰。
(2)、服務器響應Initial和Handshake Packet
服務器驗證客戶端的ClientHello，生成自己的密鑰對，并發送：
- ServerHello（包含服務器公鑰）。
- 證書（CERT）和完成消息（FIN）。
- ACK確認收到客戶端的Initial Packet。
(3)、客戶端完成密鑰協商
- 客戶端計算共享密鑰，發送Finished消息確認握手完成。
- 此時，客戶端可發送應用數據（如HTTP請求）。
(4)、服務器確認連接
- 服務器收到Finished后，發送ACK和HANDSHAKE_DONE，連接建立完成。
2、重連（0-RTT）
前提：客戶端和服務端之前已建立過連接，有共享密鑰。
關鍵：0-RTT數據可被重放（Replay Attack），因此只能用于冪等操作（如GET請求）。
交互示例圖：
具體步驟：
（1）、客戶端復用舊會話參數
- 客戶端使用之前連接的加密參數（如PSK，預共享密鑰）直接發送Initial Packet和應用數據。
- 示例：客戶端在Initial Packet中攜帶緩存的Session Ticket（TLS 1.3的PSK擴展）。
（2）、服務器驗證并響應
- 服務器驗證PSK后，直接接受數據并發送ACK，無需等待客戶端確認。
- 數據傳輸立即開始，實現0-RTT連接。
2、數據傳輸階段
1、多路復用流管理
- 每個HTTP請求/響應分配唯一的流ID（Stream ID）。
- 流類型：
- 雙向流（Bidirectional Stream）：客戶端與服務器雙向通信（如HTTP請求/響應）。
- 單向流（Unidirectional Stream）：單向傳輸（如服務器推送）。
2、流量控制
- 滑動窗口（Flow Control）：通過WINDOW_UPDATE幀動態調整接收窗口大小，防止緩沖區溢出。
- 連接級與流級控制：每個流和整個連接獨立控制流量。
3、擁塞控制
- 默認使用BBR（Bottleneck Bandwidth and RTT）或Cubic算法。
- 動態調整發送速率，避免網絡擁塞。
4、丟包恢復
- ACK幀：接收方定期發送ACK確認收到的數據包。
- 重傳機制：未收到ACK的數據包在超時后重傳。
- 前向糾錯（FEC）：弱網環境下發送冗余數據包，減少重傳次數。
3、連接終止階段
1、優雅關閉（Graceful Shutdown）
- 任一端發送CONNECTION_CLOSE幀，通知對方終止連接。
- 包含錯誤碼和可選調試信息。
2、立即關閉（Immediate Close）
- 發送PUBLIC_RESET包強制終止連接（如檢測到錯誤）。
7、QUIC 的數據包結構（簡要）
每個QUIC包包含：
特點：
- 包頭加密（除部分必要字段）
- 支持亂序到達、獨立確認（ACK）
- 每個STREAM Frame攜帶一個流的數據
8、QUIC與傳統協議的對比
9、QUIC的應用場景
1、HTTP/3
- QUIC是HTTP/3的傳輸層協議，顯著提升網頁加載速度（如減少TLS握手延遲）。
2、實時音視頻傳輸
- 多路復用和FEC特性適用于低延遲、高丟包場景（如直播、視頻會議）。
3、物聯網（IoT）
- 弱網環境下（如移動網絡），QUIC的丟包恢復和連接遷移能力保障穩定性。
4、云服務與CDN
- 阿里云、華為云等CDN廠商已支持QUIC，優化內容分發效率（如首屏加載時間減少30%）。
10、QUIC的實現挑戰
1、NAT和防火墻兼容性
- 傳統網絡設備可能丟棄UDP流量，需通過協議設計（如連接ID）繞過限制。
2、部署成本
- 需要客戶端和服務端均支持QUIC（如瀏覽器集成、App集成quiche庫）。
3、調試復雜性
- QUIC的加密和多路復用增加了抓包分析難度，需專用工具（如Wireshark）。
11、總結
QUIC核心要點：
QUIC協議通過基于UDP的多路復用、0-RTT連接、內置加密和智能擁塞控制，解決了傳統TCP+TLS的性能瓶頸。
其工作流程分為連接建立、數據傳輸和終止三個階段，核心**優勢在于低延遲、高安全性和強抗丟包能力。**隨著HTTP/3的普及，QUIC將成為下一代互聯網傳輸協議的主流選擇。
向陽前行，Dare To Be！！！
)
