HTTP/3就在这里，这对web性能来说是一件大事。看看它能让网站变得多快！

等等，等等，HTTP/2怎么了？那不是几年前才风靡一时吗？的确是这样，但也有一些问题。为了解决这些问题，有一个新版本的古老协议正在标准化轨道上运行。

好的，但是HTTP/3真的能让事情变得更快吗？确实如此，我们有基准来证明这一点。

快速预览

在我们深入了解细节之前，让我们先来看一下基准测试结果的快速预览。在下面的图表中，使用同一浏览器通过同一网络请求同一站点，仅改变使用的HTTP协议。每个站点被检索20次，响应时间通过性能API测量。（稍后将详细介绍基准方法）

使用每个新版本的HTTP协议时，您都可以清楚地看到性能的提高：

当在更大的地理距离和更不可靠的网络上请求资源时，这种变化变得更加明显。

但在我们完全了解所有HTTP/3基准细节之前，需要一点上下文。

HTTP的简史

HTTP（超文本传输协议1.0）的第一个正式版本于1996年定稿。有一些实际问题和部分标准需要更新，因此HTTP/1.1在一年后的1997年发布。根据作者的说法：

但是，HTTP/1.0没有充分考虑分层代理、缓存、持久连接的需要和虚拟主机的影响。此外，称自己为“HTTP/1.0”的未完全实现的应用程序大量增加，这就需要更改协议版本，以便两个通信应用程序确定彼此的真正功能。

再过18年，HTTP的新版本才会发布。2015年，RFC 7540将大张旗鼓地将HTTP/2标准化为该协议的下一个主要版本。

一次一个文件

如果一个网页需要10个javascript文件，则web浏览器需要在该网页完成加载之前检索这10个文件。在HTTP/1.1-land中，web浏览器一次只能通过与服务器的TCP连接下载一个文件。这意味着文件是按顺序下载的，一个文件中的任何延迟都会阻止后面的所有内容。这被称为线头阻塞，对性能不好。

为了解决这个问题，浏览器可以打开到服务器的多个TCP连接，以并行化数据检索。但这种方法是资源密集型的。每个新的TCP连接都需要客户端和服务器资源，当您在混合中添加TLS时，也会发生大量SSL协商。需要一种更好的方法。

使用 HTTP/2 进行多路复用

HTTP/2 的一大卖点是多路复用。它通过切换到允许多路复用文件下载的二进制在线格式来修复应用程序级别的行头阻塞问题。也就是说，客户端可以一次请求所有 10 个文件，并开始通过单个 TCP 连接并行下载它们。

不幸的是，HTTP/2 仍然存在头部阻塞问题，只是低了一层。 TCP 本身成为链中的薄弱环节。任何丢失数据包的数据流都必须等到该数据包被重新传输才能继续。

然而，由于 HTTP/2 多路复用的并行特性对 TCP 的丢失恢复机制不可见，丢失或重新排序的数据包会导致所有活动事务陷入停顿，无论该事务是否直接受到丢失数据包的影响。

事实上，在高丢包的环境中，HTTP/1.1 的表现更好，因为浏览器打开了多个并行的 TCP 连接！

HTTP/3 和 QUIC 的真正复用

输入 HTTP/3。 HTTP/2 和 HTTP/3 之间的主要区别在于它们使用哪种传输协议。 HTTP/3 使用一种称为 QUIC 的新协议代替 TCP。 QUIC 是一种通用传输协议，旨在解决 HTTP/2 与 TCP 之间的队头阻塞问题。它允许您通过 UDP 创建一系列有状态的流（类似于 TCP）。

QUIC传输协议包含流多路复用和每流流量控制，与HTTP/2帧层提供的协议类似。通过在流级别提供可靠性并在整个连接中提供拥塞控制，QUIC能够提高HTTP的性能，而不是TCP映射

并提高HTTP的性能！如果你不在乎测试是如何进行的，就直接看结果

基准测试HTTP/3

为了了解HTTP/3的性能差异，需要一个基准测试设置。

HTML

为了更接近实际使用情况，测试设置由三个场景组成：一个小站点、一个内容丰富的站点（大量图像和一些JS）和一个单页应用程序（大量使用JS）。我查看了几个真实的站点，平均每个站点的图像和JS文件数量，然后编写了一些与这些资源数量（和大小）匹配的演示站点。

小站点

• 10 JS files from 2kb to 100kb
• 10 images from 1kb to 50kb
• Total payload size 600kb, 20 blocking resources total

内容站点

• 50 JS files from 2kb to 1mb
• 55 images ranging in size from 1kb to 1mb.
• Total payload size 10MB, 105 resources total (look at cnn.com sometime in dev tools and you’ll see why this is so big)

单页应用程序

• 85 JS files from 2kb to 1mb
• 30 images ranging in size from 1kb to 50kb.
• Total payload size 15MB, 115 resources total (look at JIRA sometime in dev tools)

服务器

Caddy用于提供所有资产和HTML。

• 所有响应都使用缓存控制：“无存储”，以确保浏览器每次都会重新下载。
• TLS1.2用于HTTP/1.1和HTTP/2
• TLS1.3用于HTTP/3。
• 已为所有HTTP/3连接启用0-RTT

地点

测试从我在明尼苏达州的电脑到Digital Ocean托管的三个独立数据中心进行：

客户

我自动让浏览器连续20次请求相同的页面，在页面加载后等待3秒钟，开始下一个请求。互联网连接速度为200mbps。在数据捕获时，计算机上没有运行其他应用程序。

那么HTTP/3有多快？

美国纽约

以下是从纽约数据中心请求三个不同站点时HTTP/2与HTTP/3的响应时间：

HTTP/3是：

• 200ms faster for the Small Site
• 325ms faster for the Content Site
• 300ms faster for the Single Page Application

从明尼苏达州到纽约的距离是1000英里，按网络标准来说，这相当小。重要的是，即使是在相对较短的距离内，HTTP/3也能够将性能提高这么多。

英国伦敦

我也在结果中包含了针对伦敦的HTTP/1.1基准测试运行。为了显示HTTP/2和HTTP/3的速度有多快，我将图表保持在相同的比例。您可以看到，对于内容站点，时间安排非常慢，以至于它们甚至不完全适合图表！

正如您所看到的，当网络上的距离越远时，速度的提高就越明显。HTTP/3是：

• 600ms faster for the Small Site (3x the speedup compared with New York)
• 1200ms faster for the Content Site (over 3.5x the speedup compared with New York)
• 1000ms faster for the Single Page Application (over 3x the speedup compared with New York)

印度班加罗尔

在印度，当从服务器加载页面时，HTTP/3的性能改进非常明显。我甚至没有运行HTTP/1.1测试，因为它太慢了。以下是HTTP/2与HTTP/3的对比结果：

当涉及更大的地理位置和更多的网络跃点时，HTTP/3将继续领先。也许更引人注目的是，HTTP/3的响应时间是多么紧密。当数据包旅行数千英里时，QUIC产生了巨大的影响。

在任何情况下，HTTP/3都比它的前身快！

为什么HTTP/3要快得多？

真实的多路复用 （Real Multiplexing）

HTTP/3真正的多路复用特性意味着堆栈上任何地方都不会发生行首阻塞。当从更远的地理位置请求资源时，数据包丢失的可能性更高，并且需要TCP重新传输这些数据包。

0-RTT是游戏规则的改变者 （0-RTT Is a Game Changer）

此外，HTTP/3支持O-RTT QUIC连接，这减少了与服务器建立安全TLS连接所需的往返次数。

QUIC中的0-RTT特性允许客户端在握手完成之前发送应用程序数据。这可以通过重用以前连接中协商的参数来实现。要实现这一点，0-RTT依赖于客户端记住关键参数，并向服务器提供TLS会话票证，以允许服务器恢复相同的信息。

但是，不应盲目启用0-RTT。根据您的威胁模型，可能存在一些安全问题。

0-RTT数据的安全属性弱于其他类型TLS数据的安全属性。明确地：

此数据不是前向机密，因为它仅在使用提供的PSK派生的密钥下加密。

不保证连接之间不重播。

我今天可以使用HTTP/3吗？

大概虽然该协议目前处于Internet草稿状态，但已有大量的实现。

我特别为这些基准选择了Caddy，因为可以使用Caddyfile中的简单配置值启用HTTP/3

NGINX也有实验性的支持，并正致力于在不久的将来正式发布HTTP/3。

像谷歌和Facebook这样的大型科技公司已经在通过HTTP/3提供流量服务。google.com完全通过HTTP/3为现代浏览器提供服务。

对于那些困在Windows生态系统中的人来说，据说Windows Server 2022将支持HTTP/3，需要一些相当深奥的步骤来启用它。

结论

HTTP/3可以在用户体验站点的方式上产生很大的不同。通常，站点需要的资源越多，HTTP/3和QUIC的性能改进就越大。随着该标准继续接近最终确定，现在可能是开始考虑为您的站点启用该标准的时候了。

 

原文：https://medium.com/request-metrics/http-3-is-fast-dc7f8871df6

本文：http://jiagoushi.pro/node/1612