:style 设置背景图_HTTP / 2：背景，性能优势和实现

:style 设置背景图

On top of the infrastructure of the internet — or the physical network layers — sits the Internet Protocol, as part of the TCP/IP, or transport layer. It’s the fabric underlying all or most of our internet communications.

Internet协议位于Internet基础结构(或物理网络层)的顶部，它是TCP / IP或传输层的一部分。 它是我们所有或大多数Internet通信的基础。

A higher level protocol layer that we use on top of this is the application layer. On this level, various applications use different protocols to connect and transfer information. We have SMTP, POP3, and IMAP for sending and receiving emails, IRC and XMPP for chatting, SSH for remote sever access, and so on.

在此之上使用的更高层协议层是应用程序层 。 在此级别上，各种应用程序使用不同的协议来连接和传输信息。 我们有用于发送和接收电子邮件的SMTP，POP3和IMAP，用于聊天的IRC和XMPP，用于远程服务器访问的SSH等。

The best-known protocol among these, which has become synonymous with the use of the internet, is HTTP (hypertext transfer protocol). This is what we use to access websites every day. It was devised by Tim Berners-Lee at CERN as early as 1989. The specification for version 1.0 was released in 1996 (RFC 1945), and 1.1 in 1999.

在这些协议中，最知名的协议已成为Internet使用的代名词，它是HTTP(超文本传输​​协议)。 这就是我们每天用来访问网站的方式。 它是由CERN的Tim Berners-Lee于1989年设计的。1.0版的规范于1996年发布(RFC 1945)，1999年发布为1.1版。

The HTTP specification is maintained by the World Wide Web Consortium, and can be found at https://www.w3.org/standards/techs/HTTP.

HTTP规范由万维网联盟维护，可以在https://www.w3.org/standards/techs/HTTP上找到。

The first generation of this protocol — versions 1 and 1.1 — dominated the web up until 2015, when HTTP/2 was released and the industry — web servers and browser vendors — started adopting it.

该协议的第一代(版本1和1.1)一直主导着网络，直到2015年HTTP / 2发布，业界(网络服务器和浏览器供应商)开始采用该协议。

HTTP / 1 (HTTP/1)

HTTP is a stateless protocol, based on a request-response structure, which means that the client makes requests to the server, and these requests are atomic: any single request isn’t aware of the previous requests. (This is why we use cookies — to bridge the gap between multiple requests in one user session, for example, to be able to serve an authenticated version of the website to logged in users.)

HTTP是基于请求-响应结构的无状态协议，这意味着客户端向服务器发出请求，并且这些请求是原子的：任何单个请求都不知道先前的请求。 (这就是我们使用Cookie的原因-例如，在一个用户会话中弥合多个请求之间的间隔，以便能够为登录的用户提供经过身份验证的网站版本。)

Transfers are typically initiated by the client — meaning the user’s browser — and the servers usually just respond to these requests.

传输通常由客户端(即用户的浏览器)启动，服务器通常仅响应这些请求。

We could say that the current state of HTTP is pretty “dumb”, or better, low-level, with lots of “help” that needs to be given to the browsers and to the servers on how to communicate efficiently. Changes in this arena are not that simple to introduce, with so many existing websites whose functioning depends on backward compatibility with any introduced changes. Anything being done to improve the protocol has to be done in a seamless way that won’t disrupt the internet.

我们可以说HTTP的当前状态相当“愚蠢”，或者更好，是低级的，需要向浏览器和服务器提供许多“帮助”，以帮助他们进行有效的通信。 在这个领域中进行更改并不是那么容易引入，因为许多现有网站的功能取决于向后兼容任何所引入的更改。 为改进协议所做的任何事情都必须以无缝方式完成，并且不会破坏互联网。

In many ways, the current model has become a bottleneck with this strict request-response, atomic, synchronous model, and progress has mostly taken the form of hacks, spearheaded often by the industry leaders like Google, Facebook etc. The usual scenario, which is being improved on in various ways, is for the visitor to request a web page, and when their browser receives it from the server, it parses the HTML and finds other resources necessary to render the page, like CSS, images, and JavaScript. As it encounters these resource links, it stops loading everything else, and requests specified resources from the server. It doesn’t move a millimeter until it receives this resource. Then it requests another, and so on.

在许多方面，当前模型已成为这种严格的请求-响应，原子，同步模型的瓶颈，并且进展主要采取黑客的形式，通常由Google，Facebook等行业领导者带头。正在以各种方式进行改进，以供访问者请求网页，并且当他们的浏览器从服务器接收到网页时，它会解析HTML并找到呈现网页所需的其他资源，例如CSS，图像和JavaScript。 遇到这些资源链接时，它将停止加载其他所有内容，并从服务器请求指定的资源。 在收到此资源之前，它不会移动一毫米。 然后它请求另一个，依此类推。

The number of requests needed to load world’s biggest websites is often in couple of hundreds.

加载世界上最大的网站所需的请求数通常为数百。

This includes a lot of waiting, and a lot of round trips during which our visitor sees only a white screen or a half-rendered website. These are wasted seconds. A lot of available bandwidth is just sitting there unused during these request cycles.

这包括大量等待和大量往返，在此期间我们的访问者只能看到白色的屏幕或呈现一半的网站。 这些浪费了几秒钟。 在这些请求周期中，许多可用带宽就闲置在那里。

CDNs can alleviate a lot of these problems, but even they are nothing but hacks.

CDN可以缓解许多此类问题，但是即使它们只是黑客。

As Daniel Stenberg (one of the people working on HTTP/2 standardization) from Mozilla has pointed out, the first version of the protocol is having a hard time fully leveraging the capacity of the underlying transport layer, TCP. Users who have been working on optimizing website loading speeds know this often requires some creativity, to put it mildly.

正如Mozilla的Daniel Stenberg(从事HTTP / 2标准化工作的人之一) 所指出的那样 ，该协议的第一个版本很难充分利用基础传输层TCP的容量。 一直在努力优化网站加载速度的用户知道，这通常需要一些创造力。

Over time, internet bandwidth speeds have drastically increased, but HTTP/1.1-era infrastructure didn’t utilize this fully. It still struggled with issues like HTTP pipelining — pushing more resources over the same TCP connection. Client-side support in browsers has been dragging the most, with Firefox and Chrome disabling it by default, or not supporting it at all, like IE, Firefox version 54+, etc. This means that even small resources require opening a new TCP connection, with all the bloat that goes with it — TCP handshakes, DNS lookups, latency… And due to head-of-line blocking, the loading of one resource results in blocking all other resources from loading.

随着时间的流逝，Internet带宽速度急剧增加，但是HTTP / 1.1时代的基础架构并未充分利用这一点。 它仍然在诸如HTTP流水线之类的问题上苦苦挣扎-通过同一个TCP连接推送更多资源。 浏览器中的客户端支持受到的拖累最大，Firefox和Chrome默认情况下将其禁用，或者根本不支持它，例如IE，Firefox 54+等。这意味着即使很小的资源也需要打开新的TCP连接，随之而来的是所有的膨胀-TCP握手，DNS查找，延迟...，并且由于行头阻塞 ，一种资源的加载导致所有其他资源的加载受到阻碍。

A synchronous, non-pipelined connection vs a pipelined one, showing possible savings in load time.

同步，非流水线连接与流水线连接相比，表明可以节省加载时间。

Some of the optimization sorcery web developers have to resort to under the HTTP/1 model to optimize their websites include image sprites, CSS and JavaScript concatenation, sharding (distributing visitors’ requests for resources over more than one domain or subdomain), and so on.

Web上的一些优化魔术师必须依靠HTTP / 1模型来优化其网站，包括图像精灵 ，CSS和JavaScript串联，分片(将访问者对资源的请求分配到多个域或子域中)等。 。

The improvement was due, and it had to solve these issues in a seamless, backward-compatible way so as not to interrupt the workings of the existing web.

改进是必须的，它必须以一种无缝的，向后兼容的方式解决这些问题，以免中断现有Web的运行。

斯派迪 (SPDY)

In 2009, Google announced a project that would become a draft proposal of a new-generation protocol, SPDY (pronounced speedy), adding support to Chrome, and pushing it to all of its web services in subsequent years. Then followed Twitter and server vendors like Apache, nginx with their support, Node.js, and later came Facebook, WordPress.com, and most CDN providers.

2009年，Google宣布了一个项目，该项目将成为新一代协议SPDY (发音为speedy )的提案草案，为Chrome提供更多支持，并在随后的几年内将其推向所有Web服务。 然后是Twitter和服务器供应商，例如Apache，nginx及其支持，Node.js，后来出现了Facebook，WordPress.com和大多数CDN提供商。

SPDY introduced multiplexing — sending multiple resources in parallel, over a single TCP connection. Connections are encrypted by default, and data is compressed. First, preliminary tests in the SPDY white paper performed on the top 25 sites showed speed improvements from 27% to over 60%.

SPDY引入了多路复用 -通过单个TCP连接并行发送多个资源。 默认情况下，连接被加密，并且数据被压缩。 首先，在SPDY白皮书中对前25个站点进行的初步测试表明，速度从27％提高到60％以上。

After it proved itself in production, SPDY version 3 became basis for the first draft of HTTP/2, made by the Hypertext Transfer Protocol working group httpbis in 2015.

SPDY版本3在生产中得到证明后，便成为超文本传输​​协议工作组httpbis在2015年制定的HTTP / 2初稿的基础 。

HTTP/2 aims to address the issues ailing the first version of the protocol — latency issues — by:

HTTP / 2旨在通过以下方法解决与该协议的第一版有关的问题-延迟问题：

• compressing HTTP headers
  压缩HTTP标头

• implementing server push

  实现服务器推送

• multiplexing requests over a single connection.

  通过单个连接多路复用请求。

It also aims to solve head-of-line blocking. The data it transfers is in binary format, improving its efficiency, and it requires encryption by default (or at least, this is a requirement imposed by major browsers).

它还旨在解决行头阻塞。 它传输的数据采用二进制格式，从而提高了效率 ，并且默认情况下需要加密(或者至少是主流浏览器强加的要求)。

Header compression is performed with the HPACK algorithm, solving the vulnerability in SPDY, and reducing web request sizes by half.

标头压缩使用HPACK算法执行， 解决了SPDY中的漏洞 ，并将Web 请求的大小减少了一半。

Server push is one of the features that aims to solve wasted waiting time, by serving resources to the visitor’s browser before the browser requires it. This reduces the round trip time, which is a big bottleneck in website optimization.

服务器推送是旨在通过在浏览器需要之前向访问者的浏览器提供资源来解决浪费的等待时间的功能之一。 这减少了往返时间，这是网站优化的一大瓶颈。

Due to all these improvements, the difference in loading time that HTTP/2 brings to the table can be seen on this example page by imagekit.io.

由于所有这些改进，imagekit.io可以在此示例页面上看到HTTP / 2带到表的加载时间的差异。

Savings in loading time become more apparent the more resources a website has.

网站拥有的资源越多，节省加载时间就越明显。

如何查看网站是否通过HTTP / 2提供资源 (How to See If a Website Is Serving Resources over HTTP/2)

In major browsers, like Firefox or Chrome, we can check a website’s support for the HTTP/2 protocol in the inspector tool, by opening the Network tab and right-clicking the strip above the resources list. Here we can enable the Protocol item.

在诸如Firefox或Chrome之类的主要浏览器中，我们可以通过打开“ 网络”选项卡并右键单击资源列表上方的地带，在检查器工具中检查网站对HTTP / 2协议的支持。 在这里，我们可以启用协议项。

Another way is to install a little JavaScript-based tool that allows us to inspect HTTP/2 support through the command line (assuming we have Node.js and npm installed):

另一种方法是安装一个基于JavaScript的小工具，该工具使我们能够通过命令行检查HTTP / 2支持(假设我们已安装Node.js和npm)：

npm install -g is-HTTP2-cli

After installation, we should be able to use it like this:

安装后，我们应该可以像这样使用它：

is-HTTP2 www.google.com

✓ HTTP/2 supported by www.google.com
Supported protocols: grpc-exp h2 HTTP/1.1

实作 (Implementations)

At the time of writing, all major browsers support HTTP/2, albeit requiring all the HTTP/2 requests be encrypted, which the HTTP/2 specification itself doesn’t require.

在撰写本文时，所有主流浏览器都支持HTTP / 2 ，尽管要求对所有HTTP / 2请求进行加密，而HTTP / 2规范本身并不需要。

伺服器 (Servers)

Apache 2.4 supports it with its mod_HTTP2 module which should be production-ready by now. Apache needs to be built with it by adding the --enable-HTTP2 argument to the ./configure command. We also need to be sure to have at least version 1.2.1 of the libngHTTP2 library installed. In the case of the system having trouble finding it, we can provide the path to ./configure by adding --with-ngHTTP2=<path>.

Apache 2.4通过其mod_HTTP2模块支持它 ，该模块现在应该已经可以量产了。 需要通过在./configure命令中添加--enable-HTTP2参数来构建Apache。 我们还需要确保至少安装了libngHTTP2库的1.2.1版本。 如果系统找不到它，我们可以通过添加--with-ngHTTP2=<path>来提供./configure的--with-ngHTTP2=<path> 。

The next step would be to load the module by adding the directive to Apache’s configuration:

下一步是通过将指令添加到Apache的配置中来加载模块：

LoadModule HTTP2_module modules/mod_HTTP2.so

Then, we would add Protocols h2 h2c HTTP/1.1 to our virtual host block and reload the server. Apache’s documentation warns us of the caveats when enabling HTTP/2:

然后，我们将Protocols h2 h2c HTTP/1.1添加到我们的虚拟主机块并重新加载服务器。 Apache的文档在启用HTTP / 2时警告我们注意事项：

Enabling HTTP/2 on your Apache Server has impact on the resource consumption and if you have a busy site, you may need to consider carefully the implications.

在Apache服务器上启用HTTP / 2会对资源消耗产生影响，如果站点繁忙，则可能需要仔细考虑其含义。

The first noticeable thing after enabling HTTP/2 is that your server processes will start additional threads. The reason for this is that HTTP/2 gives all requests that it receives to its own Worker threads for processing, collects the results and streams them out to the client.

启用HTTP / 2之后的第一件事是服务器进程将启动其他线程。 原因是HTTP / 2将接收到的所有请求交给其自己的Worker线程进行处理，收集结果并将它们流式传输到客户端。

You can read more about the Apache configuration here.

您可以在此处阅读有关Apache配置的更多信息。

nginx has supported HTTP/2 since version 1.9.5, and we enable it by simply adding the http2 argument to our virtual host specification:

nginx 从1.9.5版开始支持HTTP / 2 ，我们可以通过在虚拟主机规范中添加http2参数来启用它：

server {
    listen 443 ssl http2 default_server;

    ssl_certificate    server.crt;
    ssl_certificate_key server.key;

Then reload nginx.

然后重新加载nginx。

Unfortunately, server push at the time of writing is not officially implemented, but it has been added to development roadmap, scheduled to be released next year. For the more adventurous ones, there is an unofficial nginx module that adds support for HTTP/2 server push.

不幸的是，在撰写本文时， 服务器推送尚未正式实施，但已添加到计划于明年发布的开发路线图中 。 对于更喜欢冒险的用户，有一个非官方的nginx模块可以添加对HTTP / 2服务器推送的支持。

LiteSpeed and OpenLiteSpeed also boast support for HTTP/2.

LiteSpeed和OpenLiteSpeed 还拥有对HTTP / 2的支持。

One caveat before activating HTTP/2 on the server side is to make sure that we have SSL support. This means that all the virtual hosts snippets we mentioned above — for Apache and for nginx — need to go into the SSL-version virtual host blocks, listening on port 443. Once we have Apache or nginx installed, and we have configured regular virtual hosts, getting the LetsEncrypt SSL certificate, and installing it on any of the major Linux distributions should be a matter of just couple of lines of code. Certbot is a command-line tool that automates the whole process.

在服务器端激活HTTP / 2 之前的一项警告是，确保我们具有SSL支持。 这意味着我们上面提到的所有虚拟主机片段(对于Apache和nginx)都需要进入SSL版本的虚拟主机块，侦听端口443。一旦安装了Apache或nginx，并配置了常规虚拟主机，获取LetsEncrypt SSL证书并将其安装在任何主要的Linux发行版上，只需几行代码即可。 Certbot是一个命令行工具，可自动完成整个过程。

结论 (Conclusion)

In this article, I’ve provided a bird’s-eye overview of HTTP/2, the new and evolving specification of a second-generation web protocol.

在本文中，我概述了HTTP / 2，这是第二代Web协议不断发展的新规范。

The full list of implementations of the new generation of HTTP can be found here.

可以在此处找到新一代HTTP的完整实现列表。

For the less tech-savvy, perhaps the shortest path to transitioning to this new protocol would be to simply implement a CDN into the web stack, as CDNs were among the earliest adopters of HTTP/2.

对于技术欠佳的人来说，过渡到该新协议的最短路径可能是简单地将CDN实现到Web堆栈中，因为CDN最早是HTTP / 2的采用者。

翻译自: https://www.sitepoint.com/http2-background-performance-benefits-implementations/

:style 设置背景图