仓库源文，站点原文

title: HTTP/3 slug: http categories: [http, http3]

author: blue

HTTP3 是 HTTP 协议的最新版本。从诞生之初，HTTP 就是交换超文本文档的首选应用层协议。 多年来，为了跟上互联网的发展，以及 WWW 上交换的内容种类增加，HTTP 进行了几次重大升级。

本文将深入探讨 HTTP/3，介绍 HTTP 协议的演变历程，重点介绍 HTTP/3 的特点，并对 HTTP/3 将会带来的互联网变化提供新的视角。

• 背景 在万维网诞生之时，万维网仅仅是一群交换超文本文件的计算机。在计算机之间交换文件 是一个简单的程序，包括请求和响应。在此基础上设计了一个简单的基于文本的协议。 HTTP（超文本传输协议）应运而生。后来，它被起草成了一个标准化的 IETF 协议， 定义在 RFC 1945 中，也被称为 HTTP/1.0。

多年来，HTTP 从 HTTP/1.0 发展到 HTTP/1.1，再到 HTTP/2。在每一次迭代中， 协议都增加了新的功能，以处理大量的需求，如应用层需求、安全考虑、会话处理和媒体类型等。 要深入了解 HTTP/2 及其从 HTTP/1.0 演变而来的 HTTP/2，请看我们的 HTTP/2 概念文章。

尽管经历了几次修订，但 HTTP 的底层传输机制基本没有变化。但是，随着互联网流量的激增， 在移动电话的推动下，HTTP 的传输机制在保证网页浏览体验的流畅性方面变得问题重重。

HTTP/3 是为了处理 HTTP/2.0 的传输相关问题而生的，可以在各种设备上更快地访问 Web。 它基于一个新的传输层协议，称为 QUIC（Quick UDP Internet Protocol），在 UDP 之上工作。 这一选择与之前版本的 HTTP 截然不同，之前版本都是基于 TCP。TCP 是一个比 UDP 更可靠的协议， 那么为什么要在 UDP 之上重新设计 HTTP 的传输层呢？

让我们来看看在 TCP 上运行 HTTP 的局限性，并深入了解一下基于 QUIC 协议的 HTTP/3 的设计思想。

• 什么是 HTTP/3 当 IETF 正式标准化 HTTP/2 时，Google 正在独立构建一个新的传输协议，名为 gQUIC。 它后来成为新互联网草案，并被命名为 QUIC。gQUIC 最初的实验证明，在网络条件较差的情况下， gQUIC 在增强网页浏览体验方面的效果非常好。因此，gQUIC 的发展势头越来越好，IETF 的大多数成员赞成建立一个在 QUIC 上运行的 HTTP 新规范。这个新的倡议被称为 HTTP/3， 以区别于当前的 HTTP/2 标准。

从语法和语义上看，HTTP/3 与 HTTP/2 相似。HTTP/3 遵循相同的请求和响应消息交换顺序， 其数据格式包含方法、标题、状态码和 body。然而，HTTP/3 的显著的偏差在于协议层在 UDP 之上的堆叠顺序。

• HTTP/3 是如何工作的？ HTTP/3 功能的核心是围绕着底层的 QUIC 协议来实现的。在讨论 QUIC 和 UDP 之前， 我们有必要先列出 TCP 的某些限制，这也是导致 QUIC 发展的原因。

• TCP 可能会间歇性地挂起数据传输 如果一个序列号较低的数据段还没有接收到，即使其他序列号较高的段已经接收到，TCP 的接收机滑动窗口也不会继续处理。这将导致 TCP 流瞬间挂起，在更糟糕的情况下， 即使所有的段中有一个没有收到，也会导致关闭连接。这个问题被称为 TCP 流的行头阻塞（HoL）。

• TCP 不支持流级复用 虽然 TCP 确实允许在应用层之间建立多个逻辑连接，但它不允许在一个 TCP 流中复用数据包。 使用 HTTP/2 时，浏览器只能与服务器打开一个 TCP 连接，并使用同一个连接来请求多个对象， 如 CSS、JavaScript 等文件。在接收这些对象的同时，TCP 会将所有对象序列化在同一个流中。 因此，它不知道 TCP 段的对象级分区。

• TCP 会产生冗余通信 TCP 连接握手会有冗余的消息交换序列，即使是与已知主机建立的连接也是如此。 QUIC 协议在以下设计选择的基础上，通过引入一些底层传输机制的改变，解决了这些问题。

  1.选择 UDP 作为底层传输层协议。在 TCP 之上建立新的传输机制，将继承 TCP 的上述所有缺点。 因此，UDP 是一个明智的选择。此外，QUIC 是在用户层构建的，所以不需要每次协议升级时进行内核修改。

流复用和流控。QUIC 引入了连接上的多路流复用的概念。QUIC 通过设计实现了单独的、 针对每个流的流控，解决了整个连接的行头阻塞问题。

灵活的拥塞控制机制。TCP 的拥塞控制机制是刚性的。该协议每次检测到拥塞时， 都会将拥塞窗口大小减少一半。相比之下，QUIC 的拥塞控制设计得更加灵活， 可以更有效地利用可用的网络带宽，从而获得更好的吞吐量。

更好的错误处理能力。QUIC 使用增强的丢失恢复机制和转发纠错功能，以更好地处理错误数据包。 该功能对于那些只能通过缓慢的无线网络访问互联网的用户来说是一个福音， 因为这些网络用户在传输过程中经常出现高错误率。

更快的握手。QUIC 使用相同的 TLS 模块进行安全连接。然而，与 TCP 不同的是，QUIC 的握手机制经过优化，避免了每次两个已知的对等者之间建立通信时的冗余协议交换。

灵活的拥塞控制机制。TCP 的拥塞控制机制是刚性的。该协议每次检测到拥塞时， 都会将拥塞窗口大小减少一半。相比之下，QUIC 的拥塞控制设计得更加灵活， 可以更有效地利用可用的网络带宽，从而获得更好的吞吐量。

更好的错误处理能力。QUIC 使用增强的丢失恢复机制和转发纠错功能，以更好地处理错误数据包。 该功能对于那些只能通过缓慢的无线网络访问互联网的用户来说是一个福音，因为这些 网络用户在传输过程中经常出现高错误率。

更快的握手。QUIC 使用相同的 TLS 模块进行安全连接。然而，与 TCP 不同的是，QUIC 的握手机制经过优化，避免了每次两个已知的对等者之间建立通信时的冗余协议交换。

• 为什么 HTTP/3 很重要？ TCP 已经有 40 多年的历史了。它在 1981 年通过 RFC 793 从而标准化。多年来， 它经历了多次更新，是一个非常强大的传输协议，可以支持互联网流量的增长。然而， 由于设计上的原因，TCP 从来就不适合处理有损无线环境中的数据传输。在互联网的早期， 有线网络将网络中的每一台计算机连接起来。

现在，随着智能手机和便携式设备的数量超过台式机和笔记本电脑的数量，超过 50% 的互联网流量已经通过无线传输。这种趋势给整体的网络浏览体验带来了问题， 其中最重要的是在无线覆盖率不足的情况下，TCP 中的行头阻塞。

Google 的一些初步实验证明，QUIC 作为 Google 部分热门服务的底层传输协议， 极大地提高了速度和用户体验。部署 QUIC 作为 YouTube 视频的底层传输协议，导致 YouTube 视频流的缓冲率下降了 30%，这直接影响了用户的视频观看体验。在显示谷歌搜索结果时， 也有类似的改善。

网络条件较差的情况下提升非常明显，这促使谷歌更加积极地完善该协议，并最终向 IETF 提出标准化。

由于这些早期的试验所带来的所有改进，QUIC 已经成为带领万维网走向未来的重要因素。 在 QUIC 的支持下，HTTP 从 HTTP/2 到 HTTP/3 的改头换面，朝着这个方向合理地迈出了一步。

• HTTP/3 的最佳用例 HTTP/3 将改善我们上网的体验，特别是在仍无法使用高速无线网络的地区。尽管 HTTP/2 已经解决了一部分问题，然而 HTTP/3 更进一步。

• 物联网(IoT) HTTP 可能不是物联网的首选协议，但在某些情况下，基于 HTTP 的通信非常适合特定的应用。 HTTP/3 可以解决从传感器收集数据的移动电话的无线连接损耗问题。这个问题同样适用于 安装在车辆或可移动资产上的独立 IoT 设备。通过 HTTP 来访问这些设备，可以更加可靠。

• 大数据 全球各地的企业都在觉醒，意识到从多个部门收集数据的潜力，并将其整合成更大的信息共享 API， 供内部和外部受众共享。这些 API 也为数据的货币化铺平了道路，通过托管这些数据作为流 API 服务可以实现数据的货币化。随着时间的推移，这些服务会吐出海量的数据。通过 HTTP/3 托管的流 API 将使它们比 HTTP/2 更健壮、更有弹性。

• Web VR 随着浏览器能力的提升，内容格局正在快速变化。其中一个领域就是基于网络的 VR。 虽然还处于起步阶段，但有很多的用例可以让 VR 在加强协作方面发挥关键作用。 网络在促进 VR 互动方面占据了核心位置。VR 应用需要更多的带宽来渲染虚拟场景中的复杂细节， 因此迁移到 HTTP/3 会大有收获。

• 采用 HTTP/3：考虑和限制 过渡到 HTTP/3 不仅涉及到应用层的变化，还涉及到底层传输层的变化。因此，与它的前身 HTTP/2 相比，HTTP/3 的采用更具挑战性，因为后者只需要改变应用层。传输层承受着 网络中的大量中间层审查。这些中间层，如防火墙、代理、NAT 设备等会进行大量的 深度数据包检查，以满足其功能需求。因此，新的传输机制的引入对 IT 基础设施和 运维团队来说有一些影响。

然而，HTTP/3 被广泛采用的另一个问题是，它是基于 QUIC 的，在 UDP 上运行。大多数的 Web 流量，以及 IETF 定义的知名服务都是在 TCP 之上运行的。这也是为什么长时间运行 HTTP/3 的 UDP 会话会被防火墙的默认数据包过滤策略所影响的原因。

随着 IETF 正在进行的标准化工作，这些问题最终都会得到解决。此外，考虑到 Google 在早期 QUIC 实验所显示的积极结果，人们对 HTTP/3 的支持是压倒性的， 这将最终迫使中间层厂商标准化。

针对受限的 IoT 设备，HTTP/3 由于过于繁琐从而无法采用。许多 IoT 应用部署的设备的 外形尺寸非常小。因此，它们的 RAM 和 CPU 功率都是有限的。为了使设备在电池功率、 低比特率和有损连接等限制条件下高效运行，必须执行此要求。HTTP/3 在现有的 UDP 之上， 以 QUIC 的形式在传输层处理，增加了 HTTP/3 在整个协议栈中的占用空间。这使得 HTTP/3 较为笨重，不适合那些 IoT 设备。但这种情况很少出现，而且存在专门的协议，这就避免了 直接在此类设备上支持 HTTP 的需要。此外，还有以物联网为核心的协议，如 MQTT。

• 开始使用 HTTP/3 IETF 的 HTTP 工作组正致力于在 2020 年后期发布 HTTP/3。因此它还没有被 NGINX 和 Apache 等主流 web 服务器正式支持。不过，有几个 lib 可以用来实验这个新协议， 也提供了非官方的补丁。

以下是支持 HTTP/3 和 QUIC 传输 lib 的列表。请注意，这些实现都是基于互联网标准草案 某一个版本，而这个版本很可能会被更高的版本所取代，最终的标准会在 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 模块之上，asyncio 模块是 Python 的标准异步 I/O 框架。

Neqo (https:/github.com/mozilla/neqo)

Neqo 是 Mozilla 使用 Rust 实现 QUIC 和 HTTP/3。

原文地址：https://www.ably.io/concepts/http3?utm_medium=referral&utm_source=reddit&utm_campaign=evergreen#limitations

引用地址：https://mp.weixin.qq.com/s/i-QUbVRVicqzMSZ9FUVCfQ

评论:

有人说, 当他们身在中国大陆使用 UDP 服务时会被 QoS 限流.

虽说是将来的标准, 但整体来说, 这还是未来式.

我们可以通过 https://caniuse.com/#feat=http3 来了解浏览器对其的支持情况.