前言
HTTP/2 开启了多路复用的时代，但它依然跑在 TCP 这条“老旧”的铁轨上。只要 TCP 的设计初衷（顺序传输、字节流可靠性）不改变，队头阻塞（HOL Blocking） 的幽灵就永远无法彻底散去。于是，Google 另辟蹊径，基于 UDP 打造了 QUIC，并最终成为了 HTTP/3 的核心。
一、 HTTP/2 的遗憾：TCP 层的队头阻塞
虽然 HTTP/2 过多路复用解决了 HTTP 在应用层 的队头阻塞，使应用层发生的请求不再需要排队等候，解决了 HTTP/1.1 的队头阻塞。，但由于它底层依然依赖 TCP，产生了一个新的瓶颈
-
传输层队头阻塞问题 ：HTTP/2 建立在 TCP 之上。TCP 要求字节必须按顺序交付。如果网络发生丢包，TCP 无法分辨哪些字节属于哪个请求，只能暂停整个连接等待重传。
-
弱网环境下的尴尬：在丢包率较高的移动网络下，HTTP/2 的表现有时甚至不如开启 6 个连接的 HTTP/1.1，因为“一荣俱荣，一损俱损”。
- 连接建立的开销：TCP 三次握手 + TLS 握手，在弱网环境下 RTT（往返时延）非常高。
二、 HTTP/3 的逆袭：基于 UDP 的 QUIC 协议
由于 TCP 协议深植于操作系统内核和路由器固件中，修改极其困难。HTTP/3 索性“推倒重来”，在 UDP 之上实现了可靠传输，这便是 QUIC（Quick UDP Internet Connections） 。
1. QUIC 的四大核心魔法
① 彻底解决队头阻塞
QUIC 在传输层实现了多路复用。每个流（Stream）之间是相互独立的。
- 效果：如果 Stream A 丢包，只会阻塞 Stream A 的重组，Stream B 和 Stream C 可以继续不受影响地传输数据。
② 极速握手（0-RTT / 1-RTT）
TCP 需要先建立连接再建立加密通道。
- 效果：QUIC 将传输握手与加密握手合并。初次连接只需 1 个 RTT，再次连接甚至可以实现 0-RTT 极速启动。
③ 连接迁移 (Connection Migration)
TCP 依靠“四元组”（源IP、源端口、目标IP、目标端口）识别连接。
- 痛点：当你从 Wi-Fi 切换到 4G，IP 变了，TCP 连接必断。
- 改进：QUIC 使用 Connection ID 识别连接。即便 IP 切换，只要 ID 不变，连接就能无缝延续。
④ 改进的头部压缩：QPACK
HTTP/2 使用的 HPACK 在乱序传输时会产生队头阻塞，HTTP/3 升级为 QPACK，专门优化了多流并发下的压缩效率。
三、 总结：从“排队”到“并发”
| 特性 | HTTP/2 (TCP) | HTTP/3 (UDP/QUIC) |
|---|---|---|
| 传输层阻塞 | 存在 TCP 队头阻塞 | 不存在（流与流独立） |
| 握手时延 | 2~3 RTT (TCP+TLS) | 0~1 RTT |
| 网络切换 | 连接断开，需重新握手 | 无缝迁移 |
| 可靠性 | 操作系统内核实现 | QUIC 在应用层实现 |
四、 HTTP3.0现状
目前HTTP3.0并没有普及，你可以随便打开网站查看请求相应的HTTP版本，会发现大多数请求都是HTTP2.0的！
