7 Suggestions for using HTTP/2 to improve performance

7 Suggestions for using HTTP/2 to improve performance

The historical Hypertext Transfer Protocol (HTTP standard) has been upgraded recently. HTTP/2 was approved in May 2015 and has been implemented in many Web browsers and servers (including NGINX Plus and open source NGINX ). About 2/3 of browsers support HTTP/2, and this proportion is increasing every month.

HTTP/2 is built on the Google SPDY protocol. Chrome will stop supporting the latter in early 2016. NGINX was the first to support SPDY, and now it is also the first to Support HTTP/2. To this end, we have released a detailed White Paper (PDF) to introduce HTTP/2, how it is built based on SPDY, and how to implement this new protocol.

An important feature of HTTP/2 comes from SPDY.

• HTTP/2 is a binary (text) protocol, so it is more concise and efficient;
• It only uses one multiplexing connection for each domain, rather than one connection for each file;
• The first step is to use a special HPACK protocol (instead of gzip used in SPDY) for compression;
• HTTP/2 has designed complex priority scheduling rules to help the browser first request the most urgently needed files, while NGINX already supports (the SPDY solution should be simpler ).

Now, you need to decide whether to migrate to HTTP/2, and the key is to know how to use it to the maximum extent. This article will show you why to make this decision and how to implement it from the perspective of performance. Next we will discuss seven small suggestions on HTTP/2 performance one by one.

1. Whether to migrate to HTTP/2
2. Terminate HTTP/2 and TLS
3. Starting with SPDY
4. Find the code optimized for HTTP/1.x
5. Deploy HTTP/2 or SPDY
6. HTTP/1.x Optimization
7. Implement smart domain sharing

Note: strictly speaking, SPDY and HTTP/2 do not require TLS, but they are most useful when using SSL/TLS, in addition, the browser only supports SPDY or HTTP/2 when using SSL/TLS.

Recommendation 1: whether to migrate to HTTP/2

It's easy to implement HTTP/2. Let's take a look at our White Paper. However, HTTP/2 is not a silver bullet. It is only useful for some Web applications, but not so useful for others.

If you use SSL/TLS (TLS), HTTP/2 can improve the website performance. If you do not have one, you must support TLS before using HTTP/2. At this time, the performance loss of TLS can be roughly offset by the performance improvement of HTTP/2. However, we recommend that you test the function before using it.

HTTP/2 has five advantages.

1. Each server uses only one connection. HTTP/2 only uses one connection for each server, rather than one connection for each file. In this way, the time for establishing connections is reduced, which is especially time-consuming for TLS connections.
2. Accelerate TLS delivery. HTTP/2 only requires a time-consuming TLS handshake and achieves optimal performance through multiple connections. HTTP/2 will also compress the first data, saving some optimization work required in the HTTP/1.x era, such as splicing files, to improve the cache utilization.
3. Simplify Web applications. Using HTTP/2 can save Web developers a lot of trouble, because they do not need to do any optimizations for HTTP/1.x.
4. Suitable for pages with mixed content. HTTP/2 is especially suitable for traditional pages that mix HTML, CSS, JavaScript, images, and limited multimedia. The browser can prioritize important file requests so that key parts of the page can appear first.
5. More secure. By reducing the performance loss of TLS, more applications can use TLS to make user information more secure.

Multiplexing of HTTP/2

Correspondingly, HTTP/2 has five shortcomings.

1. The overhead of a single connection is relatively large. The HPACK Data Compression Algorithm updates the search tables at both ends. In this way, the connection can be stateful, and the broken state means that the query table needs to be rebuilt. In addition, a single connection occupies a large amount of memory.
2. You may not need SSL. If your data does not need protection, or you have already used DRM or other encoding for protection, the security of TLS may not matter to you.
3. We need to discard the optimization for HTTP/1.x. HTTP/1.x optimization affects the performance of browsers that support HTTP/2, so it may take time to reinvent them.
4. It is not good for downloading large files. If your application mainly provides large file downloads or streaming media playback, you may not want to use TLS. In addition, multiplexing does not have any advantages when only one stream exists.
5. Your customers may not care. Your customers may not care whether the videos of their cats they share are 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 have tested NGINX internally and the results can be theoretically confirmed: For hybrid content web pages that require requests to be delayed through a typical network, HTTP/2 performs better than HTTP/1. x and HTTPS. The connection-based RTT can be divided into three situations.

• Low RTT (0-20 ms): HTTP/1.x, HTTP/2, and HTTPS are basically the same.
• Typical network RTT (30-250 ms): HTTP/2 is faster than HTTP/1.x, and they are faster than HTTPS. The RTT between two neighboring cities in the United States is about 30 ms, while the East West Coast (about 3000 miles) is about 70 ms. The shortest path between Tokyo and London is about 240 ms.
• High RTT (MS or above): HTTP/1.x is faster than HTTP/2, and the latter is faster than HTTPS.

First rendering time

This figure shows the first rendering time, that is, the time when the user first saw the webpage content on his screen. This time is generally considered to be related to users' perception of website response speed.

For more information about the tests, see the introduction video of HTTP/2. The source is nginx. conf 2015.

However, each webpage is different. In fact, the sessions of each user are different. If you host streaming media or provide large file downloads, your decisions may be different, or even the opposite.

You may eventually find that the input-output ratio is not obvious. If so, you should learn more and perform more tests on your own content. Then, let's have a chat. (Want to find some information? Let's take a look at NGINX network discussion: What's New in HTTP/2 ?).

Recommendation 2: Terminate 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 and database server, but does not need to use the same protocol, as shown in.

Using an independent server termination protocol means using a multi-server architecture. Multiple servers may be multiple physical servers, multiple virtual servers, or multiple virtual server instances in an AWS cloud environment. Multiple servers are more complex than single servers, or more complex than the combination of application servers and database servers. However, the multi-server architecture has many advantages, and many websites with high traffic must also use this architecture.

Terminate HTTP/2 and TLS

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

NGINX and NGINX Plus are often used to terminate TLS and HTTP/2 protocols and load balancing. You do not need to change the existing environment unless you want to move the NGINX server to the front-end.

Recommendation 3: Start With SPDY

SPDY is the previous generation of HTTP/2, with the same overall performance. Because it has been around for several years, many browsers support SPDY but do not support HTTP/2. However, when writing this article, the gap in support is narrowing down. Specifically, 2/3 of browsers support HTTP/2, while 4/5 of browsers support SPDY.

If you are eager to use the new Web transmission protocol and want to cover as many users as possible, you can start with SPDY. Then, in early 2016, Google switched to HTTP/2 when it no longer supported SPDY, at least in NGINX. At that time, more users will have browsers that support HTTP/2, and you have provided good performance for most of them.

Recommendation 4: Find the code optimized for HTTP/1.x

Before deciding to use HTTP/2, you must first know which code has been optimized for HTTP/1.x. There are about four optimizations.

1. Sub-domain storage. To implement parallel request files, you may distribute the files to different domains. CDN will automatically perform this operation. However, domain-based storage affects the performance of HTTP/2. We recommend that you use HTTP/2-friendly domain-based storage (see recommendation 7), which is only for HTTP/1. x User Domain-based storage.
2. Sprites ). The IMG assembles many images into one file and then obtains each image as needed through code. The image genie is not very useful in the HTTP/2 environment, but it is still a bit useful.
3. The spliced code file. Similar to the image genie, many independent files are made into one, and then the browser finds and runs the required files.
4. Inline file. CSS code, JavaScript code, and even images are directly inserted into HTML files. In this way, file transmission can be reduced, at the cost of a large initial HTML file.

The following three optimizations involve inserting small files into a large file to reduce the initialization and handshake of new connections. These operations are time-consuming for TLS.

The first optimization is that the domain-based storage is the opposite. It forces multiple connections to obtain files from different domains in parallel. These two seemingly conflicting technologies are very effective for Websites under HTTP/1.x. However, to make good use of these two technologies, you must invest a lot of time, energy, and resources for implementation, management, and O & M.

Before using HTTP/2, you need to find out the optimized code and analyze whether it will affect your application design and workflow. In this way, after migrating to HTTP/2, you can modify them and even cancel some optimizations.

Recommendation 5: deploy HTTP/2 or SPDY

In fact, it is not difficult to deploy HTTP/2 or SPDY. If you use NGINX, you only need to start the corresponding protocol in the configuration file. For more information, see How to enable HTTP/2. The browser and the server negotiate the protocol used. If the browser supports HTTP/2 (and also uses TLS), HTTP/2 is used.

After the server is configured, users who support HTTP/2 browsers will run your application based on HTTP/2, while users who use older browsers will continue to use HTTP/1. x runs your application, as shown in. If your website traffic is very high, you should monitor the performance before and after the change. If the performance is low, you may have to cancel the change.

Support HTTP/2 and HTTP/1.x on the server

Note: After using HTTP/2 and its single connection, some NGINX configurations are important. Note thatoutput_buffers,proxy_buffersAndssl_buffer_sizeWait for the command to test it. See general configuration tips, specific SSL suggestions (here and here), and NGINX White Paper on SSL performance.

Note: pay special attention to the use of HTTP/2 to transmit ciphertext. The RFC for HTTP/2 contains a long list of cipher suites to be avoided. We recommend that you create a table by yourself to enablessl_buffer_sizeAnd then test the cipher suite you want to use in all common browser versions.

Suggestion 6: Let's talk about HTTP/1.x optimization.

You can't say that undo and modify the code optimized for HTTP/1. x is actually the most creative part of HTTP/2. There are several issues to be aware of, because it is possible to do many things.

Before getting started, you must consider whether the old browser users are better. Then, you can adopt three policies to cancel and modify the HTTP/1.x optimization.

• No need to do anything. If you have not optimized HTTP/1.x or only performed a small amount of optimization, you can directly migrate to HTTP/2 without having to do anything.
• Selectively. The second case is to reduce the number of files to be merged, rather than not merging at all. For example, the image genie involved in many scenarios do not need to be moved, and HTML may be separated.
• Completely cancel HTTP/1.x optimization (however, please refer to the recommendation in recommendation 7 for domain-based storage ). You can skip any previous optimizations.

The cache is still universal. In theory, cache operations are very suitable for scenarios where there are many small files. However, many small files also mean many I/O files. Therefore, it is necessary to merge some similar files. On the one hand, we should consider the workflow, and on the other hand, we should consider the application performance. It is recommended that you pay more attention to the experience of others during the transition to HTTP/2.

Recommendation 7: implement intelligent domain Separation

Domain-based storage may be the most challenging but most successful HTTP/1.x optimization policy. It can improve the application performance in HTTP/1.x, but in HTTP/2, its performance improvement can be ignored (because there is only one connection .)

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

• Resolve multiple domain names to the same IP address.
• Make sure that the certificate contains wildcards so that all domain names can be used. A multi-domain certificate can also be used.

For details, refer to here.

With these guarantees, the sub-domain will continue to apply HTTP/1. x is valid, that is, the domain name can still trigger the browser to create more connections, but it is invalid for HTTP/2, because these domain names will be treated as the same domain, one connection can access all domain names.

Summary

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

I hope this article will allow you to achieve the maximum HTTP/2 performance gains with minimal effort, and from then on, you can focus on writing faster, more effective, and safer applications, make your applications easier to maintain and maintain.

Reference resources

• For more information about HTTP/2, see the NGINX White Paper (PDF ).
• InCan I useThe website can check the browser's support for various front-end technologies, including SPDY and HTTP/2.
• For more information about the test, see HTTP/2 presentation.
• NGINX has a Web Seminar: What's New in HTTP/2 ?, The core features are discussed and implementation suggestions are given.
• For more information about NGINX Performance, see our blog: 10 Tips for 10x Application Performance.

This article permanently updates the link address: