Several recommendations for improving performance with HTTP/2

The historic Hypertext Transfer Protocol, the HTTP standard, has recently been upgraded. HTTP/2 was approved in May 2015 and is now being implemented in many Web browsers and servers (including Nginx Plus and open source nginx). About Two-thirds of browsers already support HTTP/2, and this ratio is increasing every month.

HTTP/2 built on the Google Spdy agreement, Chrome will stop supporting the latter in early 2016. Nginx is the first to support Spdy, and now also the first to support the HTTP/2. To do this, we have also published a detailed white paper (PDF) that describes HTTP/2 and how it is built based on Spdy and shows how to implement this new protocol.

The important features of HTTP/2 are derived entirely from spdy.

• HTTP/2 is a binary (and text) protocol, and therefore more concise and efficient;
• It uses only one multiplexed connection per domain, not one connection per file;
• The header is compressed using a specially crafted Hpack protocol (not gzip used in spdy);
• HTTP/2 designed complex prioritization rules to help the browser first request the most urgently needed files, and Nginx has supported (Spdy's scenario is simpler).

Now you need to decide whether to migrate to HTTP/2, and the key is to know how to make the most of it. This article will take you through the performance perspective of why this decision is made and how it is implemented. Next we will discuss 7 small suggestions about the performance of HTTP/2.

1. Do you need to migrate to HTTP/2 now?
2. Terminating HTTP/2 and TLS
3. Consider starting with the Spdy.
4. Find the code optimized for http/1.x
5. Deploy HTTP/2 or Spdy
6. Talk about http/1.x optimization again
7. Implementing Intelligent sub-domains

Note : Strictly speaking, spdy and HTTP/2 do not require TLS, but they are most useful when using SSL/TLS, and the browser only supports Spdy or HTTP/2 when using SSL/TLS.

Recommendation one: Do you need to migrate to HTTP/2 now?

The implementation of HTTP/2 is simple, see our white Paper on the Clear (PDF). However, HTTP/2 is not a universal silver bullet, it is only useful for some Web applications and not useful for others.

If you use SSL/TLS (hereafter referred to as TLS), then HTTP/2 can improve website performance. If you do not, then you need to support TLS before using HTTP/2. At this point, the performance loss of using TLS can roughly be offset by the performance boost used by HTTP/2. However, it is recommended that you test it before you actually apply it.

HTTP/2 has five major advantages.

1. each server uses only one connection . HTTP/2 uses only one connection per server, not one connection per file. This eliminates the time it takes to establish the connection more than once, which is especially noticeable for TLS because of the TLS connection charge time.
2. accelerates TLS delivery . The HTTP/2 requires only a time-consuming TLS handshake and optimal performance through multi-channel utilization on a single connection. HTTP/2 also compresses the header data, eliminating some of the optimizations needed for the http/1.x era, such as stitching files, thereby improving cache utilization.
3. simplify Web Apps . Using HTTP/2 can make Web developers save a lot of things, because there's no need to do the optimization work for http/1.x.
4. suitable for mixed-content pages . HTTP/2 is ideal for traditional pages that mix HTML, CSS, JavaScript, graphics, and limited multimedia. The browser can prioritize those important file requests so that the key parts of the page appear first and appear quickly.
5. more secure . By reducing the performance penalty for TLS, more applications can use TLS to make user information more secure.

Multiplexing of HTTP/2

Correspondingly, there are five deficiencies in HTTP/2.

1. single connection overhead is relatively large . The Hpack data compression algorithm updates the lookup tables at both ends. This allows the connection to have a state, while the state of destruction means that the lookup table is rebuilt, and the other single connection consumes more memory.
2. you may not need SSL. If your data does not need to be protected, or if it has been protected with DRM or other encodings, then the security of TLS may not matter to you.
3. you need to discard optimizations for http/1.x . http/1.x optimizations can affect performance in browsers that support HTTP/2, so it may take time to pull them back.
4. bad for downloading large files . If your app primarily offers large file downloads or streaming, you might not want to use TLS, and there is no advantage to multiplexing in the case of a single stream.
5. your client may not care . Your client probably doesn't care if the video he shares with his own cat is protected by TLS and HTTP/2.

In short, everything depends on performance. In this regard, there are good news and bad news.

The good news is that we tested nginx internally, and the results are theoretically proven: HTTP/2 performance is better than http/1.x and HTTPS for mixed content Web pages that want to defer requests through a typical network. Based on the connected RTT, the results can be divided into three cases.

• Very low RTT (0-20ms): http/1.x, HTTP/2, and HTTPS are virtually non-differentiated.
• Typical network RTT (30-250ms): HTTP/2 is faster than http/1.x, and they are faster than HTTPS. The RTT between the two neighboring cities in the United States is approximately five MS, while the East-west Coast (about 3000 miles) is approximately eight Ms. The shortest path between Tokyo and London is around the length of the RTT.
• High RTT (300ms and above): http/1.x faster than HTTP/2, which is faster than HTTPS.

This figure shows the time of the first rendering, the time the user first saw the content of the page on their screen. This time is generally considered to be related to the user perception of the site response speed.

To learn more about our testing, see this HTTP/2 introductory video from nginx.conf 2015.

However, each page is different, in fact, each user's session is not the same. If you host streaming media or provide large file downloads, your decision may not be the same, or even the opposite.

You may eventually find that the input-output ratio is not obvious. If so, you need to learn more, do more tests on your content, and then we can have a chat. (Want to find some information?) You can look at the Nginx webinar: What's New in HTTP/2?).

Recommendation two: terminating HTTP/2 and TLS

Terminating the protocol means that the client uses the desired protocol to connect to the proxy server, such as TLS or HTTP/2, and then the proxy server connects to the application server, the database server, and so on, but does not need to use the same protocol, as shown in.

Using a separate server termination protocol means using a multi-server architecture. Multiple servers can be multiple physical servers, multiple virtual servers, or multiple virtual server instances in a cloud environment such as AWS. Multiple servers are more complex than a single server or a combination of application server/database servers. However, multi-server architectures have many benefits, and many sites with large traffic must use this architecture.

After a server or virtual server is configured, a lot of things become possible. The new server can share the load of other servers and can be used for load balancing, static file caching, and other purposes. In addition, you can make it easier to add and replace application servers or other servers.

Nginx and Nginx Plus are often used to terminate TLS and HTTP/2 protocols, load balancing. There is no need to change the environment, unless you want to move the Nginx server to the front.

Recommendation three: Consider starting from Spdy

Spdy is the last generation of HTTP/2, with the same overall performance. Because it has been there for several years, many browsers support Spdy but do not support HTTP/2. However, at the time of writing, this gap in support is shrinking. Specifically, two-thirds of browsers support HTTP/2, while four-fifths of browsers support Spdy.

If you are in a hurry to adopt a new Web transport protocol and want to reach as many users as possible, start with Spdy first. Then by the beginning of 2016, when Google no longer supported Spdy, then switched to HTTP/2, very simple, at least in Nginx. At that time, more users would have a browser that supports HTTP/2, and you've already provided good performance for most of those users.

Recommendation four: Find the code optimized for http/1.x

Before you decide to adopt HTTP/2, you first need to know what your code is optimized for http/1.x. There are about four aspects of optimization.

1. The storage of the domain . In order to implement parallel request files, you may spread the files across different domains and the CDN will do so automatically. However, domain storage affects the performance of HTTP/2, and it is recommended to use HTTP/2-friendly, sub-domain storage (recommendation seven), only for http/1.x user domains.
2. Sprite Chart . Sprite maps a lot of pictures into one file, and then gets each picture by the code as needed. Sprite chart is not very useful in HTTP/2 environment, but it is still a bit of use.
3. stitching the code file . Similar to the use of sprite charts, many separate files are also made into one, and the browser then finds and runs the required files from it.
4. inserts a file within the row . CSS code, JavaScript code, and even images are inserted directly into the HTML file. This reduces file transfers at the expense of a large initial HTML file.

The next three optimizations involve stuffing small files into a larger file to reduce the initialization and handshake of new connections, which can be time-consuming for TLS.

The first optimization, which is the opposite of a domain store, forces multiple connections to be opened in parallel to obtain files from different domains. These two seemingly contradictory technologies are very effective for http/1.x sites. However, in order to use these two technologies, a great deal of time, effort and resources are needed to implement, manage, and operations.

Before using HTTP/2, you need to find out the code that applies these optimizations and analyze whether they will affect your application design and workflow. This way, after migrating to HTTP/2, you can start to transform them and even undo some optimizations.

Recommendation five: Deploy HTTP/2 or Spdy

In fact, deploying HTTP/2 or spdy is not difficult. If you are using Nginx, just start the appropriate protocol in the configuration file, see here to learn how to enable HTTP/2 (PDF). The browser and server negotiate what protocol to use, and if the browser supports HTTP/2 (and also uses TLS), HTTP/2 will be used.

After you configure the server, users who use the Http/2 browser will be running your app based on HTTP/2, while users of older browsers will continue to run your app using http/1.x, as shown in. If your site traffic is very large, then you should monitor the performance before and after the change, and for degraded performance, you may have to undo the change.

Note : After using HTTP/2 and its single connection, nginx some of the importance of certain configurations will be obvious, especially to pay attention to, output_buffers proxy_buffers and ssl_buffer_size Other instructions, more testing. See General configuration notes, specific SSL recommendations (here and here), and Nginx white Paper on SSL performance (PDF).

Note : Use HTTP/2 to transfer the ciphertext with extra attention. The HTTP/2 RFC has a long list of cryptographic suites to avoid. It is recommended that you make a form yourself, enable ssl_buffer_size it, and test the encryption suite you want to use under all popular browser versions.

Recommendation Six: Re-talk about http/1.x optimization

You say strange no, undo and modify code optimized for http/1.x is actually the most creative part of implementing HTTP/2. There are a few questions to be aware of, because a lot of things can be done.

Before you start, you must consider whether older browser users are better off. After that, you can take three policies to undo and modify the optimization of http/1.x.

• you don't have to do anything . If you do not optimize for http/1.x, or if you have done only a small amount of optimization, then you can move directly to HTTP/2 without doing anything.
• choose to do it selectively. The second scenario is to reduce the consolidation of some files, rather than simply merging them. For example, the sprite that is involved in many scenarios does not have to move, and the full HTML may be separated.
• completely undo the http/1.x optimization (however, refer to recommendation seven for domain storage recommendations first). You can no longer do any optimizations that you have done before.

The cache is still ubiquitous. In theory, caching is ideal for situations where small files are particularly numerous. However, many small files also mean more file I/O. Therefore, the merger of some similar documents is necessary, on the one hand to consider the work flow, on the other hand to consider the application performance. It is recommended to pay more attention to some of the experiences of others during the transition to HTTP/2.

Recommendation Seven: Implementing an intelligent sub-domain

Sub-domain storage is probably the most extreme but also the most successful http/1.x optimization strategy. It can improve application performance under http/1.x, but under HTTP/2, its performance gains can be ignored (because there is only one connection.) )

For HTTP/2 friendly sub-domains, ensure the following two points.

• Let multiple domain names resolve to the same IP.
• Make sure that the certificate contains wildcards so that all the sub-domains can be used, and the appropriate multi-domain certificates can of course.

For specific details, please refer to here.

With these guarantees, the domain will continue to be valid for http/1.x, that is, the domain name can still trigger the browser to create more connections, but it is not valid for HTTP/2, because these domains will be considered the same domain, and one connection will be able to access all domain names.

Summary

The combination of HTTP/2 and TLS can improve the performance of your site and make users feel that your site is safe. Whether you are the first to achieve HTTP/2 in your own application, or to catch up with your competitors, you can quickly and well achieve the support of HTTP/2.

Hopefully this article will allow you to get the most out of your HTTP/2 performance with minimal effort, and from then on you can focus on writing faster, more efficient, more secure applications, making your applications easier to maintain and operational.

Reference Resources

• To fully understand HTTP/2, you can look at the Nginx White Paper (PDF).
• Browser support for various front-end technologies, including Spdy and HTTP/2, can be found on the can I use website.
• To learn the details of our tests, refer to HTTP/2 presentation here.
• Nginx has a Web Workshop: What's New in HTTP/2?, discusses the core features and gives implementation recommendations.
• To learn about Nginx's performance recommendations, please refer to our blog: Ten Tips for 10x application performance.

 

Several recommendations for improving performance with HTTP/2