HTTP/3 的研发至少可追溯至 2016 年，而其底层传输协议 QUIC 更是由 Google 在 2013 年率先提出。如今这两项技术均已确立国际标准：获得 95% 浏览器的支持，**Cloudflare 处理的 HTTP 请求中已有 32% 采用该协议**，并且在 HTTP Archive 数据集中，有 35% 的网站 宣称支持HTTP/3 (通过 alt-svc 或 DNS）。
我们不仅成功开发出全新一代 HTTP 协议，更已将超三分之一的网络流量迁移至该协议——这堪称里程碑式的进展。
然而矛盾的是，包括 Node.js、Go、Rust、Python 和 Ruby 在内的主流编程语言，其标准库均未内置对 QUIC 或 HTTP/3 的支持。Curl 虽然近期新增了相关功能，但仍标记为实验性质且在大多数发行版中默认禁用。某些语言虽有第三方实现库，但均处于实验阶段，且无法与核心网络 API 协同工作。更值得注意的是，尽管移动网络是 HTTP/3 的关键应用场景，Android 主流 HTTP 库 OkHttp 仍明确不支持该协议。Nginx 仅提供实验性模块且默认关闭，Apache 既无支持计划也未公布路线图，而 Kubernetes 最流行的反向代理 Ingress-Nginx 更是完全放弃了支持计划，将相关功能移交至尚未发布的新一代项目。
事实上，目前几乎找不到能完整支持 HTTP/3 的流行开源工具——这项技术的推广部署仍处于萌芽阶段。
这种矛盾现象背后究竟隐藏着什么？
本文假设读者已了解 HTTP/1.1、HTTP/2 与 HTTP/3 的核心差异。如需入门资料，curl 创始人 Daniel Stenberg 撰写的 http2-explained 与 http3-explained 是绝佳参考。
让我们回溯根本：为什么这很重要？如果浏览器和大型 CDN 已支持 HTTP/3，其他客户端或服务端实现是否还有必要跟进？
有观点认为，在负载均衡器之后使用 HTTP/2 意义有限。其核心论点是：HTTP/2 的多路复用主要解决延迟与队头阻塞 (Head-of-line blocking) 问题，但在延迟极低的内部网络中，通过长连接即可规避这些问题。
这个论点同样适用于 HTTP/3：它对高延迟、多请求的 浏览器-CDN 场景有益，但对其他场景价值有限。但即使只考虑 HTTP/1.1 与 HTTP/2，多路复用优势的现实情况也更加复杂：
- 响应延迟不仅来自网络传输：服务端处理缓慢同样会阻塞 TCP 连接
- 负载均衡器常与后端服务异地部署（例如通过全球 CDN 提供服务时，动态请求仍需回源至独立后端）
- 长连接 TCP 连接并不可靠：即使在数据中心内，网络故障也时有发生，“保持连接”只是理想状态。HTTP 协议本身也会强制中断连接（如响应体传输中途失败时）
- 流量波动会导致 TCP 连接数失衡：要么长期维持冗余连接池，要么在峰值时建立新连接，面临慢启动、往返延迟与 TLS 握手开销
- 非网站类流量（移动应用、API 服务、物联网设备）同样面临网络延迟与服务端阻塞问题，这些场景都能从 HTTP/2/3 中获益
除多路复用外，HTTP/2 还有更多跨场景优势：
- 头部压缩（HTTP/2 的 HPACK 与 HTTP/3 的 QPACK）显著减少传输数据量，对内部长连接效果尤为明显
- 双向流通信（仅 HTTP/2/3 支持）开启全新交互模式，gRPC 即基于此特性构建，类似 WebSocket 但完全兼容 HTTP 语义
- 请求优先级控制允许服务端优化资源分配，这对负载均衡器与后端通信同样重要
HTTP/3 更在以下方面实现突破：
- 通过取消 TCP 严格包序，使单个流独立传输，避免流间阻塞
- 结合 TLS 1.3 与 QUIC 实现 0RTT 握手，首次请求无需等待 TLS 握手完成
- 降低传输开销与连接数，减少客户端能耗与服务端资源消耗
- 支持连接迁移，IP 变更时保持会话连续性，未来甚至支持多路径传输
- 采用 BBR 拥塞控制等先进算法，提升网络适应能力
- 为 WebTransport 提供基础，实现低延迟双向通信的同时解决 WebSocket 的队头阻塞等问题
实际测试数据同样佐证其价值。RequestMetric 的基准测试显示：
Fastly 也在实际环境中观测到首字节时间的大幅优化：
显然，这是一项具有实质价值的技术。
既然 HTTP/3 已完成标准化、获得广泛支持并经过实践检验，没理由不让所有开发者都能通过常用开发工具链享受这些技术红利。
割裂的网络
现实却截然相反：尽管技术优势明显且网络流量占比显著，大多数开发者仍难以端到端部署 HTTP/3。这种现象折射出互联网长期存在的分层现状。如今的网络流量已分化为两种形态：
- 超大规模流量：主流浏览器与特定移动应用通过精心调优的客户端，与少数科技巨头的自有基础设施或大型 CDN 通信
- 长尾流量：后端服务、中小型应用、物联网设备、学术研究等多样化场景，依赖开源生态与共享技术栈
这两大阵营的核心差异包括：
- 长尾流量规模更大： 67% 的网页请求直连源站，Cloudflare 2024 年数据表明其 30% 流量来自自动化程序，60% 属于 API 调用
- 长尾生态天然碎片化，主要依赖志愿维护的开源项目
- 超大规模阵营由少数利益相关方主导，能快速协调标准制定与落地
- 商业动机高度集中：性能毫秒级提升直接关联企业收益
- 长尾完全依赖开源实现，而超大规模玩家拥有自研定制的实力与资源
- 版本迭代速度差异巨大：长尾工具注重稳定性，超大规模阵营追求快速迭代
这种分化并非善恶对立——从工程角度，HTTP/3 正是跨组织协作的卓越成果。但问题在于：当下一代网络技术由少数群体定义并优先服务自身需求时，大多数开发者只能通过购买 CDN 服务间接获取技术红利，这无疑限制了创新生态的健康发展。
OpenSSL 与 QUIC 的兼容困局
这种分化最具体的体现就是 OpenSSL 对 QUIC 的支持策略。作为最基础的 TLS 库，OpenSSL 的态度直接影响整个开源生态。事件脉络如下：
- BoringSSL 2018 年即提供 QUIC API
- OpenSSL 长期缺失该功能，催生 QuicTLS 等兼容分支
- 现有 HTTP/3 实现生态（Quiche、msh3、nghttp3 等）均基于 BoringSSL 或分支构建
- OpenSSL 3.2 起采用不兼容的实现方案，导致生态分裂
curl 的项目现状图清晰展现了这种割裂：
对大多数项目而言，放弃 OpenSSL 转向其他方案成本过高，这导致它们至今无法原生支持 QUIC。Node.js 曾讨论切换方案，但考虑到系统兼容性、长期支持等现实因素，最终难以实施。
这正是双层网络差异的典型体现：开源工具必须保持向后兼容，而超大规模玩家可以为了技术先进性承担更大变更成本。
未来走向
组织架构差异正在导致互联网技术栈的分裂。虽然长尾场景未必急需 HTTP/3，但若放任不管，可能导致：
- 性能差距扩大：超大规模网站在移动网络环境下体验优势加剧
- 工具链分化：前端框架等基础设施逐渐以 HTTP/3 为默认假设
- 技术壁垒形成：缺乏 HTTP/3 支持可能成为被限流或验证的依据
- 生态恶性循环：长尾需求逐渐被技术演进忽略
所有这些都还有一段距离，而且是相当假设性的！我怀疑其中一些假设会在某种程度上发生，但可能性范围很广。不过值得注意的是，这不仅仅适用于 HTTP/3：少数 CDN 和网络客户端的这种集中和协调很容易在许多其他类型的技术改进中也以类似的方式发生。
至少对于 HTTP/3 而言，我希望这里能有一个愉快的解决方案来及时改善这种分裂，尽管我不知道它是否会足够快以避免明显的后果。许多 QUIC 和 HTTP/3 的外部库和实验性实现会随着时间的推移而成熟，而且我认为最终 (我真的非常希望) OpenSSL QUIC API 的分裂将得到解决，从而为 许多基于 OpenSSL 的环境中的 QUIC 支持打开大门，要么通过适配器支持这两种方法，要么通过直接支持 OpenSSL 模型的新 HTTP/3 和 QUIC 堆栈。
然而，所有这一切都不会在今天发生，因此不幸的是，如果您想在您的应用程序中端到端地使用 HTTP/3，您可能还需要经历一段时间的艰难时期。敬请关注。