Why upgrade to HTTP /2? When we review sites using Chrome’s console, non-HTTP /2 sites give us a suggestion:
This means to use HTTP /2. I’ve only heard about HTTP /2 before, but HTTP /2 is already here. The biggest feature of HTTP /2 is the use of multiplexing, the server in the same domain only establish a TCP connection, load multiple resources, use binary frame transmission, while the HTTP header will be compressed. It is more efficient to use HTTP2 than HTTP /1.1, so I have upgraded my blogging efforts.
1. Upgrade to HTTP/2
The minimum version required for Nginx is 1.10.0, the minimum version required for OpenSSL is 1.0.2, and HTTP /2 is basically HTTPS only. This version is ok, but the openSSL of the system is 1.0.1. Update the openSSL of the system to 1.0.2, but it is still not ok. Openssl 1.0.1 was specified by nginx at compile time, so it is not useful to upgrade the openSSL system, as shown in the following figure:
So how do you upgrade? Nginx officially provides two methods, the first is to upgrade the operating system, the second is to build a new version of nginx from source, we use the second method. The latest stable version of nginx is 1.12.1. Run the following command on the server:
Wget HTTP: / / http://nginx.org/download/nginx-1.12.1.tar.gz# downloadThe tar - ZXVF nginx - 1.12.1. Tar. Gz# decompression
cdNginx - 1.12.1. / configureVerify the system environment and generate a make file
make # compiler
sudo make install # installationCopy the code
Configure can be configured with the same parameters as the old version of nginx, including the installation path. This can be obtained by executing nginx -v to make the new Nginx configuration as the old nginx configuration. If the configure prompt is missing some libraries, install them accordingly.
./configure: error: the Google perftools module requires the Google perftools
library. You can either do not enable the module or install the library.
This can be solved by installing the following library:
sudo yum install gperftools-develCopy the code
The openSSL version of nginx is correct:
Add nginx configuration, HTTPS listen:
listen 443 ssl;Copy the code
Now add http2 to the end:
listen 443 ssl http2;Copy the code
Nginx is now installed in a new browser, and is then turned off and on again.
It will become http2:
One detail is that HTTP/2 is not called 2.0. This is intentional, because 1.x is confusing, so the 2 version number is not included, so the firefox display above is actually incorrect.
The entire transport model is shown below (image from Nginx) :
Nginx and clients are HTTP/2, while nginx and business services are HTTP/1.1. Because nginx and business services are usually on the same Intranet, the speed is usually very fast, and the connection between Nginx and clients is not very controllable. It would be better if the business service itself supported HTTP/2.
Then let’s first look at how much traffic is saved by transferring it, as shown in the picture below. Load a page:
As you can see, HTTP 2 does not offer much improvement in terms of traffic, only reducing traffic by 4kB (1%). Let’s look at why. Another advantage of HTTP 2 is its multiplexing and other aspects.
2. Advantages of HTTP/2
(1) multiplexing
The point of multiplexing is that multiple resources can be transferred over the same connection, thus eliminating some of the optimizations previously made in HTTP 1.1, such as:
A) Use Sprite image technology to combine multiple small images into one large image to reduce the number of requests;
B) Combine JS and CSS to reduce the number of requests.
Because in the HTTP 1.1 era, servers need more threads to process requests because they need to establish multiple TCP connections, and browsers also need more threads to process requests, so browsers limit the number of simultaneous requests to the same domain. Chrome limits the number of simultaneous requests to 6, and the total number of connections to 17. This site allows readers to test the limitations of their browser. For a practical comparison, HTTP 1.1 queues resources, as shown below:
But when we enable HTTP /2, there is almost no limit to the number, as shown below:
You will notice that these resources are all loaded at the same time, and there is no need to queue the later resources. In other words, you can transmit as fast as you theoretically have bandwidth. The actual effect was repeated 5 times with one page on my blog site, and compared to the average load time was only 4% faster. This is not obvious in my example, but it does not mean that HTTP 2 is useless. It would have been better if Nginx had also used HTTP /2 to connect to business services.
The transfer model looks like this, as shown below (image from Google Developer documentation) :
Data is transferred over the same connection in the form of frames, and the service can Push resources to the client ahead of time.
(2) Server Push
As you can see in the two loading images above, other resources will not start loading until the first resource HTML is loaded, because they are HTML-triggered loading. For example, the IMG tag will load an image, so the other resources will not load until the HTML is loaded and parsed. Http2, on the other hand, allows the service to push other resources that are likely to be requested by the client to you, rather than waiting for the request to be sent, thus improving the overall page load speed. Nginx does not currently support Server Push, but you can download an http2 node. js package and write a demo.
response.push('/img/banner.png');Copy the code
(3) Packet header compression and binary encoding
Since the data transmitted through HTTPS is encrypted, this process cannot be observed using packet capture tools, so we can do some theoretical analysis.
The advantage of using binary transmission is that it is closer to the characteristics of computer storage. The traditional form of text stream transmission has some parsing complexity. For example, the parsing of Message Length should be divided into five cases, as detailed by W3C, while using binary mode does not have this problem. Note that the binary form of HTTP /2 does not change the HTTP /1.1 architecture, just the format of the transmission packet, as shown in the following figure:
The figure above shows two frames, a header frame and a data frame.
Header compression looks like this, as shown below:
The client sends two requests. The first request has a complete HTTP header, and the second request only has a different PATH field. However, this time it only needs to send one PATH field, which greatly reduces the amount of requests. The implementation of this requires both the client and the service to maintain a header table. The 4KB less traffic mentioned above is most likely a result of this savings. This makes a lot of sense, because dynamic requests can sometimes send only a few bytes of data, but a header of several hundred bytes (500-800).
One last question, how compatible is HTTP/2? As shown in Caniuse:
IE11 only in Windows 10 support, Chrome/Safari/Firefox/Opera browser support HTTP/HTTPS only 2.
What if the browser doesn’t support HTTP /2? Can also be opened normally, why? Since a handshake is required to establish an HTTPS connection, the browser or Client sends a Client Hello package that specifies whether it supports HTTP2, as shown in the following figure:
Nginx can then decide whether to use HTTP /2 based on the handshake information, or HTTP /1.1 if the client does not support it. Here’s one way to see why browsers need to use HTTPS and service support ALPN.
Reference:
-
Introduction to HTTP/2 – Google Developer Documentation
- Why Everyone Should Be Moving To HTTP/2
- HTTP/2 Frequently Asked Questions
Extension:
- Why upgrade to HTTPS
- What happens in the first few milliseconds of an HTTPS connection
- WebSocket and TCP/IP