HTTP/3是下一代跨Web的网络通信协议，这意味着它会部分取代HTTP/1和HTTP/2。离2月在苏黎世召开的下一届QUIC工作组会议还有一个月的时间，回顾一下HTTP/3的承诺和当前客户端/服务器的支持情况可能会非常有助益。

HTTP/3承诺让互联网连接更快、更稳定和更安全。它的前身为“HTTP over QUIC”，其目标是让HTTP在谷歌自己的传输层协议QUIC上运行，随后，它被提议为IETF，目前它是Internet草案。在2018年10月，IETF HTTP & QUIC工作组联席主席Mark Nottingham提议将HTTP over QUIC重命名为HTTP/3，以澄清其本质特点以及与QUIC的独立性。

QUIC是HTTP/3的关键元素，因为它是主要特性的基础。QUIC构建在UDP之上，致力于解决使用TCP协议的主要问题，比如，连接建立的延迟以及在包丢失的情况下多个流的处理。TCP延迟问题源于其拥塞控制算法的需求，该算法要求在拥塞发生之前会缓慢地开始（slow start）评估可以发送多少流量。在HTTP/1.0中，每个TCP请求/响应交换都会被分配一个新的连接，因此会导致启动缓慢的问题。

从此之后，规避TCP启动慢的尝试一直是HTTP协议改善的核心。

HTTP/1.1引入了“keep-alive”连接，允许在同一个TCP连接上对多个请求-响应交换进行序列化，因此不需要为每个请求都设置新的连接建立阶段。然而，HTTP/1.1的keep-alive连接不支持同时发送多个请求，随着Web页面日益复杂，这导致了新的瓶颈。

HTTP/2则源自现在已被弃用的SPDY协议，它引入了在同一连接中嵌入第一等流的概念。这使得在保证多路复用的同时实现请求-响应交换成为可能，但是它有一个主要的缺陷：当包丢失增加时，HTTP/2的性能会由于TCP处理包重传的方式（HOL阻塞）而下降。这种影响可能非常严重，因为所有流都共享相同的连接。当数据包丢失超过一个给定的阈值时，HTTP/1的多连接甚至会比HTTP/2运行地更高效。

如前文所述，QUIC提供了对流的第一等支持，这解决了HTTP/2中连接初始化缓慢的问题。另外，它可以对它们进行单独处理，从而解决了由于包丢失而导致的性能问题。采用QUIC作为传输层协议是HTTP/3与HTTP/2最大的区别。由于QUIC原生实现了大量与流管理相关的特性，这些特性是HTTP/2规范的组成部分，因此可以从HTTP/3中删除它们。此外，由于HTTP/2 HPACK报头压缩严重依赖于TCP向端点传递包的顺序，所以需要采用QUIC来创建新的HTTP报头压缩方案，即QPACK。

最近几年来，谷歌一直在使用QUIC提供自己的服务，包括搜索、YouTube等，而且在Chrome中也支持它。曾经有一段时间，在与支持QUIC的谷歌服务通信时，Chrome是唯一的手段。最近，Mozilla在Firefox 72中也增加了对HTTP/3的支持，尽管仍处于试验阶段。命令行工具curl在7.66.0版本中也增加了对HTTP/3的支持以及许多其他特性。在服务器端，LightSpeed和Nginx支持HTTP/3。

在云方面，除了谷歌之外，Cloudflare几个月前宣布已经为部分客户启用了对HTTP/3的初步支持。Cloudflare也是Quiche背后的公司，Quiche是一个支持HTTP/3客户端和服务器实现的开源Rust库。

如前所述，HTTP/3仍然正在由IETF进行定义，还没有确定正式的发布日期。与此同时，在世界范围内，HTTP/3的使用正在增长，全世界使用它的服务接近300,000个。谷歌仍然是部署HTTP/3的最重要组织，但是其他几个组织也占据了重要的份额。InfoQ将继续及时报道HTTP/3，让我们的读者了解互联网的最新变革。

原文链接：

The Status of HTTP/3

创作场景

HTTP/3 的现状：全世界使用服务接近 30 万