HTTP/2：显着提升网页加载速度的网络协议
核心要点：
HTTP协议的演进：
互联网的基础架构——或物理网络层——之上是互联网协议（作为TCP/IP或传输层的一部分）。它是我们大多数互联网通信的基础架构。
在其之上是应用层，各种应用程序使用不同的协议来连接和传输信息。例如，我们有用于发送和接收电子邮件的SMTP、POP3和IMAP；用于聊天的IRC和XMPP；用于远程服务器访问的SSH等等。
其中最著名的协议，也是互联网使用的代名词，是HTTP（超文本传输协议）。我们每天都使用它来访问网站。它早在1989年就由蒂姆·伯纳斯·李在CERN设计出来。 1.0版本的规范于1996年发布（RFC 1945），1.1版本于1999年发布。
HTTP规范由万维网联盟维护，可以在https://www.w3.org/standards/techs/HTTP找到。
第一代HTTP协议（1.0和1.1版本）主导了互联网直到2015年，HTTP/2发布后，行业（Web服务器和浏览器厂商）才开始采用它。
HTTP/1.1的局限性：
HTTP是一个无状态协议，基于请求-响应结构，这意味着客户端向服务器发出请求，这些请求是原子的：任何单个请求都不知道之前的请求。 （这就是为什么我们使用cookie——例如，为了在一个用户会话中连接多个请求，以便能够向已登录用户提供网站的已认证版本）。
传输通常由客户端（用户的浏览器）启动，服务器通常只响应这些请求。
可以说，当前的HTTP状态相当“笨拙”，或者更确切地说，是低级的，需要为浏览器和服务器提供大量“帮助”，以说明如何有效地进行通信。在这个领域进行更改并非易事，因为许多现有网站的功能依赖于与任何引入的更改的向后兼容性。任何旨在改进协议的操作都必须以不会中断互联网的无缝方式进行。
在许多方面，这种严格的请求-响应、原子、同步模型已经成为瓶颈，而进展主要采取了黑客的形式，通常由谷歌、Facebook等行业领导者牵头。通常的情况（正在以各种方式改进）是访问者请求一个网页，当他们的浏览器从服务器接收它时，它会解析HTML并找到渲染页面所需的其它资源，如CSS、图像和JavaScript。当它遇到这些资源链接时，它会停止加载所有其他内容，并向服务器请求指定的资源。在收到此资源之前，它不会移动分毫。然后它请求另一个资源，依此类推。
世界顶级网站加载所需的请求数量通常在数百个。
这包括大量的等待时间，以及许多往返时间，在此期间，访问者只能看到白屏或半渲染的网站。这些都是浪费的几秒钟。在这些请求周期中，大量可用的带宽只是闲置未使用。
CDN可以减轻很多这些问题，但它们也只是权宜之计。
正如Mozilla的Daniel Stenberg（参与HTTP/2标准化的人员之一）所指出的那样，该协议的第一个版本很难充分利用底层传输层TCP的容量。一直致力于优化网站加载速度的用户知道，这通常需要一些创造力，委婉地说。
随着时间的推移，互联网带宽速度大幅提高，但HTTP/1.1时代的基础设施并没有充分利用这一点。它仍然难以应对诸如HTTP流水线——通过相同的TCP连接推送更多资源——等问题。浏览器中的客户端支持拖后腿最多，Firefox和Chrome默认情况下禁用它，或者根本不支持它，例如IE、Firefox 54 版本等。这意味着即使是很小的资源也需要打开一个新的TCP连接，以及随之而来的所有膨胀——TCP握手、DNS查找、延迟……由于队首阻塞，一个资源的加载会导致阻止所有其他资源的加载。
同步非流水线连接与流水线连接的对比，显示了可能的加载时间节省。
在HTTP/1模型下，Web开发人员必须采用的一些优化技巧来优化他们的网站包括图像精灵、CSS和JavaScript连接、分片（将访问者的资源请求分布到多个域或子域）等等。
改进是必要的，它必须以一种无缝的、向后兼容的方式解决这些问题，以免中断现有Web的工作。
SPDY和HTTP/2：
2009年，谷歌宣布了一个项目，该项目将成为新一代协议SPDY（发音为speedy）的草案提案，为Chrome添加支持，并在随后几年将其推向其所有Web服务。随后，Twitter和Apache、nginx等服务器厂商也提供了支持，Node.js，后来还有Facebook、WordPress.com和大多数CDN提供商。
SPDY引入了多路复用——通过单个TCP连接并行发送多个资源。连接默认加密，数据被压缩。首先，SPDY白皮书中对前25个网站进行的初步测试显示，速度提高了27%到60%以上。
在生产环境中证明其有效性后，SPDY 3版成为2015年超文本传输协议工作组httpbis制定的HTTP/2第一个草案的基础。
HTTP/2旨在通过以下方式解决困扰第一版协议的延迟问题：
它还旨在解决队首阻塞问题。它传输的数据采用二进制格式，提高了效率，并且默认需要加密（或者至少，这是主流浏览器施加的要求）。
头部压缩使用HPACK算法执行，解决了SPDY中的漏洞，并将Web请求大小减少了一半。
服务器推送是旨在解决浪费的等待时间的特性之一，它在浏览器请求之前向浏览器的服务器提供资源。这减少了往返时间，这是网站优化的一个主要瓶颈。
由于所有这些改进，HTTP/2带来的加载时间差异可以在imagekit.io的示例页面上看到。
加载时间的节省越多的网站资源越明显。
如何查看网站是否通过HTTP/2提供资源：
在Firefox或Chrome等主流浏览器中，我们可以在检查器工具中检查网站对HTTP/2协议的支持，方法是打开“网络”选项卡，然后右键单击资源列表上方的条带。在这里，我们可以启用“协议”项。
服务器端实现：
截至撰写本文时，所有主流浏览器都支持HTTP/2，尽管需要对所有HTTP/2请求进行加密，而HTTP/2规范本身并不需要加密。
Apache 2.4通过其mod_http2模块支持它，该模块现在应该已经可以投入生产了。Apache需要通过向./configure命令添加--enable-http2参数来构建它。我们还需要确保至少安装了1.2.1版本的libnghttp2库。如果系统难以找到它，我们可以通过添加--with-nghttp2=
下一步是通过将指令添加到Apache的配置中来加载模块：
<code>LoadModule http2_module modules/mod_http2.so</code>
然后，我们将Protocols h2 h2c http/1.1添加到我们的虚拟主机块并重新加载服务器。Apache的文档警告我们启用HTTP/2时的注意事项：
在您的Apache服务器上启用HTTP/2会影响资源消耗，如果您有一个繁忙的站点，您可能需要仔细考虑其影响。
启用HTTP/2后，首先要注意的是您的服务器进程将启动额外的线程。原因是HTTP/2将其接收到的所有请求都交给其自己的工作线程进行处理，收集结果并将它们流式传输到客户端。
您可以在这里阅读更多关于Apache配置的信息。
nginx从1.9.5版本开始就支持HTTP/2，我们只需将http2参数添加到我们的虚拟主机规范中即可启用它：
<code>server {
listen 443 ssl http2 default_server;
ssl_certificate server.crt;
ssl_certificate_key server.key;</code>然后重新加载nginx。
不幸的是，截至撰写本文时，服务器推送尚未正式实现，但它已被添加到开发路线图中，计划于明年发布。对于更具冒险精神的人来说，有一个非官方的nginx模块可以添加对HTTP/2服务器推送的支持。
LiteSpeed和OpenLiteSpeed也吹嘘支持HTTP/2。
在服务器端激活HTTP/2之前的一个注意事项是确保我们有SSL支持。这意味着我们上面提到的所有虚拟主机代码段——对于Apache和nginx——都需要进入SSL版本的虚拟主机块，监听443端口。一旦我们安装了Apache或nginx，并且我们已经配置了常规虚拟主机，获取LetsEncrypt SSL证书并在任何主要Linux发行版上安装它应该只是几行代码的问题。Certbot是一个命令行工具，可以自动化整个过程。
总结：
在本文中，我简要概述了HTTP/2，这是一个新兴的第二代Web协议规范。
可以在此处找到新一代HTTP的完整实现列表。
对于不太懂技术的人来说，过渡到这个新协议的捷径可能是简单地在Web堆栈中实现CDN，因为CDN是最早采用HTTP/2的厂商之一。
HTTP/2常见问题解答：
（此处省略FAQ部分，因为与之前的输出内容高度重复）
以上是HTTP/2：背景，绩效优势和实施的详细内容。更多信息请关注PHP中文网其他相关文章！
