随着互联网业务规模增大、移动网络复杂性提升、用户对低延迟体验需求不断提高，传统的 HTTP/1.1 与 HTTP/2 在多种网络环境下逐渐暴露出局限性。

为解决这些瓶颈，Google 推出了 QUIC 协议，而 QUIC 也成为 HTTP/3 的底层传输方式。如今许多大型网站已经默认使用 HTTP/3（如 Google、Facebook、Cloudflare）。

本文将从底层原理、协议演进、优势对比、网络模型等方面深入讲解 HTTP/3 与 QUIC。

⭐ 1. 背景：HTTP/1.1 → HTTP/2 → HTTP/3 的演进

HTTP/1.1 的问题

• 队头阻塞（HOL Blocking）
• TCP 连接数限制（浏览器一般每域名仅允许 6 个）
• 无法充分利用带宽

HTTP/2 的改进（基于 TCP）

HTTP/2 引入：

• 二进制分帧
• 多路复用
• 头部压缩（HPACK）

但依然受 TCP 限制：

• 一个 TCP 连接所有流都会被一个丢包阻塞（TCP-level HOL）
• TLS 握手耗时长（1~2 RTT）

这迫使工程师重新思考传输层。

🌐 2. 什么是 QUIC？

QUIC = 快速 UDP 互联网连接（Quick UDP Internet Connections）

一句话理解：

QUIC 是 Google 在 UDP 上重新造的一套传输层协议，用来替代 TCP + TLS。

它实现了：

• 低延迟（0-RTT / 1-RTT 握手）
• 自带 TLS 1.3 加密
• 针对丢包场景优化
• 内置多路复用且没有 TCP 队头阻塞
• 连接迁移（支持移动网络 IP 改变）

QUIC 协议栈如下：

+-----------------------+
|     HTTP/3            |
+-----------------------+
|   QUIC (Streams)      |
+-----------------------+
| Packet Encryption     |
+-----------------------+
|           UDP         |
+-----------------------+

可见 QUIC 完全用 UDP 实现自己的传输层功能。

⚡ 3. QUIC 的核心特性与原理

3.1 低延迟握手（0-RTT / 1-RTT）

QUIC 将 TLS 1.3 内置到协议内部，因此只需要：

• 首次连接：1 RTT
• 恢复连接：0 RTT

相比之下：

• TCP：3 次握手（1 RTT）
• TLS：1-2 RTT
• 合计：2-3 RTT

QUIC 的连接比传统 HTTPS 快 2 倍以上。

3.2 不受 TCP 端到端队头阻塞

TCP 中丢一个包，会阻塞所有流。
QUIC 中每个流（Stream）独立处理丢包，不交叉影响。

➡ 多路复用性能大幅提升。

3.3 基于 UDP，实现自己的拥塞控制

QUIC 虽基于 UDP，但仍具备：

• 拥塞控制（拥塞窗口 + 速率控制）
• 重传机制
• 流量控制

并且允许：

• 自定义拥塞算法（如 BBR、Cubic）
• 更灵活的报文结构

3.4 支持连接迁移（Connection Migration）

传统 TCP 连接绑定：

• 5 元组：SRC IP/PORT + DST IP/PORT + 协议

换成 4G → WiFi，IP 变了＝连接断开。

QUIC 的创新点：

使用 CID（Connection ID）标识连接，不与 IP 强绑定。

➡ 手机从 WiFi 切到 5G 时不会断网。
➡ 这是移动网络非常核心的优势。

🔥 4. HTTP/3：基于 QUIC 的新一代 HTTP

为什么不是 “HTTP/2 over UDP”？

因为 TCP 的瓶颈（队头阻塞等）无法在应用层解决，所以：

HTTP/3 直接使用 QUIC 来替代 TCP + TLS

HTTP/3 的协议栈：

HTTP/3
 └─ QPACK（头部压缩）
      └─ QUIC Streams
            └─ QUIC Transport
                  └─ UDP

🆚 5. HTTP/2 vs HTTP/3 对比图

🏁 6. 为什么 QUIC 和 HTTP/3 是未来趋势？

✔ 更快

真实数据吞吐比 HTTP/2 提升 20~40%

✔ 更稳定

弱网 / 手游 / 移动端体验明显提升

✔ 更安全

TLS 1.3 内置，默认全加密

✔ 更灵活

企业可以自定义拥塞算法（如 BBR）