HTTP/2 与 HTTP/3：比较

HTTP/2 的背景

创建 HTTP/2 是为了解决 HTTP/1.1 的非结构化演进过程中出现的许多问题，其中大部分与性能相关。

许多问题是由于HTTP/1.1 的固有限制而出现的，归结为响应时间随着流量的增加而增加：

• HTTP线头阻塞(HTTP HoL) — 当一系列数据包被阻塞前方动脉的慢/大数据包阻塞时，HTTP HoL 会导致响应时间增加。

• 协议开销——服务器和客户端交换额外的请求和响应元数据，重复传输标头和 cookie 会增加响应速度并减慢响应速度。

• TCP慢启动——作为拥塞控制措施，协议反复探测网络以找出可用容量；在设法达到满负荷之前，多次小额转移可能会导致滞后。

开发人员试图通过域分片、流水线和使用“无 cookie”域等变通方法来解决这些问题和限制，但这些通常会导致兼容性和互操作性问题。显然，老化的 HTTP/1.1 标准需要更新。

2009 年，Google 宣布了SPDY，一个实验性协议，作为解决 HTTP/1.x 问题的结构化方法。HTTP 工作组注意到 Google 在使用 SPDY 实现更高的性能目标方面取得的成功。2012 年 11 月，发起了对 HTTP/2 的提案征集，并以 SPDY 规范为起点。

在接下来的几年里，HTTP/2 和 SPDY 与 SPDY 作为实验分支共同发展。HTTP/2 作为国际标准于 2015 年 5 月作为RFC 7540发布。

对 HTTP/3 的需求

多年来，HTTP 不断发展，从 0.9 版 5 年，1.0 版一年，到 1.1 版大约 15 年，最终在 2014 年到达第 2 版。在每次迭代中，都添加了新功能解决多种需求的协议，例如应用层要求、安全考虑、会话处理和媒体类型。如需深入了解 HTTP/2 及其从 HTTP/1.0 的演变，请阅读我们的HTTP 演变 - HTTP/2 深入探讨中的HTTP 不起眼的起源部分。

在这个演变过程中，HTTP 的底层传输机制大体上保持不变。然而，随着公众对移动设备技术的大量采用，互联网流量激增，新开箱的 HTTP/2 一直在努力提供流畅、透明的 Web 浏览体验。它承受着现代互联网流量的数量和速度，尤其是在实时应用程序及其用户不断增长的需求下。这导致在使用此版本的协议时出现许多警告，从而暴露出明显的改进机会。

多路复用、负载峰值和请求优先级

曾几何时，实时白板/图表公司Lucidchart 在其负载均衡器(LB) 上启用 HTTP/2 后遇到了一个意想不到的问题。

长话短说：他们注意到这些 LB 后面的服务器上的 CPU 负载更高，响应时间更慢。HTTP/2 吹捧提高了带宽效率、减少了延迟和请求优先级，因此没有加起来。但是什么？乍一看，流量看起来很正常，并且没有代码更改可以归咎于奇怪的行为。但是，虽然请求的平均数量是正常的，但流本身包含许多同时请求的高峰值。以前的供应模型未能考虑到这种情况，结果是对请求的响应超时或延迟。

实际原因是，只要用户的浏览器使用 HTTP/1.1，由于 HTTP/1.1 的串行请求处理性质，这有效地限制了并发请求的数量，使流量保持有序并在可预测的范围内。开启 HTTP/2 可能会出现不可预知的峰值，因为它具有多路复用功能，即使用单个连接发送并发请求。批处理请求对客户端来说非常有用，但是同时请求的开始时间和数量让 Lucidchart 的服务器非常头疼。

最后，能够在 LucidChart 的服务器上使用 HTTP/2 需要实施非平凡的解决方案，例如限制平衡器和重新构建应用程序。HTTP/2 软件的成熟度和对 HTTP 优先级的服务器支持的缺乏是额外的问题。一些应用程序仅通过安全套接字 (HTTPS) 支持 HTTP/2——对于安全的内部网络来说，这是一种不必要且繁重的架构复杂性。

服务器推送变得复杂

如果不小心使用，HTTP/2 推送功能弊大于利。例如，回访者可能有文件的缓存副本，在这种情况下，服务器不应该推送资源。使推送缓存感知可以解决这个问题，但这有它自己的警告，并且很快就会变得复杂。

那个讨厌的线阻塞头

HTTP/2 解决了 HTTP 级别的线头阻塞问题，它允许资源在同一连接上被多路复用、同时分解成块。但是，由于数据包丢失并且必须重新以正确的顺序重新发送， TCP 级别 的线路阻塞仍然可能发生。

HTTP/2 与 HTTP/3 有何不同？

HTTP/3 的目标是通过解决 HTTP/2 的传输相关问题，在所有形式的设备上提供快速、可靠和安全的 Web 连接。为此，它使用了一种名为 QUIC 的不同传输层网络协议，该协议最初由 Google 开发。

HTTP/2 和 HTTP/3 的根本区别在于 HTTP/3 在 QUIC 上运行，而 QUIC 在无连接 UDP 上运行，而不是面向连接的 TCP（所有以前版本的 HTTP 都使用）。

QUIC 中使用的面向连接的 TCP 与无连接 UDP 的比较

在语法和语义结构方面，HTTP/3 与 HTTP/2 类似。HTTP/3 参与相同类型的请求/响应消息交换，其数据格式包含方法、标头、状态代码和正文。但是，HTTP/3 引入的一个显着差异在于 UDP 之上协议层的堆叠顺序，如下图所示。

HTTP/3 中的堆叠顺序显示 QUIC 包含安全层和部分传输层

资料来源：金斯塔

下表比较了 HTTP/2 和 HTTP/3 的特性和功能：

HTTP/2 和 HTTP/3 Part 1/2 特性和能力对比表

HTTP/2 和 HTTP/3 Part 2/2 特性和能力对比表

HTTP/2 概述

 HTTP/2 是 HTTP/1.1 的扩展，而不是替代它。应用程序语义保持不变，具有相同的 HTTP 方法、状态代码、URI 和标头字段。

每个 HTTP/2 连接都以 HTTP/1.1 开始，如果客户端支持 HTTP/2，则连接会升级。HTTP/2 在客户端和服务器之间使用单个 TCP 连接，该连接在交互期间保持打开状态。

客户端和服务器之间通过 TCP（HTTP/2 底层传输协议）的请求和响应。

来源https://labs.tadigital.com/index.php/2019/11/28/http-2-vs-http-3/

HTTP/2 引入了许多旨在提高性能的特性：

• 创建交错通信流的二进制帧层。

• 完全多路复用而不是强制排序并因此阻塞（这意味着它可以使用一个连接进行并行）。

• 标头压缩以减少开销。

• 从服务器主动“推送”响应到客户端缓存。

HTTP/2：优点和缺点

优点

• 通过安装 SSL 证书，所有浏览器都支持基于 HTTPS 的 HTTP/2 协议。

• HTTP/2 允许客户端通过单个 TCP 连接同时发送所有请求。理论上，客户端应该更快地接收资源。

• TCP 是一种可靠、稳定的连接协议。

缺点

• 并发请求会增加服务器的负载。HTTP/2 服务器可以大批量接收请求，这会导致请求超时。服务器负载峰值问题可以通过插入负载均衡器或代理服务器来解决，这可以限制请求。

• 服务器对 HTTP/2 优先级的支持还不成熟。软件支持仍在不断发展。某些 CDN 或负载均衡器可能无法正确支持优先级。

• HTTP/2 推送功能可能很难正确实现。

• HTTP/2 解决了 HTTP 行头阻塞，但 TCP 级别的阻塞仍然会导致问题。

HTTP/2 适合哪些用例？

HTTP/2 支持 HTTP/1.x 的所有用例，无论它是在浏览器中实现的什么地方，包括桌面 Web 浏览器、移动 Web 浏览器、Web API 和 Web 服务器。但是，它也可以用于代理服务器、反向代理服务器、防火墙和内容分发网络，以及以下情况：

• 对于响应时间不重要的应用程序。

• 对于时间关键型应用程序，例如实时消息传递或流应用程序，只有在使用合适的自适应技术（例如WebSockets、服务器发送事件 (SSE)、发布-订阅 (pub/sub)消息传递）的情况下。

• 需要可靠连接的地方（TCP 的优势）

• 使用受限的物联网设备。

HTTP/3 概述

HTTP/3 支持快速、可靠和安全的连接。它默认使用 Google 的 QUIC 协议加密 Internet 传输。

HTTP/3：优点和缺点

优点

• 引入在 UDP 上运行的新（不同）传输协议 QUIC 意味着在理论上和目前实验上都减少了延迟。

• 因为 UDP 不在协议栈中执行错误检查和纠正，所以它适用于不需要或在应用程序中执行这些的用例。这意味着 UDP 避免了任何相关的开销。UDP 通常用于对时间敏感的应用程序，例如实时系统，这些应用程序不能等待数据包重传，因此可以容忍一些丢弃的数据包

缺点

• 传输层分支。过渡到 HTTP/3 不仅涉及应用层的变化，还涉及底层传输层的变化。因此，与其前身相比，采用 HTTP/3 更具挑战性。

• 可靠性问题。UDP 应用程序往往缺乏可靠性，因此必须接受一定程度的数据包丢失、重新排序、错误或重复。由最终用户应用程序提供任何必要的握手，例如实时确认消息已被接收。

• HTTP/3 尚未标准化。

HTTP/3 适合哪些用例？

• 实时应用程序，例如在线游戏、广告竞价和 IP 语音，以及使用实时流协议的地方。

• 广播信息如多种服务发现和共享信息如精确时间协议和路由信息协议。这是因为 UDP 支持多播。

• 物联网。HTTP/3 可以解决物联网用例（例如从连接的传感器收集数据的移动设备）的无线连接丢失问题。

• 大数据。随着 HTTP/3 变得足够强大，托管的 API 服务将能够进行流式传输，然后随着数据转换为商业智能而货币化。

• 基于网络的虚拟现实。VR 应用程序需要更多带宽来渲染虚拟场景的复杂细节，并且肯定会从迁移到由 QUIC 提供支持的 HTTP/3 中受益。

• 微服务：更快（或没有）握手意味着更快地遍历微服务网格。

HTTP/3 入门：HTTP/3 的开源解决方案

IETF 的 HTTP 工作组仍在致力于发布 HTTP/3。所以它还没有被 NGINX 和 Apache 等 Web 服务器正式支持。但是，有几个软件库可用于试验此新协议，并且还提供非官方补丁。

以下是支持 HTTP/3 和 QUIC 传输的软件库列表。请注意，这些实现基于互联网草案标准版本之一，该版本可能会被更高版本所取代，最终标准在 RFC 中发布。

• quiche ( https://github.com/cloudflare/quiche )：quiche 提供了一个低级编程接口，用于通过 QUIC 协议发送和接收数据包。它还支持 HTTP/3 模块，用于通过其 QUIC 协议实现发送 HTTP 数据包。它还为 NGINX 服务器提供了一个非官方补丁，用于安装和托管能够运行 HTTP/3 的 Web 服务器。除此之外，还有其他包装器可用于在 Android 和 iOS 移动应用程序上支持 HTTP/3。

• Aioquic ( https://github.com/aiortc/aioquic)：Aioquic是 QUIC 的 Python 实现。它还支持 HTTP/3 的内置测试服务器和客户端库。Aioquic 建立在 asyncio 模块之上，这是 Python 的标准异步 I/O 框架。

• Neqo ( https://github.com/mozilla/neqo )：Neqo 是 Mozilla 使用 Rust 实现的 QUIC 和 HTTP/3。

如果您想玩转 QUIC，请访问QUIC 协议的开源实现页面，由 QUIC 工作组维护。

实现 HTTP/3 的难点

过渡到 HTTP/3 不仅涉及应用层的变化，还涉及底层传输层的变化。传输层协议的变化可能证明是有问题的。安全服务通常是基于应用程序流量（大部分是 HTTP）将通过 TCP（可靠的、面向连接的协议）传输的前提而构建的。因此，采用 HTTP/3 比采用 HTTP/2 更具挑战性，后者仅需要更改应用程序层。

传输层经过网络中的中间盒的严格审查。这些中间盒，例如防火墙、代理、NAT 设备，执行大量深度数据包检查以满足其功能需求。用于主要（或仅）TCP 流量的防火墙默认数据包过滤策略有时会降低或阻止长时间的 UDP 会话。

此外，将传输从 TCP 更改为 UDP 可能会对安全基础设施解析和分析应用程序流量的能力产生重大影响，因为 UDP 是基于数据报（数据包）的协议，并且根据定义可能不可靠。因此，新传输机制的引入给 IT 基础架构和运营团队带来了一些复杂性。

随着 IETF 正在进行的标准化工作，这些问题最终将得到解决。鉴于谷歌早期对 QUIC 的实验所显示的积极结果，对 HTTP/3 的支持是压倒性的，这最终将迫使中间盒供应商进行标准化。

结论

HTTP/3 提供了互联网发展下一阶段所需的大量性能和安全改进。尽管如此，尽管存在明显需要增强 HTTP/2 的事实，但对于 HTTP/3 是否会最终成为对 HTTP/2 网络状态的全面改进，尚无定论。它今天站立并移动。

尽管浏览器和平台已经开始采用，但 HTTP/3 尚未进入 RFC 阶段（截至 2021 年 1 月），现在就其采用和实施成功发表声明还为时过早。对于实时应用程序，WebSockets、服务器发送事件 (SSE)和发布-订阅 (pub/sub)等成熟的技术仍然能够完美地提供 HTTP/2 中所需的功能。

此外，使用 QUIC 协议和 UDP（而不是 TCP）迁移到 HTTP/3 在具有可靠互联网连接的用例中留下了一些 QoS 问题。这增加了使用新兴协议所固有的不确定性。

HTTP/3 是传奇网络协议的一个令人兴奋的新发展，它将成为许多当前或未来用例的合适解决方案。但它旨在改进的标准还有很多生命力，而且 HTTP/2 不会很快消失。

进一步阅读

• HTTP 演进——HTTP-2 深入探讨

• HTTP 演进——HTTP3 深潜

• WebSockets 与 HTTP

• 比较 HTTP/3 与 HTTP/2 的性能

• HTTP/3：从根到提示

• Curl Quiche · Cloudflare HTTP/3 文档