HTTP/3到底是什么？为什么在HTTP/2之后这么快就需要它

为什么我们需要 HTTP/3？

为什么我们需要 HTTP/3？

我经常遇到的一个问题是，“为什么在 2015 年才标准化的 HTTP/2 之后这么快就需要 HTTP/3？” 这确实很奇怪，直到您意识到我们一开始并不真正需要新的 HTTP 版本，而是需要对底层 传输控制协议 (TCP) 进行升级。

TCP 是提供关键服务的主要协议，例如向 HTTP 等其他协议提供 可靠性和按顺序交付等关键服务。 这也是我们可以继续与许多并发用户一起使用 Internet 的原因之一，因为它巧妙地将每个用户的带宽使用限制在他们的公平份额内。

你可知道？

使用 HTTP(S) 时，您实际上是在同时使用除 HTTP 之外的多种协议。这个“堆栈”中的每个协议都有自己的特性和职责（见下图）。例如，当 HTTP 处理 URL 和数据解释时，传输层安全性 (TLS) 通过加密确保安全性，TCP 通过重新传输丢失的数据包来实现可靠的数据传输，而互联网协议 (IP) 将数据包从一个端点路由到另一个端点的不同设备之间（中间框）。

这种相互叠加的协议“分层”是为了方便重用它们的特性。高层协议（如 HTTP）不必重新实现复杂的功能（如加密），因为低层协议（如 TLS）已经为它们完成了这项工作。再举一个例子，Internet 上的大多数应用程序在内部使用 TCP 来确保它们的所有数据都被完整传输。因此，TCP 是 Internet 上使用最广泛和部署最广泛的协议之一。

几十年来，TCP 一直是网络的基石，但它在 2000 年代后期开始显示其时代。它的预期替代品是一种名为QUIC的新传输协议，它在几个关键方面与 TCP 有很大不同，直接在其上运行 HTTP/2 将非常困难。因此，HTTP/3 本身是对 HTTP/2 的一个相对较小的改编，以使其与新的 QUIC 协议兼容，该协议包含了人们兴奋的大部分新功能。

之所以需要 QUIC，是因为 TCP 自 Internet 早期就已经存在， 并没有真正考虑到最大效率 。例如，TCP 需要一个“握手”来建立一个新的连接。这样做是为了确保客户端和服务器都存在并且他们愿意并且能够交换数据。然而，它也需要一个完整的网络往返才能完成，然后才能对连接进行任何其他操作。如果客户端和服务器在地理上相距遥远，则每次往返时间 (RTT) 可能会花费超过 100 毫秒，从而导致明显的延迟。

作为第二个示例，TCP 将其传输的所有数据视为 单个“文件”或字节流 ，即使我们实际上是在同时使用它来传输多个文件（例如，当下载由以下内容组成的网页时）很多资源）。实际上，这意味着如果包含单个文件数据的 TCP 数据包丢失，那么所有其他文件也会延迟，直到这些数据包被恢复。

这称为 线头 (HoL) 阻塞 。虽然这些低效率在实践中是可以控制的（否则，我们不会使用 TCP 超过 30 年），它们确实会以明显的方式影响更高级别的协议，例如 HTTP。

随着时间的推移，我们尝试改进和升级 TCP 以改善其中的一些问题，甚至引入新的性能特性。例如，TCP Fast Open通过允许高层协议从一开始就发送数据，从而消除了握手开销。另一项工作称为MultiPath TCP。这里的想法是您的手机通常同时具有 Wi-Fi 和 (4G) 蜂窝连接，那么为什么不同时使用它们来提高吞吐量和鲁棒性呢？

实现这些 TCP 扩展并不难。然而， 在互联网规模上实际部署它们极具挑战性 。由于 TCP 如此流行，几乎每个连接的设备都有自己的板载协议实现。如果这些实现太旧、缺少更新或有问题，那么这些扩展将无法实际使用。换句话说，所有实现都需要了解扩展才能使其有用。

如果我们只讨论最终用户设备（例如您的计算机或 Web 服务器），这不会有太大问题，因为这些可以相对容易地手动更新。但是，许多其他设备位于客户端和服务器之间，它们也有自己的 TCP 代码（示例包括防火墙、负载平衡器、路由器、缓存服务器、代理等）。

这些中间盒通常更难更新，有时它们接受的内容更严格。例如，如果设备是防火墙，它可能被配置为阻止所有包含（未知）扩展的流量。实际上，事实证明，大量的活动中间盒对 TCP 做出了某些假设，这些假设不再适用于新的扩展。

因此，可能需要数年甚至十多年的时间才能更新足够的（中间盒）TCP 实现以实际大规模使用扩展。可以说，TCP 已经几乎不可能演进了。

因此，很明显我们需要一个 TCP 协议的替代协议，而不是直接升级来解决这些问题。然而，由于 TCP 功能及其各种实现的绝对复杂性，从头开始创建新的但更好的东西将是一项艰巨的任务。因此，在 2010 年代初，决定推迟这项工作。

毕竟，不仅 TCP 存在问题，HTTP/1.1 也存在问题。我们选择拆分工作并首先“修复” HTTP/1.1，从而形成现在的 HTTP/2。完成后，可以开始替换 TCP，即现在的 QUIC。最初，我们希望能够直接在 QUIC 之上运行 HTTP/2，但在实践中这会使实现效率太低（主要是由于功能重复）。

相反，HTTP/2 在几个关键领域进行了调整，使其与 QUIC 兼容。这个经过调整的版本最终被命名为 HTTP/3（而不是 HTTP/2-over-QUIC），主要是出于营销原因和清晰度。因此，HTTP/1.1 和 HTTP/2 之间的差异比 HTTP/2 和 HTTP/3 之间的差异要大得多。