Seven Tips for Implementing HTTP / 2

Original author: Valentin Bartenev
  • Transfer
Recently, a new version of the HTTP standard has been released. In May 2015, HTTP / 2 was approved, which has gained distribution among browsers and web servers (including NGINX and NGINX Plus). Currently, more than 60% of browsers used support HTTP / 2, and this figure continues to increase every month.

The HTTP / 2 standard is based on the SPDY protocol developed by Google. On Google Chrome, SPDY support will be available until early 2016 . NGINX was one of the first to implement the SPDY protocol and now plays a leading role in promoting HTTP / 2. An article was published in which a detailed description of HTTP / 2 is given, a comparison with SPDY is given, and the process of implementing the new protocol is described in detail.

The main features of HTTP / 2 are similar to SPDY:

  • HTTP / 2 is a binary rather than a text protocol, which makes it more compact and efficient.
  • In HTTP / 2, only one multiplexing connection to the host is used, instead of multiple connections transmitting over a single file.
  • HTTP / 2 uses header compression using the specialized HPACK protocol (instead of gzip, which was used in SPDY).
  • HTTP / 2 uses a sophisticated prioritization mechanism to give browsers the most necessary files in the first place (SPDY used a simpler algorithm).

Now you need to go deeper and consider in more detail the features of the new protocol. This article is written to help you make the decision to switch to HTTP / 2, and also considers possible optimizations when implementing the protocol.

The following is a list of seven tips for implementing HTTP / 2:

  1. Assess the need to implement HTTP / 2
  2. Terminate HTTP / 2
  3. Get started with SPDY
  4. Refuse HTTP / 1.x optimization
  5. Deploy HTTP / 2 or SPDY
  6. Revise HTTP / 1.x Optimization
  7. View friendly HTTP / 2 sharding

Note: Strictly speaking, TLS is not required to use SPDY and HTTP / 2, but the main advantages are when SSL / TLS is enabled, so browsers only support SPDY and HTTP / 2 when SSL / TLS is available.

Assess the need to implement HTTP / 2


Implementing HTTP / 2 is easy and the process is described in detail here . However, it is worthwhile to understand that HTTP / 2 is not a universal solution and for some applications it may be useful, but for others it may not.

For example, with a high degree of probability, HTTP / 2 will accelerate a site that already uses SSL / TLS (hereinafter referred to as the TLS abbreviation), otherwise you must enable TLS before enabling HTTP / 2. It should be noted that performance degradation may occur from using TLS, which can negate the acceleration from HTTP / 2. Therefore, you should first check this case.

The following are five key potential benefits of using HTTP / 2:

  1. Only one connection to the server is used instead of many connections transmitting one file. In other words, the number of connections is reduced, which is especially useful when using TLS.
  2. Effective use of TLS. HTTP / 2 makes only one TLS handshake, and multiplexing allows you to effectively use this connection. HTTP / 2 also compresses header data, and eliminating HTTP / 1.x optimizations (such as file concatenation) allows the caching algorithm to work more efficiently.
  3. Simplify web applications. When using HTTP / 2, you can get rid of HTTP / 1.x optimizations, which also deprive developers of inconvenience.
  4. Great for complex web pages. HTTP / 2 is great for web pages that simultaneously use HTML, CSS, JavaScript, images and videos. Browsers can prioritize file requests so that the most necessary parts of the page are sent first.
  5. Connection Security. Although using HTTP / 2 may cause performance loss due to the use of TLS, at the same time TLS will make web applications more secure for users.


image

And five corresponding shortcomings that can be encountered:

  1. High costs for one connection. The HPACK data compression algorithm requires support for a conversion table at both ends. Also, one connection requires more memory.
  2. Perhaps the use of TLS is redundant. If the transmitted information does not need protection or is already protected using DRM (or other encryption), then TLS is unlikely to be useful.
  3. Finding and removing existing HTTP / 1.x optimizations is necessary to increase the performance of HTTP / 2, which is additional work.
  4. It does not give advantages when downloading large files. If the web application is mainly designed to download large files or video streaming, then most likely the use of TLS will be erroneous, and multiplexing will not bring any benefit.
  5. Security is not important. Perhaps visitors do not care that the video with the seals they share on your site is not protected by TLS and HTTP / 2 (which may be true).

It all comes down to performance and there is good and bad news.

The good news is that based on the tests that were conducted at NGINX, the results predicted by theory follow: for complex web pages requested with typical latency, HTTP / 2 performance is higher than HTTP / 1.x and HTTPS. The results are divided into three groups depending on the typical round-trip time (RTT):

  • Very low RTTs (0-20 ms): virtually no difference between HTTP / 1.x, HTTP / 2, and HTTPS.
  • Medium (typical for the Internet) RTTs (30-250 ms): HTTP / 2 is faster than HTTP / 1.x, and both are faster than HTTPS. For neighboring cities in the United States, RTT is about 30 ms, and about 70 ms from one coast to the other (about 3,000 miles). On one of the shortest routes between Tokyo and London, RTT is about 240 ms.
  • High RTTs (300 ms and higher): HTTP / 1.x is faster than HTTP / 2, which is faster than HTTPS.


image

The figure shows the time before the start of rendering - that is, the time until the moment the user sees the first content of the web page. This time is often seen as crucial for users to perceive the responsiveness of the website.

More details about the testing process and the results can be found in the presentation from the nginx.conf 2015 conference.

However, all web pages and user sessions are different from each other. For example, if you have video streaming or large downloads, then your results may vary or even be opposite.

The bottom line is that you first need to understand the possible costs and the greatest benefits when using HTTP / 2. After that, it is worthwhile to test the performance of your applications, and then make a choice.

Terminate HTTP / 2


Termination means that the client can connect to the proxy server through a specified protocol, such as HTTP / 2, and then the proxy server connects to server applications, databases, etc. using a completely different protocol (see image below).

image
When using separate servers, it becomes possible to switch to a multi-server architecture. Servers can be shared physically, virtually, or a cloud environment such as AWS can be used . This complicates the architecture compared to a single-server solution or a combination of a server + database, but it offers many advantages and is a necessity for highly loaded sites.

After a physical or virtual server is installed in front of the existing system, additional features become available. The new server offloads other servers from processing client messages. In addition, it can be used for load balancing, static file caching and any other purposes. It is becoming much easier to add and replace server applications and other servers as needed.

NGINX and NGINX Plus are often used for all these purposes - TLS and HTTP / 2 termination, load balancing and much more. The existing environment does not require any changes, except for the part on user interaction with the NGINX server.

Get started with SPDY


SPDY is the forerunner of HTTP / 2 and its performance is comparable to HTTP / 2. Since SPDY has been around for several years, all popular browsers support it , unlike HTTP / 2 , which appeared relatively recently. However, at the time of writing, the gap is narrowing and more than 60% of browsers already support HTTP / 2, while SPDY supports more than 80%.

If there is an urgent need to implement a new transport protocol, and use the protocol with maximum support among users, then you should start with SPDY. Later, in early 2016, when SPDY support will be removed, switch to HTTP / 2. At this point, a larger number of users will use browsers that support HTTP / 2, so this transition may be optimal from the point of view of most users.

Refuse HTTP / 1.x optimizations


Before implementing HTTP / 2, you need to identify optimizations for HTTP / 1.x. The following are four types of optimizations that you should pay attention to:

  1. Sharding. Placing files on different domains for parallel transfer to the browser; Content Delivery Networks (CDNs) do this automatically. Such optimizations can damage HTTP / 2 performance. You can use HTTP / 2 friendly sharding for HTTP / 1.x users (see HTTP / 2 friendly sharding).
  2. Using sprites. Sprites are collections of pictures that are transmitted as a single file; after that, on the client side, pictures are retrieved from the collection as necessary. This optimization is less efficient when using HTTP / 2, although it can still be useful.
  3. File merge. Like sprites, some of the files that are usually stored separately are merged into one. After that, the browser finds and runs the code as necessary within the glued file.
  4. Embedding files. CSS, JavaScript, and even images are inserted directly into the HTML file, which reduces the number of transmitted files by increasing the source HTML file.

The last three types of optimization for combining small files into larger ones, reducing new connections and initializing additional connections are especially important when using TLS.

The first optimization, sharding, works differently - it forces you to open more connections using additional domains. Together, these seemingly contradictory methods can be quite effective in improving the performance of HTTP / 1.x sites. However, they all spend time, effort and resources to develop, implement, manage and maintain work.

Before implementing HTTP / 2, you should find these optimizations and find out how they currently affect application design and workflow. This should be done in order to be able to change or cancel these optimizations after moving to HTTP / 2.

Deploy HTTP / 2 or SPDY


In fact, switching to HTTP / 2 or SPDY is pretty simple. For NGINX users, you just need to “enable” the protocol in the NGINX configuration, as described here using HTTP / 2 as an example. After that, the server will notify the client browser about the possibility of using HTTP / 2 or SPDY.

After enabling HTTP / 2 on the server, users whose browsers support HTTP / 2 will connect and work with web applications through HTTP / 2. People with older versions of browsers will have to work through HTTP / 1.x (see the figure below). When implementing HTTP / 2 or SPDY on highly loaded sites, you should measure the performance before and after, and roll back the changes in case of negative consequences.

image

Note: Since HTTP / 2 uses a single connection, some configuration settings in NGINX become more important. It is recommended that you review the NGINX configuration with particular attention to setting and testing the parameters of directives such as output_buffers, proxy_buffers, and ssl_buffer_size. You should pay attention to general configuration notes , specific TLS tips ( here and here ), and an article on NGINX performance when using TLS.

Note: When using ciphers with HTTP / 2, you should pay attention to the following: RFC for HTTP / 2 has a long listciphers to avoid. If you want to configure the list of ciphers yourself, then in this case it is recommended to consider setting ssl_ciphers and turning on ssl_prefer_server_ciphers on , and then test the appropriate ciphers with all popular versions of browsers. The indicator for the popular Qualys' SSL Server test browsers (as of November 2015) is considered unreliable for counting HTTP / 2 handshakes .

Revise HTTP / 1.x Optimization


This is not surprising, but removing or modifying HTTP / 1.x optimizations is the most creative part of implementing HTTP / 2. There are several issues to consider.

Before making changes, users of older browsers that may be affected should be considered. With this in mind, there are three main strategies for canceling or revising HTTP / 1.x optimizations:

  • Is everything ready. If the applications have not been optimized for HTTP / 1.x or minor changes have been made, then everything is ready to use HTTP / 2.
  • Mixed approach. You can reduce data concatenation but not completely eliminate it. For example, some image sprites may remain, while at the same time getting rid of data embedded in HTML.
  • A complete rejection of HTTP / 1.x optimization (but see friendly HTTP / 2 sharding and notes). You can simply completely get rid of optimizations.

Caching has some features. In theory, caching works effectively when applied to many small files. However, in this case, a large number of I / O operations are performed. Therefore, combining related files can be useful for both the workflow and application performance.

View friendly HTTP / 2 sharding


Sharding is perhaps the most difficult, and at the same time, perhaps the most successful HTTP / 1.x optimization strategy. Sharding can be used to improve HTTP / 1.x performance, but for HTTP / 2 (which uses only one connection), it is mostly ignored.

To use sharding paired with HTTP / 2, there are two things to do:

  • Make domain names for sharding resources resolve to the same IP address.
  • Make sure that a wildcard certificate is used - in this case it will be valid for all domain names used in sharding. Or make sure that you have the appropriate multi-domain certificate.

Detailed information can be found here .

Under these conditions, sharding will occur for HTTP / 1.x - since the domains are different, which allows browsers to create additional sets of connections - and will not happen for HTTP / 2, since individual domains are considered as one, and the connection can be accessed to any of them.

Conclusion


Most likely, HTTP / 2 with TLS will help increase the performance of your site and allow users to be sure that their connection is secure. Moreover, the introduction of HTTP / 2 support, most likely, will not require a lot of effort.

The tips above should help you achieve the best HTTP / 2 performance with the least effort so that you devote the rest of your time to building fast, efficient, and secure applications.

Also popular now: