3 min. 阅读

HTTP/3：最新网络协议综合指南

浏览器与网络服务器的对话方式正在发生变化。 二十多年来，超文本传输协议一直依靠传输控制协议来传送网页，在大部分时间里，它的工作足够出色。但 “足够好 “已经不再适用。

HTTP/3 代表着网络历史上最重大的传输变革。它完全放弃了 TCP 协议，转而使用一种名为 QUIC 的新传输协议，该协议在用户数据报协议上运行。这种转变不仅仅是技术上的好奇–它是对我们今天使用互联网方式的直接回应：在移动设备上，通过不稳定的连接，以及对近乎即时响应的期望。

在本指南中，您将了解HTTP/3 的确切含义、与以前版本的区别、QUIC 的重要性以及如何在生产环境中部署 HTTP/3。无论您是试图了解该协议的开发人员，还是计划迁移的工程师，本细则都涵盖了您所需的概念和实际步骤。

HTTP/3 概述

HTTP/3 是超文本传输协议 HTTP 的第三次重大修订，于 2022 年 6 月作为 RFC 9114 定稿。与之前的版本不同，HTTP/3 并不在 TCP 上运行。相反，它将 HTTP 语义映射到 QUIC 上，QUIC 是一个以 UDP 为基础的传输层协议。这种架构上的变化解决了多年来困扰网络性能的基本限制。其核心理念简单明了：保留开发人员所熟悉和喜爱的 HTTP 的一切–GET 和 POST 等方法、状态代码、标头、请求-响应模式–但将底层传输替换为更适合现代互联网条件的传输。HTTP/3 仍然使用 HTTP。它只是通过一种根本不同的传输协议来传递这些信息。

HTTP/3 与 HTTP/2 的不同之处在于几个关键的变化。首先，QUIC 取代了 TCP，消除了困扰 HTTP/2 的传输层线路阻塞问题。 其次，传输层安全（TLS 1.3）直接集成到传输握手中，将加密和传输握手合并为一次往返。第三，连接迁移允许会话在网络变化后继续运行–手机从 Wi-Fi 切换到蜂窝网络不会中断连接。第四，通过重复连接的 0-RTT 恢复，减少延迟成为可能。

在现实世界中得到了大量采用。 谷歌在 2012 年左右率先推出 QUIC 协议，多年来一直为 HTTP/3 流量提供服务。Meta在Facebook和Instagram中使用了该协议。Cloudflare 在其整个全球网络中启用了 HTTP/3，Akamai 也紧随其后。 到 2024-2025 年，仅这些提供商就将通过 HTTP/3 处理全球网络流量的很大一部分。

协议不再是实验性的了。 主要网络浏览器–Chrome、Firefox、Safari、Edge–默认情况下都支持 HTTP/3。 如果您正在使用现代浏览器阅读这篇文章，很有可能您今天的一些请求已经在不知不觉中使用了 HTTP/3。

这实际上意味着：在有损网络上的页面加载速度更快，在移动网络上的连接更有弹性，以及并行处理多个请求的应用程序的性能更佳。这些优势并不是在所有网络条件下都能体现，但对于最重要的应用场景–真实网络上的真实用户–TTP/3 带来了显著的改进。

从 HTTP/1.1 和 HTTP/2 到 HTTP/3

要了解 HTTP/3 存在的原因，就必须了解它的前身。从HTTP/1.1 到 HTTP/2 再到 HTTP/3，其演变过程有一个清晰的模式：每个版本都在保留 HTTP 语义的同时，解决了前一版本的局限性。

HTTP/1.1 于 1997 年发布（RFC 2068，后经 RFC 2616 完善，最终被 RFC 7230-7235 所取代）。它引入了持久连接和流水线功能，允许通过单个tcp 连接发出多个请求。但在实践中，流水作业从未取得良好效果。队列前端的缓慢响应会阻塞后面的所有请求，这就是应用层的线头阻塞。浏览器通过为每个源打开6-8 个并行 TCP 连接来弥补这一缺陷，这种方法虽然有效，但浪费了资源，并使拥塞控制变得复杂。

HTTP/2（RFC 7540，2015 年）通过二进制成帧和流复用固定了应用层阻塞。多个数据流可以共享一个连接，请求和响应作为帧交错进行。通过 HPACK 压缩报头，减少了冗余元数据。服务器推送可让服务器主动发送资源。在实践中，尽管规范并未要求使用TLS，但 TLS 已成为强制性规范。

但HTTP/2 继承了 TCP 的基本限制：所有数据流共享一个有序的字节流。当一个数据流的数据包丢失时，TCP 会保留所有数据包，直到丢失的数据包被重新传输。这就是传输级的行首阻塞– HTTP/2 无法摆脱它，因为 TCP 在连接级强制执行无序交付。

不同版本的主要区别

  • HTTP/1.1：基于文本，每个连接一次只能发出一个请求（实际上），每个源点有多个 TCP 连接
  • HTTP/2：二进制成帧、单 TCP 连接上的多路复用连接、HPACK 报头压缩、服务器推送
  • HTTP/3：QUIC/UDP 上的 HTTP 语义、独立流（无传输 HOL 阻塞）、QPACK 压缩、集成 TLS 1.3

HTTP/3 的动机很明确：保持 HTTP 语义不变，但完全替换传输层。TCP 虽然非常可靠，但如果不从根本上改变，就无法消除HOL 阻塞，从而破坏与几十年来部署的基础设施的兼容性。QUIC 就是答案–一种针对现代需求从零开始设计的新传输协议。

什么是 QUIC 及其对 HTTP/3 的重要性

QUIC 是快速 UDP 互联网连接的缩写，不过互联网工程任务组在对其进行标准化时放弃了这一缩写。QUIC 最初由谷歌在 2012 年左右设计，于 2021 年 5 月作为 RFC 9000 标准化，HTTP/3 随后于 2022 年作为 RFC 9114 标准化。

QUIC 的核心是基于 UDP 的传输协议。但与原始 UDP 不同的是，QUIC 实现了可靠传输所需的一切功能：连接建立、可靠性、排序（每个数据流）、拥塞控制和加密。与 TCP 的主要区别在于，QUIC 是在用户空间而不是内核中实现所有这些功能的，它提供多个独立的数据流而不是单一的字节流。

QUIC 传输协议对 HTTP/3 非常重要，因为它具有几个关键特性。传输层的数据流复用意味着每个 HTTP 请求都有自己的数据流，一个数据流的数据包丢失不会阻塞其他数据流。集成 TLS 1.3 意味着加密不是一个单独的层，而是嵌入到初始握手中。连接 ID 允许连接在 IP 地址变更后继续使用。0-RTT 恢复功能可让重复访问者立即发送数据，而无需等待握手完成。

QUIC 的设计选择反映了从 TCP 的局限性和中间件僵化导致 TCP 难以发展中吸取的经验教训。通过加密大部分数据包头并在用户空间运行，QUIC 可以更快地发展，而无需等待内核更新或担心中间设备对协议行为做出假设。

以下是一个高层次的比较：

  • TCP：内核级实现，单一有序字节流，3 路握手和单独的 TLS 握手，连接与 IP:端口元组绑定
  • QUIC：用户空间实施，多个独立流，传输和加密握手（1-RTT 或 0-RTT）相结合，连接由独立于 IP 的 CID 识别

UDP 协议提供了最小的开销–只有 64 位的报头，包括源端口、目的端口、长度和校验和。QUIC 在此基础上提高了可靠性，但也获得了 TCP 内核级实现所无法比拟的灵活性。

传输层的 TCP 与 QUIC

TCP 连接的建立遵循我们熟悉的三方握手：SYN、SYN-AK、AKK。 这只是建立连接的一次往返。对于 HTTPS，您还需要进行TLS 握手–使用TLS 1.3 至少还需要一次往返，使用旧版本则需要更多。在任何应用数据流动之前，光是设置就已经花费了 2-3 个 RTT。

TCP 还强制执行单一有序字节流。每个字节都必须按顺序到达，如果一个数据包丢失，所有后续数据包都会在接收缓冲区等待，直到丢失的数据包被重新传输和接收。对于 HTTP/2，这意味着一个数据流的数据包丢失会阻塞该连接上的所有数据流，即使它们的数据已成功到达。

QUIC 采用了不同的方法。 每个 QUIC 数据流都是独立排序的。 数据包丢失只影响数据包中包含数据的数据流。其他数据流将继续接收和处理数据，不会出现延迟。 这就完全消除了传输层的线路阻塞。

为了建立安全连接，QUIC 将 TLS 1.3 握手直接集成到传输层中。第一个数据包可以完成连接建立和密钥交换，从而将初始延迟减少到 1 RTT。对于客户端以前访问过的服务器的连接，0-RTT 恢复允许在第一个数据包中根据缓存的会话密钥发送应用数据。

快速比较：

  • TCP + TLS 1.3：TCP 握手 1 RTT + TLS 1 RTT = 数据前最少 2 RTT
  • QUIC：联合握手时为 1 RTT，恢复握手时为 0 RTT
  • 丢包影响 (TCP)：所有数据流停止等待重传
  • 丢包影响 (QUIC)：只有受影响的数据流停滞；其他数据流继续

在高延迟路径（移动网络、卫星连接、跨洲流量）上，实际差异最为明显。节省一到两次往返，就能使初始页面加载时间缩短数百毫秒。

HTTP/3 协议概述

HTTP/3 在 RFC 9114 中被定义为 “HTTP 语义在QUIC 传输协议上的映射”。关键词是 “映射”–HTTP/3并没有改变 HTTP 的功能，只是改变了其在网络上的传输方式。每个客户端发起的双向 QUIC 流都携带一个 HTTP 请求和相应的响应。这种每流一个请求的模式取代了 HTTP/2在单个 TCP 连接中的多路复用。服务器发起的单向流携带控制信息（设置、GOAWAY），并在使用时携带服务器推送数据。

在每个流内，HTTP/3 使用与 HTTP/2 框架概念类似的框架。HEADERS 框架包含请求和响应头（通过 QPACK 压缩）。DATA 框架承载信息主体。SETTINGS 框架建立连接参数。框架是二进制的，而不是文本，但开发人员很少直接与这一层交互。

由于 QUIC 负责处理流复用、流控制和可靠性，HTTP/2 的几个概念被委托给传输层或完全删除。例如，HTTP/2 本身的流级流量控制就没有必要，因为 QUIC 本身就提供了这一功能。

概念结构：

  • QUIC 连接：客户端和服务器之间的加密传输会话
  • QUIC 数据流：连接内独立的双向或单向字节流
  • HTTP/3 帧：流中携带的协议单元（HEADERS、DATA 等
  • HTTP 消息：由特定流上的帧组成的请求或响应

这种分层意味着 HTTP/3 可以受益于 QUIC 的任何改进，而无需改变 HTTP/3 本身。新的拥塞控制算法、更好的损失检测、多路径支持–所有这些都可以在传输层添加。

HTTP 语义和框架

HTTP/3 保留了开发人员从 HTTP/1.1 和 HTTP/2 中了解到的 http 语义。 方法（GET、POST、PUT、DELETE）、状态代码（200、404、500）、标头和信息体完全按照预期运行。 应用层看到的 HTTP 与以往相同。

请求使用伪头文件来传达 HTTP/1.1 在请求行中编码的内容。 :method伪头文件包含 GET 或 POST。:path表示 URL 路径。scheme指定 http 或 https。authority替换 Host 头信息。这些伪头文件必须出现在 HEADERS 框架中常规请求头字段之前。

在给定的 quic 流中，一个请求由一个 HEADERS 框架（包含请求头）组成，其后可选择添加 DATA 框架（请求主体），并在流关闭发送时结束。 响应也遵循相同的模式：HEADERS 框架包含状态和响应标头，DATA 框架包含主体。

关键框架规则：

  • 每个双向数据流有一个请求和一个响应
  • 每个数据流的标题帧必须在前
  • 常规标题前的伪标题
  • 帧在数据流中有序排列，但数据流是独立的
  • 设置适用于连接，而非单个数据流
  • GOAWAY 发出优雅关闭连接的信号

常见的框架类型包括 HEADERS（压缩头块）、DATA（主体内容）、SETTINGS（连接参数）、GOAWAY（关闭信号）和 PUSH_PROMISE（服务器推送，如果启用）。与 QUIC 内置功能重叠的框架类型已从 HTTP/2 的设计中删除或简化。

头压缩：HPACK 与 QPACK

头压缩可减少 HTTP 流量中多余的元数据。每个请求都会携带Host、User-Agent、Accept-Encoding 和cookies 等标头。其中许多会在不同请求中逐字重复。 如果不进行压缩，这种重复会浪费带宽，特别是在进行多次 API 调用的聊天连接上。

HTTP/2 引入了 HPACK，它使用以前看过的报头动态表和哈夫曼编码来缩小报头块。HPACK 在 HTTP/2 中运行良好，但由于压缩状态是在单个 tcp 连接中共享的，因此它假定按顺序交付。

HTTP/3 不能直接使用 HPACK。 QUIC 流是独立的，因此报头块可能会按顺序到达。如果一个流引用了另一个数据尚未到达的流中定义的表项，解码就会失败或阻塞–在压缩层引入行头阻塞。

QPACK 通过将标头表更新与标头块引用分离来解决这个问题：

  • HPACK：共享动态表，无序更新，专为 TCP 的有序字节流设计
  • QPACK：编码器和解码器流异步处理表更新
  • HPACK 风险：无序交付打破解码假设
  • QPACK 解决方案：标题块只能引用已确认收到的条目
  • 结果QPACK 保持了压缩效率，而不会出现 HOL 阻塞现象

在实际应用场景中，例如移动应用程序使用类似的报头调用数十个小型应用程序接口时，QPACK 既能节省带宽，又能改善延迟。将表更新从流数据交付的关键路径中分离出来，意味着不会有任何一个缓慢的流阻碍其他流的报头解压缩。

多路复用、服务器推送和优先级排序

HTTP/3 的多路复用功能直接源于QUIC 基于流的设计。多个请求在一个QUIC 连接上流动，每个请求都有自己的双向流。HTTP/2 的所有流共享一个 TCP 连接的排序限制，而HTTP/3 的流则不同，是真正独立的。一个数据流上的数据包丢失不会阻碍其他数据流的进行。这使得网络浏览器可以更高效地并行加载页面资源。HTML、CSS、JavaScript 和图片都可以同时请求，而不会因为一个缓慢的资源而阻塞其他资源。 在移动用户常见的有损网络中，这种独立性可实现更快、更可预测的页面加载。

服务器推送存在于 HTTP/3 中，但其热度已经下降。其概念保持不变：服务器可以使用 PUSH_PROMISE 框架，在客户端请求之前主动发送资源。在实践中，服务器推送的正确实施非常复杂，与浏览器缓存的交互性也很差，而且往往收效甚微。现在，许多部署都完全禁用了服务器推送。

优先级也发生了变化。HTTP/2 基于树状结构的复杂优先级模型造成了互操作性问题，而且实施起来往往不一致。HTTP/3 采用了 RFC 9218 中定义的更简单的方法，使用紧急程度和增量提示，而不是依赖树。这使得优先级的确定在不同的实现中更具可预测性。

复用和推送摘要：

  • 多路复用：每个连接有多个独立流，无跨流阻塞
  • 服务器推送：可用，但越来越多的情况下是可选的；许多人禁用了它
  • 优先级：比 HTTP/2 模型更简单；使用紧迫性和递增标记
  • 实际影响：并行资源加载在有损网络中更具弹性

考虑一下浏览器加载一个典型网页的情况：HTML 文档、多个 CSS 文件、JavaScript 包和几十张图片。通过 HTTP/3，允许多个请求意味着所有这些请求可以同时进行。如果携带图像数据的数据包丢失，只有该图像流等待重新传输，而 CSS 和 JavaScript 则继续加载。

TLS 1.3 和安全集成

HTTP/3 要求使用 TLS 1.3 或更高版本。没有未加密的 HTTP/3，也没有与通过 TCP 80 端口的 HTTP 相对应的 HTTP。根据定义，每个 HTTP/3 连接都是加密的，为所有数据传输提供安全连接。

QUIC 在传输层集成了 TLS 1.3，而不是在其上分层。加密握手发生在连接建立的同时，而不是之后。这种整合有以下几个好处：

  • 减少往返次数：连接设置和加密设置同时进行
  • 更强的默认设置：具有前向保密功能的 TLS 1.3 密码套件
  • 加密报头大多数 QUIC 数据包元数据都经过加密，而不仅仅是有效载荷
  • 无降级攻击无法协商较弱的加密或明文
  • 对等验证：在组合握手过程中验证服务器证书

加密范围不仅限于 HTTP 有效载荷。QUIC 对数据包编号以及 TCP 和 TLS 向被动观察者披露的大部分报头信息进行加密。 这样可以提高安全性和隐私性，减少中间节点对流量的查看。

然而 这种加密方式带来了挑战。传统的网络监控工具依赖于 TCP 报头检查或 TLS 记录层可视性，但无法与 QUIC 配合使用。 防火墙和入侵检测系统可能需要更新，以处理 QUIC 流量。 习惯于深度数据包检测的企业网络必须调整其安全策略和工具。

这种权衡是有意为之：QUIC 的设计者将最终用户隐私和防止中间件僵化置于操作员可视性之上。对于有合理监控需求的企业来说，端点级日志记录和更新的安全基础设施是必不可少的。

HTTP/3 的性能特点

HTTP/3 性能的提升在特定网络条件下最为明显。丢包率可变的移动网络、存在干扰的 Wi-Fi、跨越大陆的高延迟路径以及涉及频繁网络变更的场景都能显著受益。QUIC 协议就是专为这些实际条件而设计的。

在稳定、低延迟的数据中心连接上，HTTP/3 的性能可能仅略高于经过良好调整的 HTTP/2 部署。TCP 经过几十年的优化，现代内核可以非常高效地处理它。在延迟已经很低、数据包丢失很少的情况下，避免 HOL 阻塞和节省握手往返次数的好处就不那么重要了。

现实世界的测量结果支持这种细致入微的观点。Cloudflare 报告称，首次字节时间和错误恢复能力有所改善，尤其是对移动用户而言。谷歌的测量结果表明，在高延迟地区，连接故障减少，页面加载速度加快。2020-2024 年的学术研究一致表明，HTTP/3 在丢失情况下的表现优于 HTTP/2，根据丢失率的不同，收益从适度到大幅不等。

值得注意的是一个权衡问题：QUIC 的用户空间实现可能比内核级 TCP 处理消耗更多的 CPU，尤其是在高吞吐量服务器上。操作系统还没有几十年的时间来优化 QUIC 代码路径。处理大量连接数的服务器可能会增加 CPU 占用率，尤其是在功率不足的硬件上。

HTTP/3 的最大优势

  • 移动浏览与蜂窝网络切换
  • 使用拥挤的 Wi-Fi 网络的用户
  • 长途连接（高 RTT）
  • 提出许多并行请求的应用程序
  • 经常访问相同网站的用户（0-RTT 效益）
  • 对延迟抖动敏感的实时应用

连接设置和 0-RTT

HTTP/2 和 HTTP/3 之间的握手差异直接影响用户查看内容的速度。使用 HTTP/2 over TLS 1.3，建立连接至少需要一个 TCP 三方握手的 RTT，然后一个 TLS 握手的 RTT。在100 毫秒 RTT 的路径上，200 毫秒后才会有 HTTP 数据流。

HTTP/3 的组合方法大大减少了这种情况。 QUIC 同时执行传输和 TLS 1.3 握手，只需一次往返即可完成。在同样100 毫秒的路径上，发送 HTTP 数据只需 100 毫秒，而不是 200 毫秒。

对于重复访问者，0-RTT 恢复功能更胜一筹。如果客户端缓存了以前与同一服务器连接时的会话密钥，它就可以在完成握手之前，在第一个数据包中发送应用数据。服务器可以使用缓存的密钥立即做出响应。

握手比较：

  • HTTP/2 + TLS 1.3：TCP SYN → SYN-ACK → ACK（1 RTT），然后 TLS ClientHello → ServerHello → Finished（1 RTT）= 2 RTT
  • HTTP/3（新连接）：QUIC 初始化（带 TLS） ClientHello → 服务器响应（带 TLS 数据） → 连接就绪 = 1 RTT
  • HTTP/3（0-RTT 恢复）：客户端在第一个数据包中发送请求，服务器立即响应 = 0 RTT

零 RTT 存在安全隐患。由于数据是在握手完成之前发送的，因此很容易受到重放攻击。恶意行为者可以捕获 0-RTT 数据包并重新发送。服务器必须实施防重放策略，通常会限制 0-RTT 允许的操作（例如，只允许安全的只读请求）。这就是为什么0-RTT 是一种 “恢复 “功能–它依赖于先前建立的信任。

一个具体的例子：用户访问您的电子商务网站，浏览产品，然后第二天早上返回。 在 0-RTT 条件下，他们的第一次请求–加载主页–可以在零往返等待的情况下完成。 页面立即开始加载。

处理数据包丢失和拥塞

数据包丢失在互联网上是不可避免的，协议如何处理数据包丢失决定了实际性能。QUIC 的按流丢失恢复与 TCP 的方法有本质区别，对网络效率有直接影响。

当 TCP 检测到数据包丢失时，它会暂停所有后续数据的传输，直到丢失的数据包被重新传输和接收。这是必要的，因为 TCP 保证按顺序传输整个字节流。对于 HTTP/2，这意味着一个丢失的数据包会阻塞成功到达的 JavaScript 和图像–所有流数据都要等待。

QUIC 维护每个数据流的可靠性。如果传输流 5 数据的 QUIC 数据包丢失、 只有数据流 5 等待重传。数据流 6、7 和 8 继续接收数据并取得进展 . 这消除了不必要的阻塞所造成的带宽浪费，并提高了用户在丢失情况下的感知性能。

QUIC 中的拥塞控制与 TCP 的方法类似，都是基于窗口、以ACK 为驱动的算法，这些算法会探测可用带宽，并在检测到拥塞时关闭。但由于QUIC 在用户空间运行，因此更容易尝试新的拥塞控制算法。更新不需要内核补丁；它们是库更新。

损失处理特性：

  • 按数据流恢复：丢失的数据包只阻塞其数据流，而不是整个连接
  • ACK 驱动控制：类似于 TCP 经过验证的拥塞控制原则
  • 用户空间演进：无需更改操作系统即可更新拥塞算法
  • 明确的损失报告：扩展功能可实现更精确的损失检测

考虑通过拥挤的移动网络进行视频流传输的情况。使用 HTTP/2，周期性丢包会导致所有流停滞，从而产生明显的卡顿。而使用 HTTP/3，视频数据块的丢失只会影响该数据块的数据流–控制数据、字幕和其他数据流继续流动。因此，在具有挑战性的网络条件下，播放更流畅，数据交付更出色。

使用连接 ID 进行连接迁移

TCP 连接由四个元组标识：源 IP、源端口、目标 IP、目标端口。改变其中任何一个–当手机从 Wi-Fi 切换到蜂窝网络时就会发生这种情况–TCP 连接就会中断。随后会进行新的握手和 TLS 协商，从而增加延迟并中断任何正在进行的传输。

QUIC 引入了连接 id，即独立于底层 IP 地址和端口的逻辑标识符。 当客户端的网络路径发生变化时，它可以通过出示自己的 CID 继续使用同一个 quic 连接。 服务器会识别连接，并继续之前的工作–没有新的握手，也没有 TLS 重新协商。

这种连接迁移对移动用户尤为重要。在视频通话、下载大文件或串流音乐时，从一个网络走到另一个网络不再意味着连接中断。这种体验是无缝的。

还有一个隐私方面的考虑：如果 CID 从未改变，观察者就可以跟踪网络变化中的连接，从而有可能将用户的家庭 IP 与办公室 IP 联系起来。 QUIC 允许轮换 CID，从而解决了这一问题。 新的 CID 可以在连接过程中发布，客户端可以使用它们来降低网络变化时的可链接性。实施过程中必须注意在连续性和隐私性之间取得平衡。

连接迁移的好处和注意事项：

  • 无缝过渡：网络变化不会中断 HTTP/3 会话
  • 无需重新握手：避免建立新连接的 RTT 成本
  • CID 轮换：如果实施得当，可减少跨网络跟踪
  • 服务器端支持：要求服务器维护以 CID 为密钥的连接状态

示例场景：您离家时正在用手机上传一大批照片。您的设备从家庭 Wi-Fi 转为 5G 蜂窝网络。使用 TCP 上的 HTTP/2，上传会在建立新连接后从最后确认的点重新开始。而使用 HTTP/3，上传会不间断地继续，只是在新的网络路径稳定下来时会有短暂的停顿。

部署状态和浏览器/服务器支持

HTTP/3 标准化已完成。核心规范包括 RFC 9114（HTTP/3）、RFC 9000（QUIC 传输）、RFC 9001（QUIC-TLS）和 RFC 9204（QPACK）。这些都不是实验草案，而是 IETF 标准轨道上的拟议标准。

目前，主要网络浏览器已普遍支持浏览器。截至 2024-2025：

  • 谷歌浏览器：自 2020 年起默认启用
  • Microsoft Edge：默认已启用（基于 Chromium）
  • Mozilla Firefox：自版本 88 起默认已启用
  • Safari 浏览器自 macOS Monterey (12) 和 iOS 15 起提供稳定支持
  • 基于 Chromium 的浏览器：Brave、Opera、Vivaldi 都继承了 Chrome 浏览器的支持功能

服务器的实施已经非常成熟：

  • NGINX：通过模块提供 QUIC 支持；正在进行主线集成
  • LiteSpeed：本地 HTTP/3 支持，常用于性能基准测试
  • 特使：生产就绪的 HTTP/3 支持
  • Apache httpd：通过模块（mod_http3）提供
  • 卡迪：内置 HTTP/3 支持
  • Microsoft IIS：在最近的 Windows Server 版本中提供支持

CDN 和主要供应商：

  • Cloudflare：在其边缘网络中全面启用 HTTP/3
  • Akamai：广泛支持HTTP/3
  • Fastly：HTTP/3 可在其边缘平台上使用
  • AWS CloudFront：提供 HTTP/3 支持
  • 谷歌云 CDN：本地 QUIC/HTTP/3 支持

全球采用指标因测量来源而异，但 W3Techs 和 HTTP Archive 的数据显示，目前有数十% 的网络请求使用 HTTP/3，且逐年增长。轨迹很明显：HTTP/3 正在从 “新选项 “过渡到 “预期默认值”。

基础设施和中间件的影响

HTTP/3 默认通过 UDP 运行，端口为 443。这与 HTTPS 通过 TCP 使用的端口相同，但协议不同。如果网络基础设施对 UDP 进行过滤或速率限制，或将其视为比 TCP 优先级更低的协议，就会影响 HTTP/3 的性能或完全无法运行。

实用基础设施考虑因素：

  • 防火墙：必须允许 UDP 端口 443 的入站和出站；某些企业防火墙默认情况下会阻止或限制 UDP
  • 负载平衡器：必须支持 QUIC/UDP 负载平衡；传统的 TCP 负载平衡器不适用于 HTTP/3
  • DDoS 设备：需要 QUIC 意识；基于 UDP 的攻击和合法的 QUIC 流量在数据包层面上看起来是不同的
  • 数据包检查：加密的 QUIC 标头阻止了传统的深度数据包检测；工具必须进行调整

由于 QUIC 对 TCP 暴露的大部分元数据进行了加密，因此传统的网络观测工具面临着挑战。你无法通过嗅探数据包轻松查看 HTTP/3 状态代码或请求路径。监控必须在端点（服务器、客户端或通过标准化日志）进行。

基础设施团队的行动项目：

  • 验证是否允许 UDP 443 通过所有网段
  • 确认负载平衡器是否支持 QUIC 或能否将 UDP 传递到后端
  • 针对 QUIC 流量模式更新 DDoS 缓解规则
  • 为 HTTP/3 可观察性部署端点级指标收集
  • 测试 QUIC 受阻时的后备行为

一些组织可能会遇到复杂的网络设置，由于历史原因，UDP 被取消优先级或被阻止。在仔细监控的情况下逐步推广，有助于在这些问题影响生产流量之前发现它们。

从 HTTP/2 迁移到 HTTP/3

从 HTTP/2 到 HTTP/3 的迁移路径是渐进和向后兼容的。您不必二选一–在部署HTTP/2 和 HTTP/1.1 的同时部署HTTP/3，让客户端协商最佳可用协议。

协议协商是在 TLS 握手过程中通过 ALPN（应用层协议协商）进行的。客户端公布支持的协议（如 “h3″、”h2″、”http/1.1″），服务器选择首选协议。此外，服务器还可以通过HTTP/2 响应中的Alt-Svc 标头宣传 HTTP/3 的可用性，从而允许浏览器升级后续请求。

不支持 HTTP/3 的客户端将继续使用 HTTP/2 或 HTTP/1.1，不会出现任何中断。不存在标志日或破坏性变化，迁移纯粹是添加性的。

高级迁移清单：

  1. 验证 TLS 1.3 是否就绪：HTTP/3 需要 TLS 1.3；确保您的 TLS 协议栈和证书支持 TLS 1.3
  2. 确认服务器支持：升级到具有 HTTP/3 功能的网络服务器或反向代理
  3. 更新网络基础设施：打开 UDP 443，验证负载平衡器的兼容性
  4. 在服务器上配置 HTTP/3：启用 QUIC 监听器，配置 Alt-Svc 标头
  5. 全面测试：使用浏览器开发工具、curl 和在线测试工具来验证
  6. 监控和比较：跟踪相对于 HTTP/2 基线的延迟、错误率和 CPU 使用率
  7. 逐步推广：从非关键领域开始，根据结果扩大范围

我们的目标是实现无缝共存。在可预见的未来，大多数部署将同时为 HTTP/3、HTTP/2 和 HTTP/1.1 提供服务。

启用 HTTP/3 的实用步骤

步骤 1：确保支持 TLS 1.3

HTTP/3 需要在 QUIC 中集成 TLS 1.3。验证您的 TLS 库（OpenSSL 1.1.1+、BoringSSL、LibreSSL 等）是否支持 TLS 1.3。对于面向公众的网站，证书应有效并受主要浏览器信任，而不是自签名。检查你的密码套件配置是否不包括 TLS 1.3 算法。

第 2 步：为 HTTP/3 配置网络服务器

对于 NGINX，您需要一个支持 QUIC 的构建（实验分支或第三方构建），或者等待主流集成。LiteSpeed 提供本地支持–通过配置启用。Envoy 最近的版本支持 HTTP/3。LiteSpeed 示例：在 UDP 443 上启用监听器，配置 SSL 证书，并将协议设置为包括 HTTP/3。

步骤 3：更新网络基础设施

在服务器和互联网之间的所有防火墙上打开 UDP 端口 443。对于云部署，更新安全组。验证您的负载平衡器是否能处理 UDP–有些负载平衡器（如 AWS ALB）需要特定配置或 NLB 才能支持 UDP。更新 DDoS 防护规则，以识别 QUIC 流量模式。

步骤 4：测试 HTTP/3 功能

使用浏览器开发工具：打开 “网络 “选项卡，添加 “协议 “栏，验证请求是否显示 “h3 “或 “http/3″。使用支持 HTTP/3 的 curl：curl –http3 https://your-domain.com。尝试使用在线测试工具（搜索 “HTTP/3 checker”）验证 Alt-Svc 标头和成功的 QUIC 连接。

步骤 5：逐步推广和监测

首先在测试域或暂存域上部署 HTTP/3。监控关键指标：连接时间、到第一字节的时间（TTFB）、到最后字节的时间（TTLB）、错误率和服务器 CPU 使用率。与 HTTP/2 基线进行比较。如果指标良好，则扩展到其他域。为无法协商 HTTP/3 的客户端保留 HTTP/2 后备功能。

常见挑战及应对方法

UDP 屏蔽或速率限制

一些企业网络、ISP 或国家会阻止或限制 443 端口的 UDP 流量。QUIC 包括后备机制–如果 QUIC 失败，浏览器将通过 HTTP/2 重试。确保您的 HTTP/2 配置作为后备路径保持健康。对于企业内部部署，请与网络团队合作，允许 UDP 443。

可观测性挑战

加密的 QUIC 标头使数据包级分析变得困难。解析 TCP 报头或 TLS 记录层的传统工具无法在 QUIC 中看到同等数据。可通过实施强大的端点日志记录、向监控系统导出 QUIC 指标以及使用在应用层运行的分布式跟踪来缓解这一问题。

CPU 使用率增加

QUIC 用户空间实现可能比内核优化的 TCP 消耗更多 CPU，尤其是在连接数较多的情况下。调整 QUIC 参数（如连接限制、拥塞控制算法）。考虑使用单线程性能更好的硬件。在可用的情况下，使用 TLS/QUIC 硬件加速。监控 CPU 趋势，必要时进行横向扩展。

传统客户端兼容性

较旧的浏览器、嵌入式系统和某些应用程序接口可能不支持 HTTP/3，甚至不支持 HTTP/2。请为这些客户端无限期维护 HTTP/1.1 和 HTTP/2 支持。使用 ALPN 协商为每个客户端提供其支持的最佳协议。不要为了 “强制 “支持 HTTP/3，而禁用早期版本。

中间件干扰

一些网络设备会对流量结构做出假设。QUIC 的加密设计有意防止中间件的干扰，但这意味着预计会检查流量的设备会无声无息地失败或阻止 QUIC。在测试过程中识别受影响的网络路径，并与网络团队合作进行策略更新。

证书问题

自签名证书可用于测试，但在生产浏览器中会导致 QUIC 连接失败。确保证书由可信 CA 签发，并为您的域正确配置。

安全、隐私和操作考虑因素

HTTP/3 的安全性能至少与 HTTP/2 的 HTTPS 一样强大。强制 TLS 1.3、加密传输头和集成加密握手默认提供了更强的安全性。攻击面与基于 TCP 的 HTTPS 有些不同，但总体安全模型是强大的。

安全性能：

  • 强制加密：不存在未加密的 HTTP/3 模式
  • 仅限 TLS 1.3：具有前向保密功能的现代密码套件
  • 加密元数据：向被动观察者隐藏数据包编号和报头字段
  • 数据完整性：QUIC 的验证功能可防止篡改
  • 防放大：QUIC 在地址验证前限制响应大小，防止 DDoS 反射

隐私方面的考虑：

  • 降低可见度：暴露给网络观察者的元数据更少
  • 连接 ID 跟踪：如果不旋转，CID 可能会启用跟踪功能
  • 相关性风险：跨 IP 变化的长期连接可能存在关联
  • 第一方与第三方：与 HTTPS 相同的内容访问隐私模式

运行方面的问题：

  • 合法拦截：加密 QUIC 使传统窃听方法复杂化
  • 企业监控：深度数据包检查不起作用；需要端点日志记录
  • 证书管理：适用标准 PKI 要求
  • 拒绝服务QUIC 连接可能会耗费更多服务器资源；限制速率非常重要
  • 前向纠错：某些实施方案可能会增加冗余，以提高抗损能力，从而影响数据传输量

对于有流量检测合规性要求的企业来说，HTTP/3 需要调整方法。端点代理、SIEM 集成和更新的安全工具取代了数据包级检测。

适用于 CDN 和大规模服务的 HTTP/3

CDN 是 HTTP/3 的最早采用者之一，其原因显而易见：它们为全球分布的用户提供服务，这些用户通常使用移动设备，具有高延迟的最后一英里连接。 HTTP/3 的特性–更快的握手、更好的抗丢失能力、连接迁移–直接有利于 CDN 边缘性能的提升。

在 CDN 边缘节点，HTTP/3 通过节省握手 RTT 缩短了首次字节时间。对于边缘服务器延迟较高地区的用户来说，这可以使页面加载时间缩短数百毫秒。更好地处理数据包丢失意味着在多变的网络条件下性能更加稳定。

一种常见的部署模式是：在边缘终止 HTTP/3，然后通过 CDN 骨干网使用 HTTP/2 或 HTTP/1.1 与源服务器通信。这样，CDN 就能为用户提供 HTTP/3 的优势，而无需源服务器支持 HTTP/3。随着时间的推移，将会有更多的源服务器直接采用 HTTP/3。

CDN 和大规模部署模式：

  • 边缘终止：从用户到边缘的 HTTP/3，从边缘到原点的 HTTP/2
  • 全球一致性：QUIC 在各种网络条件下均表现出色
  • 移动优化：连接迁移可帮助蜂窝网络用户
  • 减少重试次数：更少的连接失败意味着更少的客户端重试流量

示例情景： 一家全球性媒体网站为亚洲、欧洲和美洲的用户提供服务。东南亚用户到最近边缘的 RTT 为 150 至 200 毫秒。有了 HTTP/3，初始连接只需一个 RTT（而不是两个）即可完成，而 0-RTT 恢复则让重复访问感觉近乎即时。当这些用户使用移动设备在网络之间移动时，连接迁移可避免令人沮丧的重新连接。

总结与展望

HTTP/3 是 HTTP 协议诞生以来在传输方式上最重大的变革。通过在 UDP 上使用 QUIC 替代 TCP，HTTP/3 解决了困扰网络性能的基本限制–尤其是 移动用户和有损网络。

http 协议的语义保持不变：开发人员使用的请求、响应、标头和状态代码与以往相同。 改变的是底层的一切–数据包如何穿越网络、如何建立连接、如何处理数据包丢失，以及设备如何在网络之间不间断地移动。

标准化工作已经完成，浏览器支持已经普及，主要的 CDN 和网络服务器也已做好生产准备。所需的基础设施投资是真实的，但也是可控的：开放 UDP 443、升级服务器和更新监控工具。对于大多数部署而言，在支持现有 HTTP/2 的同时启用 HTTP/3，是一种直接的演进，而不是冒险的迁移。

展望未来，HTTP/3 很可能在未来几年内成为默认的 HTTP 传输方式。新的扩展正在开发中–多路径QUIC、改进的拥塞控制算法、更好的调试和监控工具。随着生态系统的成熟，调整选项和最佳实践也将不断发展。

主要启示

  • HTTP/3 保持 HTTP 语义不变，只有传输层有所不同
  • QUIC 通过独立的数据流消除了传输层的线路首端阻塞
  • 集成的 TLS 1.3 可将连接设置缩短至 1 RTT（恢复时为 0 RTT）
  • 连接迁移允许会话在网络变化后继续运行
  • 目前所有主流浏览器和 CDN 都支持 HTTP/3
  • 迁移是累加的：HTTP/2 和 HTTP/1.1 与 HTTP/3 同时继续工作
  • 最新版本的 HTTP 可用于生产

如果您尚未开始评估 HTTP/3 基础架构，现在正是时候。在暂存环境中启用 HTTP/3，衡量其对关键指标的影响，并计划逐步推广。性能的提升，尤其是对移动用户的提升，是真实且可衡量的。网络正在向 HTTP/3 迁移，早期采用者已经看到了好处。