2.6 HTTP/2对Web性能的影响

对于HTTP/1固有的性能问题，现在有了解决方案，那就是HTTP/2。但是，HTTP/2能解决所有的Web性能问题吗？如果将网站升级到HTTP/2，能有多快？

2.6.1 展示HTTP/2能力的绝佳示例

从很多例子都能看出来HTTP/2所带来的性能提升。笔者的网站https://www.tunetheweb.com/performance-test-360/也是一个例子。这个页面支持HTTP/1.1、基于HTTP/1.1的HTTPS，以及基于HTTPS的HTTP/2。就像第3章中所说，浏览器仅支持基于HTTPS的HTTP/2，所以没有不基于HTTPS的HTTP/2测试。这个测试源自于另外一个类似的测试，https://www.httpvshttps.com/，该测试排斥仅支持HTTPS（不支持HTTP/2）的场景，并且会加载360张图片。本测试使用一些JavaScript代码来记录加载时间。结果如图2.18所示。

测试显示，HTTP需要用10.471 s加载页面和所有的图片资源。HTTPS需要差不多相同的时间，10.533 s。这说明HTTPS并不会带来明显的性能下降，和纯文本的HTTP相比，这几乎可以忽略不计。实际上，重新跑几次测试，你会发现HTTPS会比HTTP略微快一些，这没什么意义（因为HTTPS会比HTTP多一些操作），这些额外的操作在误差范围内。

真正令人惊喜的是HTTP/2，页面在1.731s内就加载完成——比另外两种技术快了83％！原因就在下面的瀑布图里。对比观察图2.19（HTTPS）和图2.20（HTTP/2）。

在HTTPS下，我们看到了熟悉的延迟。要创建多个连接，6个一组地加载图片。在HTTP/2下情况不一样，图片是同时请求的，所以没有延迟。为简洁起见，这里只展示前21个请求，而不是全部的360个。但这两张图已经充分说明了HTTP/2给此类网站带来的巨大性能提升。注意，在图2.19中，页面最大连接数用完之后，在请求10中，浏览器开始加载Google Analytics。该请求的域名不同，它还没达到最大连接数。图2.20展示了更高的同时请求数，所以开始请求更多的图片，Google Analytics的请求没在前21个请求中，在瀑布图的后面。

聪明的读者会发现，在HTTP/2中每个图片下载的时间变长了，需要大约490 ms，而在HTTP/1.1中只要115 ms左右（不考虑前6个，包括建立连接的时间）。静态资源加载的时间在HTTP/2下会显得更长，这是因为衡量的方式不同。瀑布图一般用发出请求的时间和收到响应的时间来计算，不考虑排队的时间。以请求16为例，在HTTP/1下，这个资源在1.2 s处才开始请求，在大约1.318 s时完成，耗时118 ms。然而，浏览器在处理完HTML时就知道它需要这张图片，所以第一个图片请求在0.75 s时就发出去了，这正是在HTTP/2下浏览器开始请求同一个图片的时间（不要把这当成巧合）。所以，这个0.45 s的延迟并没有在瀑布图中显示出来，因此，在瀑布图中应该从0.75 s开始计时。如2.4.2节所示，Chrome的瀑布图包含等待时间，所以它显示了真正的资源下载时间，比HTTP/2下要长。

然而，由于带宽、客户端和服务器的性能原因，在HTTP/2下请求可能会需要更长的时间。在HTTP/1下对多连接的使用，自然就形成了请求排队机制，因为同时只有6个请求。HTTP/2以流的形式，只使用一个连接，在理论上没有同时只能发送6个请求的限制，但具体的实现不受约束，可以添加其他限制。例如Apache，我用它来托管本页面，默认一个连接上只能有100个并发请求。同时发送的多个请求会共享资源，需要很长的下载时间。在图2.20中，图片下载的时间越来越长（第4行的282 ms到第25行的301 ms）。在图2.21中，第88～120行中的结果一样。可以看到，图片请求需要用720 ms时间（是HTTP/1下的6倍）。同时，当到了100个请求的限制时，会暂停一段时间，等第一个请求下载完成，然后剩余的请求才开始。这个情况和HTTP/1下因为连接数限制所形成的瀑布图一样，但是出现的更少，更晚，因为这相当于连接数限制被大幅度提高了。还要说的是，在这个暂停中，Google Analytics发出了请求（请求104）。和图2.19中HTTP/1.1下的情况类似，但是在HTTP/1.1中发生得更早，到第10个请求就发生了。

你在查看HTTP/2下的瀑布图时，很容易错过关键的一点，即HTTP/1和HTTP/2的请求时间本质上衡量的是不同的东西，应该查看整体时间。在这里，我们考虑整个页面的加载时间，很明显HTTP/2胜出。

2.6.2 对HTTP/2提升性能的期望

2.6.1节中的示例显示了HTTP/2可能给网站带来的巨大改善，83％的性能提升非常可观。但这个示例显示的并不是真实的情况，大多数网站都不会有这么大的改善。这个示例只是HTTP/2表现最好的情况（这也是我在本书中更倾向于使用广为人知的真实案例的另一个原因）。如果网站还有其他性能问题，那么切换到HTTP/2后可能看不到任何性能提升，这也意味着HTTP/1.1的低效率对这些网站来说问题不大。

对于一些网站，还有两个原因会导致使用HTTP/2没什么改善。第一个原因是这些网站已经优化得足够好了——使用2.2节中提到的变通办法，由HTTP/1带来的缓慢问题比较少。但是就算经过充分优化的网站也会受这些技术的性能缺陷的影响，更不用说要还要花大力气来应用和维护这些技术。从理论上讲，只要支持HTTP/2，网站可以轻易获得性能提升，不需要再使用域名分片、CSS合并、JavaScript合并、精灵图等技术。

另外一个使用HTTP/2可能不会提升网站性能的原因是，其他的性能问题远超HTTP/1带来的影响。很多网站有印刷质量的高清图片，需要花很长时间来加载。有网站加载太多的JavaScript，这也需要时间来下载（使用HTTP/2可能会有帮助）和执行（HTTP/2帮不上什么忙）。那种在加载完成之后还是很慢，或者反应迟顿（比如用户滚动时响应慢）的网站，HTTP/2无法优化，HTTP/2只解决网络性能。另外，让HTTP/2变慢的其他情况还是网络丢包，第9章中会讲。

说了这么多，我坚信HTTP/2将给网站带来更高的性能，并且会减少现在站长们对一些复杂的变通方法的需求。与此同时，对HTTP/2可以解决的问题和不能解决的问题，HTTP/2倡导者必须要有预期；否则，当你将网站迁移到HTTP/2后只会感到失望，不会立即看到巨大的性能提升。在撰写本书时，人们可能处于夸大预期的高峰期（有人可能熟悉Gartner炒作周期）[26]，并且在实际应用之前，人们会寄希望于新技术解决所有问题。网站需要了解自己的性能问题，而HTTP/1的瓶颈只是造成性能问题的一个因素。但是，根据我的经验，传统的网站在迁移到HTTP/2时性能会有良好的提升，HTTP/2比HTTP/1慢得多的情况非常罕见（但不是不可能）。其中一个例子是跟带宽关联较大的网站（例如，有许多高清图片的网站），在HTTP/2下因为其使用自然排序可能会变慢。而使用HTTP/1.1，只开启有限的连接数，那么关键资源将会更快下载，看起来也就更快。一家图形设计公司发布了一个有趣的案例[27]，但是即使是这个案例也可以通过正确地调整HTTP/2来优化，如第7章所述。

回到现实的案例，我做了亚马逊网站的副本，将所有的外部引用变成了本地引用，通过HTTP/1和HTTP/2（都是HTTPS）加载页面，并测量了不同的加载时间，结果如表2.2所示。

此表引用了网络性能圈子中常见的一些术语：

• 加载时间指页面发起onload事件的时间 —— 通常指所有的CSS和阻塞式JavaScript加载完成的时间。

• 首字节时间指从网站收到第一个字节的时间。通常，此响应是第一个真正的响应，不是重定向。

• 开始渲染时间指页面开始绘制的时间。此指标是一项关键性能指标，因为如果用户没有看到正在访问的页面有更新，他们可能会离开。

• 视觉完整时间指页面停止变化的时间，通常在初始加载时间之后很久，异步的JavaScript可能还在更新页面。

• speed index为由WebPagetest计算的页面每部分加载的平均时间，以ms为单位。[28]

在这个示例中，HTTP/2下的这些指标大多都表现更好。首字节时间略有恶化，但重复测试显示某些测试的情况正好相反，因此该结果看起来在误差范围内。

但我承认，这些改进有点像人造的，因为我没有像Amazon那样完全实现网站。我只使用了一个域（因此没有发生域分片），并将每个资源保存为静态文件而不是像Amazon那样动态生成，动态生成的内容可能增加其他延迟。但是，在HTTP/1和HTTP/2版本的测试中都没有做这些操作，因此，可以看到HTTP/2的明显改进。

比较图2.22和图2.23中两次加载之间的瀑布图，可以看到HTTP/2下的预期改进：当需要许多资源时，在开始时没有额外的连接，也没那么多阶梯式的瀑布加载。

对于两种请求类型，在网站上没有更改代码；这只是由HTTP/2引起的改进。由于Web资源互相依赖，因此在HTTP/2下加载站点仍然存在瀑布，例如，网页加载CSS、CSS加载图像。但HTTP/2没有浪费时间来建立连接和排队，因此就没有因为HTTP约束导致的瀑布效应。具体减少的时间数字可能看起来很小，但是它的比例是22％，这是一个巨大的提升，特别是考虑到这种改进不需要在Web服务器之外进行任何更改时。

真正针对HTTP/2优化，并使用其中一些新功能（我将在本书后面介绍）的网站应该会得到更大的收益。当前，对于优化HTTP/1网站，我们拥有20年的经验，但几乎没有优化HTTP/2的经验。

当我使用Amazon这个知名网站作为示例时，它尚未迁移到HTTP/2，并且针对HTTP/1进行了深度优化（尽管不完美！）。要明确指出的是，我并不是要说明Amazon的编码错误或它不符合规定，我只是在展示HTTP/2可能立即为网站带来的性能改进。也许更重要的是，不必执行HTTP/1.1变通方法就可能获得卓越的性能，从而节省工作量。

在我完成本章内容之后，Amazon已经支持HTTP/2了，它也获得了一些性能提升。但还要说明的是，Amazon作为现实世界中复杂网站的一个例子，尽管它已经进行了一些HTTP/1性能优化，但仍然可以通过HTTP/2得到显著改善。

2.6.3 HTTP/1.1的一些性能变通方法可能是反模式

因为HTTP/2修复了HTTP/1.1中的性能问题，理论上，不再需要部署本章中讨论的性能解决方法。事实上，许多人认为这些变通办法正在成为HTTP/2世界的反模式，因为它们可能会降低使用HTTP/2的效果。例如，如果网站使用域名分片并强制使用多个连接（第6章讨论了旨在解决此问题的连接合并），则无法享受使用单个TCP连接加载网站带来的性能提升。HTTP/2使得在默认情况下创建一个高性能网站变得更加简单。

然而，事实并非如此简单，正如后面的章节（特别是第6章）中要讲的，在HTTP/2的应用更加广泛之前，完全放弃这些技术可能为时尚早。在客户端，尽管有强大的浏览器支持，一些用户仍会使用HTTP/1.1。他们可能正在使用较旧的浏览器，或通过尚不支持HTTP/2的代理（包括防病毒扫描程序和公司代理）进行连接。

此外，在客户端和服务端，实现仍在变化，人们也在学习如何最好地应用这个新协议。在HTTP/1.1推出的20年中，网络性能优化行业在蓬勃地发展，开发人员学会了如何最好地针对HTTP协议优化他们的网站。虽然我希望HTTP/2不要像HTTP/1.1那样需要那么多的优化，并且它应该不费吹灰之力就能提供HTTP/1.1优化所能提供的性能。开发人员仍然还在摸索这个新的协议，毫无疑问，他们还要学习一些最佳实践和技术。

现在，你可能希望启动并运行HTTP/2。在第3章中，我们学习如何操作。之后回到性能优化，了解如何衡量改进，并充分利用HTTP/2。本章先让你了解HTTP/2可以为Web带来什么，希望以此激发你对在网站上部署HTTP/2的兴趣。