HTTP / 2: getting ready for the transition

Last year a very important event happened in the world of network technologies: a new version of the HTTP protocol, HTTP / 2, was approved and standardized. HTTP / 2 is already supported in popular web servers: Apache and Nginx. Work is underway on the implementation of HTTP / 2 in IIS. Implemented support in most modern browsers.

The use of HTTP / 2 has recently expanded significantly.

According to mid-2015, the percentage of sites and web services that switched to HTTP / 2 was small - only 0.4%. Very recent statistics (January 2016) shows a significant increase: from 0.4 to 6.5%. There is every reason to believe that in the near future the growth rate will increase.
')
To think about the practical aspects of the transition to HTTP / 2 should be now. We would like to touch on this topic in today's article. We will be especially interested in the problem of adapting the existing methods of optimizing the performance of websites to the specifics of the new protocol.
Before proceeding directly to the consideration of this issue, we turn to the history of the HTTP / 2 protocol and briefly describe the main innovations that distinguish it from HTTP / 1.1.

From HTTP to HTTP / 2

A bit of history

The first description of the HTTP protocol (HyperText Transfer Protocol) was published in 1991. In 1999, HTTP 1.1 was developed and described, which is still used today. In that distant time (almost 20 years ago), websites were not at all the same as now. For a relatively short period of time, sites began to "weigh" much more. The home page of an average modern website contains approximately 1.9 MB of data: images, JS, CSS, and more.

Due to the restriction on the number of simultaneous connections in HTTP / 1.1, loading pages that contain a large amount of "heavy" content is slow. There are two ways to solve this problem. The first is to use various performance optimization techniques (some of which we have already written ), and the second is to try to modify the HTTP protocol itself in order to eliminate possible bottlenecks. Consider such attempts in more detail.

The first large-scale HTTP reforming project was introduced in 2009 by Google engineers. This is the SPDY protocol , the purpose of which was primarily to accelerate the work of websites and applications by modifying the traditional methods of receiving and sending requests.

SPDY requires support both on the server side and on the client side. Google developers have created specialized modules for Apache ( mod_spdy ) and for Nginx ( ngx_http_spdy_module ). It is supported in almost all popular browsers.

HTTP / 2, introduced six years later, is largely based on SPDY. The new version of HTTP was created by the working group Hypertext Transfer Protocol working group. In May 2015, the HTTP / 2 specification was published as RFC 7540 .

The HTTP / 2 protocol is backward compatible with HTTP / 1.1. Changes aimed at eliminating bottlenecks and increasing productivity largely continue the SPDY line. Consider briefly the most important of them.

HTTP / 2: major innovations

Multiplexing

Perhaps this is the most important advantage of HTTP / 2. In HTTP / 1.1, each request requires a separate TCP connection. Multiplexing allows the browser to perform multiple requests within a single TCP connection:



In modern browsers, the number of simultaneous TCP connections is limited. Therefore, pages with a lot of static content are not loaded as quickly as we would like.

In HTTP / 2, by multiplexing, static elements are loaded in parallel, and as a result, performance is greatly improved.

Priorities

Another HTTP / 2 innovation is prioritization. Each request can be assigned a priority.
There are two approaches to assigning priorities: based on weight and based on dependencies.

In the first approach, each thread receives a certain weight. Then, based on the weight, the server distributes the load among the threads. This approach has already been used in the SPDY protocol.

The second method, which is the main one in HTTP / 2, is as follows: the browser asks the server to download certain content items first. For example, the browser may ask the server to first load the CSS files or JavaScript, and only then HTML or images.

In HTTP / 2, prioritization is not a mandatory, but a desirable method. However, multiplexing without it will not work properly. Download speed may be even lower than HTTP / 1.1. Resources with lower priority will occupy the band, which will lead to lower productivity.

HTTP header compression

A modern web page consists of many elements: images, JS, CSS and others. In the request to download each of these elements, the browser sends an HTTP header. By sending the requested items, the server also adds a header to them. All this is associated with the waste of resources.

In HTTP / 2, headers are transmitted in compressed form. This reduces the amount of information exchanged between the server and the browser. Instead of gzip / deflate algorithms, HPACK is used. This reduces vulnerability to BREACH attacks .

HTTP / 2 and security

One of the most important requirements of the SPDY protocol is the mandatory encryption (HTTPS) of the connection between the client and the server. In HTTP / 2 it is not mandatory. However, browser developers decided to implement a new protocol only for TLS (HTTPS) connections. Therefore, those who are thinking about switching to HTTP / 2, you must first switch to HTTPS.

This is needed not only for HTTP / 2. In Google search, using a secure connection is one of the ranking criteria . Browsers (see here and here ) will soon mark sites that do not support https as “unsafe”. We also add that many features of HTML5 - for example, geolocation - without a secure connection will not be available .

Basic HTTP / 2 configuration in Nginx and Apache

Here are brief instructions on how to enable and configure HTTP / 2 in Nginx and Apache. As mentioned above, most modern browsers work with HTTP / 2 only via TLS, so the appropriate settings should be specified in the configuration of your web server.

Nginx

HTTP / 2 support is implemented only in the latest versions of Nginx (1.9.5 and higher). If you have another version installed, you will need to update it.

After that, open the configuration file /etc/nginx/nginx.conf and find the following line in the server section:

 listen 443 ssl;

and replace it with:

 listen 443 ssl http2;

Save the changes and restart Nginx:

 $ sudo service nginx reload

Apache

Apache HTTP / 2 is supported only in versions 2.4.17 and higher. If you have an earlier version installed, upgrade and plug in the mod_http2 module. After that, add the following lines to the configuration file:

 # for a https server
 Protocols h2 http / 1.1

 # for a http server
 Protocols h2c http / 1.1

After that, restart Apache. That's all - for the basic configuration of this is enough.

HTTP / 2 and site optimization

HTTP / 2 is backward compatible with HTTP / 1.1. Therefore, in principle, you can take no action: nothing threatens the work of your service.
But as popular web servers and web browsers switch to HTTP / 2, you will see that your site, which was once optimized to increase page loading speed and increase productivity, is not working as fast as before.

Many optimization methods successfully used in HTTP / 1.1 will not work in HTTP / 2. Some of them will need to be modified, and some will be abandoned altogether. Consider this question in more detail.

Combining images into sprites

In HTTP / 1.1, it was more convenient to upload one large image than to do a lot of requests and download many small ones. This is due to the fact that requests are queued for each other. The most common way to increase download speed was to combine multiple small images into a sprite file .

Sprite returned in response to a single request. Even if the user went to the page on which there is only one small image, it was necessary to load the entire sprite.

In HTTP / 2 with its multiplexing, there are no such problems, but using sprites in certain situations may be useful. Combining multiple images into a sprite (especially if all these images are on the same page) helps to improve compression and thus reduce the total amount of data loaded.

Embedding Images with DataURI

Another popular way to solve the problem of multiple HTTP requests in HTTP / 1.1 is to embed images using the Data URI . This significantly increases the size of the style sheet.

If simultaneously with embedding images for optimization, JS and CSS are also used for concatenation, the user will most likely have to download all the relevant code, even if he does not visit the page with these images.
In HTTP / 2, this practice will worsen rather than improve performance.

JS and CSS concatenation

To optimize the work sites often used concatenation of small CSS-and JS-files. Many small files are combined into one large. Thus, it is possible to bypass the limit on the number of HTTP requests.

However, using concatenation can cause the same problem as with sprites: by going to any one page of the site, the user will download all the CSS and JS files used on it (it’s very likely that most of these files never will need). Of course, you can carefully select files for each page of the site, but it will take too much time.

Another difficulty lies in the fact that all elements of the concatenated file must be cleaned from the cache at the same time. It is impossible to make so that for some elements one expiration date is set, and for others (which are also used more often) another one. If you change at least one line in CSS, all elements will expire immediately.

Should I use concatenation in HTTP / 2? If HTTP requests do not require significant resources, then you can easily do without it. Loading a lot of small style files won't make any problems. There will be no difficulties with expiration and caching.

Domain Sharding

HTTP / 1.1 has a limit on the number of open connections. To get around this limitation, you have to load static resources from several subdomains of the same domain. This technique is called domain sharding; It is often used, for example, for pages with a large number of images. This helps to increase the download speed, but at the same time creates additional problems .

With the HTTP / 2 transition, there is no need for domain sharding. You can request as many resources as you need. Moreover, in the case of HTTP / 2, sharding does not improve performance, but rather leads to the opposite effect, since it creates additional TCP connections and interferes with prioritization.

When to go?

When to plan the transition to HTTP / 2? There is no unequivocal answer to this question, and there can not be. We will give, however, one clue: regularly review the attendance logs of your service. When you see that most visitors use HTTP / 2-capable browsers, you can proceed. Currently, HTTP / 2 support is implemented in Chrome (including the mobile version for Android), Firefox, Opera, Edge, Safari.

When planning the transition should take into account the features of your project. If you have a lot of users that come to you from mobile devices, this means that you want to switch to HTTP / 2 as soon as possible. On smartphones and tablets, the benefits of the new protocol will be especially obvious. However, here you need to take into account many nuances: for example, in many regions of the world there are still many users of the Opera Mini browser, and it does not yet support HTTP / 2.

If you plan to launch a new web service - think about the prospect of switching to HTTP / 2. Of course, you still have to use HTTP / 1.1 for some time, but now you can take optimization measures that will make your life easier in the future.

useful links

In conclusion, we give some interested links for interested readers on the topic:

• full text of the HTTP / 2 specification ;
• HTTP / 2 FAQ - a brief but informative excerpt from the specifications at the link above;
• clarifications on HTTP / 2 , written by the developer of the curl utility Daniel Sternberg (see also Russian translation );
• presentation about website optimization for HTTP / 2 .

Readers who for one reason or another can not leave comments here are invited to our blog .