导读：花儿为什么这样红，HTTP3为什么这样快？本文有详细说明。
HTTP/3 来了，它对 Web 性能来说意义重大。看看它能使网站的速度有多快！等等，HTTP/2 发生了什么？这不是才短短几年的技术，现在还属于流行技术吗？
确实是这样，但是HTTP/2仍有一些问题。为了解决这些问题，HTTP 这个古老协议的新版本正在通过标准轨道积极发挥作用。
HTTP/3 真的能让访问变得更快吗？确实如此，我们有基准测试数据来证明这一点。
快速概述
在深入了解细节之前，让我们快速预览一下基准测试结果。在下面的图表中，使用相同的浏览器通过相同的网络带宽请求相同的站点，仅改变正在使用的 HTTP 协议。
每个站点被查询 20 次，响应时间通过性能 API 测量。在使用每个新版本的 HTTP 协议时，你可以清楚地看到性能的改进情况：
当在更大的地理距离和更不可靠的网络上请求资源时，这些变化变得将更加明显。
HTTP 简史
HTTP（超文本传输协议 1.0）的第一个正式版本于 1996 年完成。由于存在一些实际问题和部分标准需要更改，一年后也就是 1997 年又发布了HTTP/1.1。
根据HTTP协议作者的自我描述：
HTTP/1.0 没有充分考虑分层代理、缓存、持久连接的需要和虚拟主机的影响。此外，自称为“HTTP/1.0”的未完全实现应用程序激增的情况，需要更改协议版本，以便两个正在通信的应用程序确定彼此的真实功能。
新版本的 HTTP 发布等了 18 年时间。2015 年，RFC 7540大张旗鼓地将 HTTP/2 标准化为该协议的下一个主要版本。
一次传输一个文件
如果网页需要 10 个 JavaScript 文件，则 Web 浏览器需要在页面完成加载之前查询这 10 个文件。在 HTTP/1.1中，Web 浏览器一次只能通过与服务器的 TCP 连接下载一个文件。这意味着文件是按顺序下载的，一个文件中的任何延迟都会阻止它后面的所有其他内容。这称为Head-of-line Blocking，它对性能不利。
为了解决此问题，浏览器可以打开多个到服务器的 TCP 连接来并行化数据查询。但这种方法是资源密集型的。每个新的 TCP 连接都需要客户端和服务器资源，当你在混合中添加 TLS 时，也会发生大量 SSL 协商。这需要一种更好的方法。
使用 HTTP/2 进行多路复用
HTTP/2 的一大卖点是多路复用。它通过切换到允许多路复用文件下载的二进制在线格式来修复应用程序级别的行头阻塞问题。也就是说，客户端可以一次请求所有 10 个文件，并开始通过单个 TCP 连接并行下载它们。
不幸的是，HTTP/2 仍然存在头部阻塞问题，只是低了一层。TCP 本身成为链中的薄弱环节。任何丢失数据包的数据流都必须等到该数据包被重新传输才能继续。
然而，因为 HTTP/2 多路复用的并行特性对于 TCP 的丢失恢复机制是不可见的，丢失或重新排序的数据包会导致所有活动事务都遇到停顿，无论该事务是否直接受到丢失数据包的影响。
事实上，在高丢包的环境中，HTTP/1.1 的表现更好，因为浏览器打开了多个并行的 TCP 连接！
HTTP/3 和 QUIC 的真正复用
HTTP/2 和 HTTP/3 之间的主要区别在于它们使用哪种传输协议。
HTTP/3 使用一种称为QUIC的新协议代替 TCP 。QUIC 是一种通用传输协议，旨在解决 HTTP/2 与 TCP 之间的队头阻塞问题。它允许您通过 UDP创建一系列有状态的流（类似于 TCP）。
QUIC 传输协议结合了流复用和每个流的流量控制，类似于 HTTP/2 提供的成帧层。
通过提供流级别的可靠性和整个连接的拥塞控制，与 TCP 映射相比，QUIC 能够有效提高 HTTP 的性能。
HTTP/3 基准测试
为了了解 HTTP/3 产生什么样的性能差异，人们需要一个基准测试设置。
HTML网页
为了更接近实际使用情况，测试设置由三个场景组成 – 一个小站点、一个内容丰富的站点（大量图像和一些 JS）和一个单页面应用程序（在 JS 上很重）。
我查看了几个真实的站点，并对每个站点的图像和 JS 文件的数量求平均值，然后编写了一些与这些资源数量（和大小）匹配的演示站点。
小型站点
10 个2kb 到 100kb 的 JS 文件
从 1kb 到 50kb 的10张图像
总有效载荷大小600kb，总共 20 个阻塞资源
内容站点
50 个2kb 到 1mb 的 JS 文件
55张大小从 1kb 到 1mb 的图像。
总有效负载大小10MB，总共 105 个资源（有时在开发工具中查看 cnn.com，您会明白为什么它如此之大）
单页应用程序
从 2kb 到 1mb 的85 个JS 文件
30张大小从 1kb 到 50kb 的图像。
总有效负载大小15MB，总共 115 个资源（有时在开发工具中查看 JIRA）
服务器
用于提供所有的资产与 HTML。
提供所有响应Cache-Control: “no-store”以确保浏览器每次都会重新下载
TLS 1.2 用于 HTTP/1.1 和 HTTP/2
TLS 1.3用于 HTTP/3
为所有 HTTP/3 连接启用了0-RTT
地点
测试是从我在明尼苏达州的计算机到托管的三个独立数据中心进行的：
美国纽约
伦敦，英国
印度班加罗尔
客户端
我让浏览器自动连续请求同一页面 20 次，在页面加载后等待 3 秒开始下一个请求。互联网带宽连接的额定速度为 200mbps。
数据查询捕获时，计算机上没有运行其他应用程序。
HTTP/3 有多快？
美国纽约
以下是从纽约数据中心请求三个不同站点时 HTTP/2 与 HTTP/3 的响应时间：
HTTP/3 ：
小型站点快200 毫秒
内容站点快325 毫秒
单页应用程序快300 毫秒
从明尼苏达州到纽约的距离是 1,000 英里，按照网络标准来说，这是相当小的距离。重要的是，即使在相对较短的距离内，HTTP/3 也能够如此显著地提高性能。
英国伦敦
我们也在结果中包含了伦敦的 HTTP/1.1 基准测试。
为了显示 HTTP/2 和 HTTP/3 的速度有多快，我将图表保持在相同的比例。可以看到，对于内容站点，速度太慢以至于图表都填不完全！
如大家所见，当网络上的距离更远时，速度的增加更加明显。
HTTP/3 ：
小型站点快600 毫秒（与纽约相比，速度提高了3 倍）
1200ms（以上为内容网站更快的3.5倍与纽约相比的加速）
单页应用程序快1000 毫秒（与纽约相比，速度提高了3 倍以上）
印度班加罗尔
从印度的服务器加载页面时，HTTP/3 的性能改进非常明显。我们没有运行 HTTP/1.1 测试，因为它太慢了。
以下是 HTTP/2 与 HTTP/3 的结果：
当涉及更大的地域和更多的网络跃点时，HTTP/3 继续领先。也许更引人注目的是 HTTP/3 的响应时间分组的紧密程度。当数据包传输数千英里时，QUIC 会产生很大的影响。
在任何情况下，HTTP/3 都比其前协议更快！
为什么 HTTP/3 这么快？
真正的多路复用
HTTP/3 真正的多路复用特性意味着堆栈中的任何地方都不会发生行头阻塞。当从很远的地方请求资源时，在地理上数据包丢失的可能性要高得多，并且 TCP 需要重新传输这些数据包。
0-RTT 是游戏规则的改变者
此外，HTTP/3 支持O-RTT QUIC 连接，这降低了与服务器建立安全 TLS 连接所需的往返次数。
QUIC 中的 0-RTT 特性允许客户端在握手完成之前发送应用程序数据。这可以通过重用先前连接的协商参数来实现。为了实现这一点，0-RTT 依赖于客户端记住关键参数并向服务器提供 TLS 会话票证，允许服务器恢复相同的信息。
但是，不应盲目启用 0-RTT，这可能存在一些安全问题。
0-RTT 数据的安全属性弱于其他类型的 TLS 数据。具体来说：
此数据不是前向机密，因为它仅在使用提供的 PSK 派生的密钥下加密。
不保证连接之间的非重播。
今天可以使用 HTTP/3 吗？
可以！虽然该协议目前处于“Internet-Draft”状态，但已有大量现有技术实现。
我专门为这些基准测试选择了Caddy，因为 HTTP/3 可以通过一个简单的配置值在Caddy文件中。
Ninx服务器也有实验性支持，会在不久的将来正式发布HTTP/3。
像谷歌和 Facebook 这样的科技公司已经在通过 HTTP/3 服务更多的用户流量。 目前Google.com已经完全通过 HTTP/3 为现代浏览器提供服务。
对于那些在 Windows 生态系统中的人来说，据说 Windows Server 2022 将支持 HTTP/3，这需要一些复杂的步骤来启用它。
小结
HTTP/3 可以对网站的用户体验方式产生很大的影响。
站点需要的资源越多，你会看到 HTTP/3 和 QUIC 的性能改进就越大。随着HTTP/3标准离定稿越来越近，是时候开始考虑为你的网站启用它了。
一起迎接HTTP/3的时代！
编译：洛逸
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/258539.html