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”的未完全实现的应用程序激增，需要更改协议版本，以便两个通信应用程序确定彼此的真实能力。
新版本的HTTP发布还需要18年。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/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个JS文件，从2kb到100kb
- 10个图片，从1kb到50kb
- 总有效负载大小为600kb，总共20个阻塞资源
内容网站
- 50个JS文件，从2kb到1mb
- 55张图片，从1kb到1mb
- 总有效负载大小为10MB，共有105个资源（在开发工具中查看cnn.com，就会明白为什么会这么大）。
单页应用程序
- 85个JS文件，从2kb到1mb不等
- 30张图片，从1kb到50kb不等
- 总有效负载大小为15MB，共有115个资源（请在开发工具中查看JIRA）。
服务器
Caddy用于提供所有的资产和HTML。
- 所有的响应都是用Cache-Control来提供的：“no-store”，以确保浏览器每次都能重新下载。
- HTTP/1.1和HTTP/2使用了TLS 1.2。
- TLS 1.3用于HTTP/3。
- 所有的HTTP/3连接都启用了0-RTT。
测试地点
测试是在我位于明尼苏达州的电脑上进行的，测试是由Digital Ocean托管的三个独立数据中心进行的。
- 美国纽约
- 英国伦敦
- 印度班加罗尔
客户端
自动浏览器连续20次请求同一页面，在页面加载后等待3秒开始下一次请求。互联网连接的额定速率为200mbps。在采集数据时，电脑上没有其他应用程序在运行。
那么HTTP/3有多快？
美国纽约
以下是从纽约数据中心请求三个不同站点时HTTP/2与HTTP/3的响应时间：
HTTP/3是：
- 小型网站速度200ms
- 内容网站的速度为325ms
- 单页应用程序的速度为300毫秒
从明尼苏达州到纽约的距离是1000英里，这在网络标准中是相当小的。重要的是，即使在一个相对较短的距离上，HTTP/3也能将性能提高这么多。
英国伦敦
在结果中也包括了伦敦的HTTP/1.1基准运行。为了显示HTTP/2和HTTP/3的速度有多快，把图表保持在同一比例。你可以看到，对于内容网站来说，时间是非常慢的，甚至无法完全在图上显示出来。
正如所看到的，当网络上的距离越远时，速度的提高就越明显。 HTTP/3是：
- 小型网站的速度为600ms（与纽约相比，速度提高了3倍）
- 内容网站的速度为1200ms（与纽约相比，速度提高了3.5倍以上）
- 单页应用程序的速度为1000ms（与纽约相比，速度提高了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数据。具体来说：
- 1.此数据不是前向机密，因为它仅在使用提供的PSK派生的密钥下加密。
- 2.不保证连接之间不重放。
现在可以使用HTTP/3吗？
虽然该协议目前处于标准化状态，但也有很多现有的实现。
专门为这些基准选择了Caddy，因为HTTP/3可以通过Caddyfile中的简单配置值启用NGINX也具有实验性支持，并且正在努力在不久的将来发布官方HTTP/3。
NGINX 也有实验性支持，并正在努力在不久的将来发布官方HTTP/3版本。
像Google和Facebook这样的大型科技公司已经通过HTTP/3为他们的流量提供服务。Google已经完全通过HTTP/3为现代浏览器提供服务。
对于那些在Windows生态系统中的人来说，据说Windows Server 2022将支持HTTP/3，但需要一些步骤才能启用它。
结论
HTTP/3 可以对网站的用户体验方式产生重大影响。一般来说，站点需要的资源越多，会发现HTTP/3和QUIC的性能提升就越大。随着HTTP/3标准最终确定，是时候开始考虑为你的网站启用它了。
原文链接：https://requestmetrics.com/web-performance/http3-is-fast
---煤油灯科技victorlamp.com翻译整理---
