HTTP/2：背景、性能和实现
作为TCP/IP或传输层的一部分，internet协议位于internet基础结构(或物理网络层)之上。它是我们所有或大部分互联网通信的基础。
我们在上面使用的一个更高层次的协议层是应用层。在这个级别上，各种应用程序使用不同的协议来连接和传输信息。我们有SMTP、POP3和IMAP用于发送和接收电子邮件，IRC和XMPP用于聊天，SSH用于远程服务器访问，等等。
其中最著名的协议是HTTP（超文本传输协议），它已经成为了使用互联网的同义词。这就是我们每天访问网站的方式。它是由蒂姆伯纳斯-伯纳斯于1989年在CERN设计的。1.0版本的规范发布于1996年(RFC 1945)， 1.1发布于1999年。
HTTP规范由万维网联盟维护，可以在http://www.w3.org/standards/techs/HTTP找到。
这个协议的第一代——版本1和1.1——在2015年之前一直统治着网络，直到HTTP/2发布，网络服务器和浏览器供应商开始采用它。
HTTP / 1
HTTP是一种无状态协议，基于请求-响应结构，这意味着客户机向服务器发出请求，而这些请求是原子的:任何单个请求都不知道之前的请求。(这就是我们使用cookie的原因——在一个用户会话中连接多个请求之间的鸿沟，例如，能够为登录用户提供经过验证的网站版本。)
传输通常由客户端发起(即用户的浏览器)，而服务器通常只响应这些请求。
我们可以说，HTTP的当前状态是相当“愚蠢”的，或者更好的，低层次的，有很多“帮助”需要给予浏览器和服务器关于如何有效通信的帮助。这个领域的变化并不是那么简单，因为有这么多的现有网站，它们的功能依赖于与任何引入的变更的向后兼容性。
在许多方面，当前的这种严格的请求-响应、原子的、同步的模型的模式已经变成了瓶颈。以各种方式被改进，是为了访问者请求网页，并且当他们的浏览器从服务器接收到web页面时，它就解析HTML并找到呈现页面所需的其他资源，如CSS、图像和JavaScript。当它遇到这些资源链接时，它停止加载其他所有内容，并从服务器请求指定的资源。它不会进行任何响应，直到接收到这个资源。然后它请求另一个，以此类推。
加载世界上最大的网站所需的请求数通常是几百个。
这包括大量的等待，以及许多往返的行程，在此期间，我们的访客只看到一个白色的屏幕或半渲染的网站。这些都是浪费的时间。在这些请求周期中，许多可用的带宽都是闲置的。
正如Mozilla的Daniel Stenberg(致力于HTTP/2标准化的人之一)所指出的，协议的第一个版本很难充分利用底层传输层TCP的容量。
一直致力于优化网站加载速度的用户知道，说得婉转些，这通常需要一些创造力。
随着时间的推移，internet带宽速度急剧增加，但是HTTP/1.1时代的基础设施并没有充分利用这一点。它仍然在处理HTTP管道之类的问题——在相同的TCP连接上推送更多的资源。浏览器中的客户端支持被拖得最久，Firefox和Chrome默认禁用它，或者根本不支持它，比如IE, Firefox 54+等等。
这意味着，即使是很小的资源也需要打开一个新的TCP连接，所有的bloat都与它一起——TCP握手、DNS查找、延迟……而且由于头行阻塞，一个资源的加载导致了阻塞所有其他资源的加载。
同步的，非管道连接与一种管道连接，在加载时间显示可能的节省。
一些优化的web开发人员不得不求助于HTTP/1模型，以优化他们的网站，包括图像精灵、CSS和JavaScript级联、分片(分配访问者对多个域或子域的资源的请求)，等等。
改进是应该的，它必须以无缝的、向后兼容的方式解决这些问题，以免中断现有web的工作。
SPDY
2009年，谷歌宣布了一个项目，该项目将成为新一代协议SPDY(发音为speed)的草案，它将为Chrome增加支持，并在随后几年将其推广到所有的web服务中。然后关注Twitter和服务器供应商，如Apache, nginx，以及他们的支持，Node。后来出现了Facebook、WordPress.com和大多数CDN提供商。
SPDY引入了多路复用——通过一个TCP连接并行地发送多个资源。默认情况下，连接是加密的，数据是压缩的。首先，在前25个网站上进行的SPDY白皮书的初步测试显示，速度从27%提高到60%以上。
SPDY version 3在生产中得到验证后，成为2015年超文本传输协议工作组httpbis制作的HTTP/2初稿的基础。
HTTP/2的目标是解决第一个版本的协议延迟问题:
- 压缩HTTP标头
- 实现服务器推送
- 在单个连接上多路复用请求。
它还旨在解决网络前端阻塞问题。它传输的数据是二进制格式的，这提高了它的效率，并且它需要默认的加密(或者至少，这是主要浏览器的要求)。
头压缩采用HPACK算法，解决了SPDY中的漏洞，将web请求大小减少了一半。
服务器推送是解决等待时间浪费的特性之一，它在浏览器需要资源之前将资源提供给访问者的浏览器。这减少了往返时间，是网站优化的一大瓶颈。
由于所有这些改进，可以在imagekit.io的示例页面上看到HTTP/2带来的加载时间差异。
一个网站拥有的资源越多，加载时间的节省就越明显。
如何查看网站是否通过HTTP/2提供资源
在Firefox或Chrome等主流浏览器中，我们可以在inspector工具中打开Network选项卡，右键单击参考资料列表上的条带，查看网站对HTTP/2协议的支持。这里我们可以启用协议项。
GIF
另一种方法是安装一个基于javascript的小工具，它允许我们通过命令行检查HTTP/2支持(假设我们有node.js和npm):
npm install -g is-HTTP2-cli
58/5000
安装之后，我们应该可以这样使用:
is-HTTP2 www.google.com✓ HTTP/2 supported by www.google.comSupported protocols: grpc-exp h2 HTTP/1.1
实现
在编写本文时，所有主要浏览器都支持HTTP/2，尽管要求对所有HTTP/2请求进行加密，而HTTP/2规范本身并不需要加密。
服务器
Apache 2.4可以用它的mod_HTTP2模块来支持,这个模块现在已经可以使用。Apache需要通过向./configure命令添加—enable-HTTP2参数来构建它。我们还需要确保至少安装了libngHTTP2库的1.2.1版本。在系统找不到的情况下，我们可以通过添加-- nghttp2 =来提供./configure的路径。
下一步是通过将指令添加到Apache的配置中来加载模块:
/ mod_HTTP2.so LoadModule HTTP2_module模块
然后，我们将协议h2 h2c HTTP/1.1添加到虚拟主机块并重新加载服务器。Apache的文档警告我们在启用HTTP/2时注意事项:
在Apache服务器上启用HTTP/2会影响资源消耗，如果站点繁忙，可能需要仔细考虑其影响。
启用HTTP/2之后的第一件值得注意的事情是，您的服务器进程将启动额外的线程。原因是HTTP/2将它收到的所有请求都发送给自己的工作线程进行处理，收集结果并将它们发送给客户端。
您可以阅读更多关于Apache配置的信息。
nginx从1.9.5版本开始就支持HTTP/2，我们只需将http2参数添加到我们的虚拟主机规范中:
server { listen 443 ssl http2 default_server; ssl_certificate server.crt; ssl_certificate_key server.key;
然后重新加载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的完整实现列表。
对于不太精通技术的人来说，向这个新协议过渡的最短路径可能是将CDN简单地实现到web技术栈中，因为CDNs是HTTP/2最早的采用者之一。