🚀 前端优化深度科普
HTTP/2 与 HTTP/3 的差异

HTTP/2 和 HTTP/3 最大的不同是什么？

底层传输协议完全不同。 HTTP/2 基于 TCP（传输控制协议），而 HTTP/3 基于 QUIC（Quick UDP Internet Connections，基于 UDP）。TCP 的“队头阻塞”（Head-of-Line Blocking）是 HTTP/2 的固有痛点——如果一个 TCP 包丢失，后续所有流都得等重传。QUIC 则把丢包影响限制在单个流内部，其他流完全不受干扰。简单说：HTTP/3 在弱网或高丢包环境下，页面加载速度更稳定、更可预测。

HTTP/2 的多路复用已经解决了队头阻塞，为什么还要升级到 HTTP/3？

HTTP/2 的多路复用只解决了应用层的队头阻塞，但 TCP 层的队头阻塞依然存在。 例如：一个 TCP 连接上同时传输 5 个资源，如果第 3 个资源的某个数据包丢了，TCP 必须等待这个包重传成功，后面的 4、5 号资源即使数据包已到达，也无法交给应用层。HTTP/3 基于 QUIC，每个流独立传输、独立纠错，一个流丢包完全不影响其他流。这也是为什么视频、实时交互类前端应用在 HTTP/3 下体验更流畅。

我开启了 HTTP/2，但加载速度没提升，是不是该换 HTTP/3？

先排查这两个常见误区： ① 使用 HTTP/2 必须启用 TLS（HTTPS），很多配置了证书但服务器未正确协商 h2 协议；② 前端资源未做合理拆分——HTTP/2 的多路复用适合大量小文件，如果仍然把所有 JS/CSS 打包成一个巨大 bundle，多路复用优势被削弱。在确认 HTTP/2 正确生效且资源已按“20-50个小文件”拆分后，若仍感觉首屏慢（尤其移动端弱网），再考虑升级 HTTP/3。QUIC 在 3G/4G 网络下的 0-RTT 握手优势更明显。

HTTP/3 的“0-RTT”是什么？前端能直接利用吗？

0-RTT 是指客户端在第二次及后续连接时，无需等待握手就能直接发送请求数据。 传统 TCP+TLS 1.3 需要 1-RTT 往返，而 QUIC 通过缓存连接凭据，实现“零往返时间”恢复会话。对前端最直接的影响：重复访问的页面、预加载的链接、Service Worker 的预缓存请求，可以节省几十到几百毫秒的延迟。但注意：0-RTT 存在一定的重放攻击风险（幂等请求安全），GET 请求（如静态资源、API 查询）可放心使用。

前端开发者需要改代码才能支持 HTTP/3 吗？

绝大多数情况不需要修改前端代码。 HTTP/3 是传输层升级，对 JavaScript、CSS、HTML 完全透明。你只需在服务器端（如 Nginx、Caddy、Cloudflare）启用 HTTP/3 和 QUIC，浏览器会自动通过 Alt-Svc 头部协商升级到 h3。唯一需要关注的：如果使用了自定义 TCP 优化（如特定拥塞控制算法），迁移到 QUIC 后需重新测试。另外，WebSocket 在 HTTP/3 中由 WebTransport 替代，但当前兼容性有限，暂不建议迁移。

HTTP/3 的 UDP 会不会导致连接不可靠？对前端有什么风险？

QUIC 在 UDP 之上实现了可靠的传输逻辑，可靠性并不比 TCP 差。 它内置了丢包检测、重传、前向纠错（FEC）等机制。对前端而言，主要风险是部分企业防火墙或老旧路由器会拦截 UDP 443 端口，导致 HTTP/3 回退到 HTTP/2 或 HTTP/1.1。但这是渐进增强场景——浏览器自动降级，用户无感知。另外，UDP 在运营商网络中可能被限速，但目前 CDN 广泛支持 QUIC，实际影响已很小。

作为前端，我应该优先优化 HTTP/3 还是继续压榨 HTTP/2？

建议分场景： ① 如果你的用户群体集中在移动端、网络环境复杂（如东南亚、拉美），优先启用 HTTP/3，因为它对高延迟、丢包场景优化显著；② 如果主要服务欧美或企业内网（网络稳定），HTTP/2 配合 Brotli 压缩、资源预加载、优先级调整，性价比更高。目前主流浏览器对 HTTP/3 支持率已超过 95%，但服务器端普及度仍有差距。最佳实践：同时开启 HTTP/2 和 HTTP/3，让浏览器自动选择最优协议。