HTTP/3展望、我应该迁移到HTTP/2吗

1. HTTP/3展望

HTTP/3 基于 QUIC 协议，完全解决了"队头阻塞"问题，弱网环境下的表现会优于 HTTP/2；
QUIC 是一个新的传输层协议，建立在 UDP 之上，实现了可靠传输；
QUIC 内含了 TLS1.3，只能加密通信，支持 0-RTT 快速建连；
QUIC 的连接使用"不透明"的连接 ID，不绑定在"IP 地址 + 端口"上，支持"连接迁移"；
QUIC 的流与 HTTP/2 的流很相似，但分为双向流和单向流；
HTTP/3 没有指定默认端口号，需要用 HTTP/2 的扩展帧"Alt-Svc"来发现。

1.1. HTTP/2 的"队头阻塞"

HTTP/2 虽然使用"帧""流""多路复用"，没有了"队头阻塞"，但这些手段都是在应用层里，而在下层，也就是 TCP 协议里，还是会发生"队头阻塞"。

在 HTTP/2 把多个"请求 - 响应"分解成流，交给 TCP 后，TCP 会再拆成更小的包依次发送（其实在 TCP 里应该叫 segment，也就是"段"）。

在网络良好的情况下，包可以很快送达目的地。但如果网络质量比较差，像手机上网的时候，就有可能会丢包。而 TCP 为了保证可靠传输，有个特别的"丢包重传"机制，丢失的包必须要等待重新传输确认，其他的包即使已经收到了，也只能放在缓冲区里，上层的应用拿不出来，只能"干着急"。

举例：

客户端用 TCP 发送了三个包，但服务器所在的操作系统只收到了后两个包，第一个包丢了。那么内核里的 TCP 协议栈就只能把已经收到的包暂存起来，"停下"等着客户端重传那个丢失的包，这样就又出现了"队头阻塞"。

"HTTP over QUIC"就是 HTTP 协议的下一个大版本，HTTP/3。它在 HTTP/2 的基础上又实现了质的飞跃，真正"完美"地解决了"队头阻塞"问题。

1.2. QUIC 协议

QUIC 最早是由 Google 发明的，被称为 gQUIC。而当前正在由 IETF 标准化的 QUIC 被称为 iQUIC。两者的差异非常大。

gQUIC 混合了 UDP、TLS、HTTP，是一个应用层 的协议。而 IETF 则对 gQUIC 做了"清理"，把应用部分分离出来，形成了 HTTP/3，原来的 UDP 部分"下放"到了传输层，所以 iQUIC 有时候也叫"QUIC-transport"。

以下说的 QUIC 都是指 iQUIC，它与早期的 gQUIC 不同，是一个传输层的协议，和 TCP 是平级的。

QUIC 的特点

基于UDP的高效传输

QUIC使用UDP作为底层协议，避免了TCP协议因中间设备（如防火墙、路由器）的僵化导致的部署难题，同时绕开了TCP的队头阻塞问题

多路复用与消除队头阻塞（HOL Blocking）

独立逻辑流：QUIC支持在单个连接上并行传输多个独立的逻辑数据流（Stream），每个流的数据包可乱序传输且互不影响。即使某个流的数据包丢失，其他流仍可正常处理，彻底解决了TCP层和应用层的队头阻塞问题。

与HTTP/2的对比：HTTP/2虽支持多路复用，但仍依赖TCP，一旦发生丢包，所有流需等待重传；而QUIC通过UDP和流隔离机制，仅影响丢失的流。

快速握手与低延迟
内置安全性与加密
连接迁移与网络适应性

QUIC连接通过64位Connection ID标识，而非TCP的四元组（源IP、端口等）。即使设备切换网络（如WiFi转4G），连接仍可保持不断，适合移动场景。

可靠性与流控机制

QUIC 内部细节

QUIC 的基本数据传输单位是包（packet）和帧（frame），一个包由多个帧组成，包面向的是"连接"，帧面向的是"流"。

QUIC 使用不透明的"连接 ID "来标记通信的两个端点，客户端和服务器可以自行选择一组 ID 来标记自己，这样就解除了 TCP 里连接对"IP 地址 + 端口"（即常说的四元组）的强绑定，支持"连接迁移"（Connection Migration）。

QUIC 的帧里有多种类型，PING、ACK 等帧用于管理连接，而 STREAM 帧专门用来实现流。

QUIC 里的流与 HTTP/2 的流非常相似，也是帧的序列，你可以对比着来理解。但 HTTP/2 里的流都是双向的，而 QUIC 则分为双向流和单向流。

流 ID 还保留了最低两位用作标志，第 1 位标记流的发起者，0 表示客户端，1 表示服务器；第 2 位标记流的方向，0 表示双向流，1 表示单向流。

所以 QUIC 流 ID 的奇偶性质和 HTTP/2 刚好相反，客户端的 ID 是偶数，从 0 开始计数。

1.3. HTTP/3 协议

HTTP/3 把流控制都交给 QUIC 去做。调用的不再是 TLS 的安全接口，也不是 Socket API，而是专门的 QUIC 函数。

HTTP/3 里仍然使用流来发送"请求 - 响应"，但它自身不需要像 HTTP/2 那样再去定义流，而是直接使用 QUIC 的流，相当于做了一个"概念映射"。

由于流管理被"下放"到了 QUIC，所以 HTTP/3 里帧的结构也变简单了。帧头只有两个字段：类型和长度，而且同样都采用变长编码，最小只需要两个字节。

HTTP/3 里的帧仍然分成数据帧和控制帧两类，HEADERS 帧和 DATA 帧传输数据，但其他一些帧因为在下层的 QUIC 里有了替代，所以在 HTTP/3 里就都消失了，比如 RST_STREAM、WINDOW_UPDATE、PING 等。

头部压缩算法在 HTTP/3 里升级成了"QPACK"，使用方式上也做了改变。虽然也分成静态表和动态表，但在流上发送 HEADERS 帧时不能更新字段，只能引用，索引表的更新需要在专门的单向流上发送指令来管理，解决了 HPACK 的"队头阻塞"问题。

HTTP/3的服务发现：

HTTP/3 没有指定默认的端口号，也就是说不一定非要在 UDP 的 80 或者 443 上提供 HTTP/3 服务。

浏览器需要先用 HTTP/2 协议连接服务器，然后服务器可以在启动 HTTP/2 连接后发送一个"Alt-Svc"帧，包含一个"h3=host:port"的字符串，告诉浏览器在另一个端点上提供等价的 HTTP/3 服务。
浏览器收到"Alt-Svc"帧，会使用 QUIC 异步连接指定的端口，如果连接成功，就会断开 HTTP/2 连接，改用新的 HTTP/3 收发数据。

2. 应该迁移到HTTP/2吗？

HTTP/2 完全兼容 HTTP/1，是"更安全的 HTTP、更快的 HTTPS"，头部压缩、多路复用等技术可以充分利用带宽，降低延迟，从而大幅度提高上网体验；
TCP 协议存在"队头阻塞"，所以 HTTP/2 在弱网或者移动网络下的性能表现会不如 HTTP/1；
迁移到 HTTP/2 肯定会有性能提升，但高流量网站效果会更显著；
如果已经升级到了 HTTPS，那么再升级到 HTTP/2 会很简单；
TLS 协议提供"ALPN"扩展，让客户端和服务器协商使用的应用层协议，"发现"HTTP/2 服务。

2.1. HTTP/2的主要优点

1. 多路复用（Multiplexing）

核心改进：在单个TCP连接上并行传输多个请求/响应，彻底解决HTTP/1.x的"队头阻塞"问题（应用层）。
效果：减少延迟、提升连接利用率，避免浏览器为并发请求建立多个TCP连接（如HTTP/1.1的6~8个连接限制）。

2. 头部压缩（HPACK）

技术：使用HPACK算法压缩HTTP头部，消除冗余字段（如重复的Cookie、User-Agent）。
效果：减少数据传输量，提升弱网环境下的性能（尤其对移动端和小型请求显著）。

3. 服务器推送（Server Push）

功能：服务器可主动向客户端推送资源（如CSS/JS文件），无需等待客户端解析HTML后发起请求。
场景：优化首次页面加载速度，减少往返次数（RTT）。

4. 二进制协议

格式：将HTTP/1.x的文本格式改为二进制分帧（Frame），解析更高效，避免文本歧义（如空格、大小写）。
效果：降低解析复杂度，提升传输可靠性。

5. 流优先级与依赖控制

机制：允许客户端为请求设置优先级（如优先加载HTML/CSS，延迟加载图片）。
效果：优化关键资源的加载顺序，提升用户体验。

2.2. HTTP/2的主要缺点

1. TCP层队头阻塞未解决

问题：HTTP/2依赖TCP协议，若传输层发生丢包，所有流需等待丢失包重传，导致性能下降。
影响：在高丢包率网络（如移动网络）中，HTTP/2可能比HTTP/1.1更慢（后者可多连接规避）。

2. 服务器推送的局限性

实现复杂：需服务器准确预测客户端所需资源，推送错误内容会浪费带宽。
缓存问题：客户端可能已缓存推送资源，导致冗余传输。
实际采用率低：多数网站未广泛使用此功能，部分浏览器已弃用（如Chrome 106+）。

3. 强制依赖HTTPS

现状：主流浏览器（如Chrome、Firefox）仅支持加密的HTTP/2（基于TLS）。
代价：需维护证书和TLS配置，对简单内网服务可能增加复杂度。

4. 协议复杂性提升

实现难度：二进制分帧、流控制、优先级等机制增加了协议栈复杂度，可能引入新类型Bug（如流状态管理错误）。
调试困难：二进制协议需要专用工具（如Wireshark）分析流量，调试门槛高于HTTP/1.x的文本协议。

5. 中间设备兼容性问题

代理与防火墙：部分老旧中间设备（如传统代理服务器）不完全支持HTTP/2，可能导致连接降级或失败。

2.3. 适用场景与替代方案

|----------------|----------|-----------------------|
| 场景 | 推荐协议 | 原因 |
| 高延迟、低丢包网络 | HTTP/2 | 多路复用显著减少RTT，头部压缩节省带宽。 |
| 高丢包率网络（如4G/5G） | HTTP/3 | QUIC解决TCP队头阻塞，适应弱网环境。 |
| 简单低频请求 | HTTP/1.1 | 协议简单，兼容性更好，无额外性能负担。 |