Words: 3825 words
Estimated reading time: 20 minutes
takeaway
Http2.0 is a secure and efficient next generation HTTP transport protocol. Secure because HTTP2.0 is based on the HTTPS protocol, efficient because it transmits data through binary framing. Because of these features, the HTTP2.0 protocol is being supported by more and more websites. As of August 2018, 27.9% of websites support HTTP2.0.
This article will provide a detailed overview of Http2.0 in terms of principles, practices, and testing. Hopefully, it will deepen your understanding.
What is the HTTP2.0 protocol?
Http2.0 官网
HTTP /2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; http methods, status codes and semantics are the same, and it should be possible to use the same APIs as http/1.x (possibly with some small additions) to represent the protocol.
The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.
The basis of The work was SPDY, but HTTP /2 has evolved to take The community’s input into account, incorporating several improvements in the process.
Chinese summary is:
● Full compatibility with 1.x protocol semantics
The 2.0 protocol is an upgrade of the 1.x protocol rather than a rewrite. The methods, states and apis of the 1.x protocol are the same in the 2.0 protocol.
● Significant improvement in performance
The 2.0 protocol focuses on the optimization of perceived latency of end users and the use of network and server resources.
Http2.0 optimizes content
01
Binary Format – the cornerstone of HTTP2.0
Http2.0 is able to overcome the performance limitations of the HTTP1.x standard, improve transport performance, achieve low latency and high throughput because of the addition of the binary framing layer.
A frame contains the following parts: Type, Length, Flags, Stream, and frame payload The payload.
Message: A complete request or response, such as a request or response, consisting of one or more frames.
A stream is a virtual channel in a connection that can host two-way messaging. Each stream has a unique integer identifier. To prevent traffic ID conflicts between the two ends, the flow initiated by the client has an odd ID, and the flow initiated by the server has an even ID.
Flow identifiers are a format that describes binary frames so that each frame can be sent over HTTP2. Associated with flow identifiers is a stream, each stream is a logical connection, an independent bidirectional frame exists in the HTTP2 connection between client and server. An HTTP2 connection can contain multiple concurrent open streams, and the number of concurrent streams can be set by the client.
At the binary framing layer, HTTP2.0 will divide all transmission information into smaller messages and frames, and use binary encoding to encapsulate them. The new binary framing layer can also ensure that HTTP verbs, methods, headers are not affected, compatible with the previous generation of HTTP standards. Where the header information in http1.X is encapsulated in the Headers frame, and the Request body is encapsulated in the Data frame.
02
Multiplexing/connection sharing
In HTTP1.1, the browser client has a limit on the number of requests for the same domain name at any one time, and the number of requests exceeding this limit will be blocked. This is one of the reasons why some sites have multiple static resource CDN domains.
Multiplexing in HTTP2.0 optimizes this performance. Multiplexing allows multiple request-response messages to be sent simultaneously over a single HTTP /2 connection. With the new framing mechanism, HTTP /2 no longer relies on multiple TCP connections for multi-stream parallelism. Each data stream is broken up into discrete frames that can be interleaved (sent out of order), prioritized, and finally reassembled at the other end.
HTTP 2.0 connections are persistent, and only one connection (one connection per domain name) is required between the client and server. An HTTP2 connection can support the multiplexing of tens or hundreds of streams. Multiplexing means that packets from many streams can be mixed together and transmitted over the same connection. When the destination is reached, the different data streams are reconnected according to the stream identifiers at the head of different frames.
The figure above shows multiple transmission streams on a single connection: the client sends data frames Stream5 to the server, while the server sends stream1 and Stream3 out of order to the client. There are three out-of-order parallel exchanges of response requests on this connection.
The figure above shows the difference between http1.x and HTTP2.0 when transferring data. Http1.1 和 HTTP2.0
Http1.1 process: freighter 1 from A to B to pick up the goods, after picking up the goods, from B to return, and then freighter 2 in A return and unload the goods before starting to pick up the goods from A to return, so orderly round trip.
Http2.0 process: freighters 1, 2, 3, 4, 5 all disordered from A, pick up the goods and return, and then unload the corresponding cargo according to the freighter plate.
Obviously, the second way to transport more goods, river utilization rate is high.
03
Header Compression
The http1.x header carries a lot of information and is sent repeatedly each time. HTTP /2 uses encoder to reduce the size of headers that need to be transmitted, and the communication parties cache a header field table respectively, so as to avoid repeated transmission of headers and reduce the size of headers that need to be transmitted.
Instead of sending the same data through each request and response, generic key-value pairs (user agents, acceptable media types, and so on) are sent once with little change during communication.
In fact, if the request does not contain headers (such as a polling request for the same resource), then the header overhead is zero bytes, and all headers automatically use the headers sent by the previous request.
If the header changes, you simply add the change to the header frame, and the change is added to the header field table, which exists throughout the lifetime of the HTTP 2.0 connection and is progressively updated by both the client and the server.
It should be noted that HTTP 2.0 focuses on header compression, while gZIP is commonly used for packet content (body) compression. The two not only do not conflict, but can achieve better compression effect together.
HTTP /2 uses the HPACK② algorithm, designed specifically for top compression.
As you can see from the figure above, http1.X does not support header compression, while http2.0’s compression algorithm works best, sending and receiving the least amount of data.
04
The compression principle
Replace the actual header with an index in the header field table.
HTTP /2’s HPACK algorithm uses an index table to define commonly used HTTP headers, stores the commonly used HTTP headers in the table, and only sends the index location in the table when requested.
For example, method=GET uses index 2, and path=/index.html uses index 5, as shown in the following figure:
HPACK Static Table 3
If the server sends a Frame, the Payload of the Frame is 0x8285, and the Frame Type is set to Header, it indicates that the Frame belongs to the HTTP Header. The request content is as follows:
1GET /index.html
Copy the code
Why 0x8285 instead of 0x0205? This is because the high level is set to 1 to indicate that the byte is a fully indexed value (both key and value are in the index).
Similarly, the high flag bit can tell whether the byte is a fully indexed value, whether only key is indexed, or whether neither key nor value is indexed (see OkHttp3 implementation of HTTP/2 header compression ④).
Because the size of the index Table is limited, it only stores some commonly used HTTP headers, and each request can also dynamically append a new HTTP Header cache to the end of the Table. The Dynamic part is called the Dynamic Table. Static tables and Dynamic tables are combined to form index tables:
Not only does HPACK reduce the amount of data by indexing key-value pairs, but it also compresses the string size by Hofman encoding.
Take the common user-Agent as an example. Its index value in a static table is 58. Its value does not exist in the table because its value is variable. On the first request, its key is 58, indicating that it is a user-agent, and its value part is Huffman-encoded (if the encoded string is longer, it is not).
After receiving the request, the server will add the user-agent to the Dynamic Table cache and assign a new index value. The next request from the client, assuming that the index position of the last request for user-Agent is 62, just send 0xBE (again, high position 1) to represent: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.146 Safari/537.36.
The process is shown in the figure below:
Eventually, the same Header only needs to send the index value, and the new Header is readded to the Dynamic Table.
05
Request Priorities
By dividing HTTP messages into many individual frames, you can further optimize performance by optimizing the interleaving and transmission order of these frames. Each stream can have a priority value of 31 bits: 0 indicates the highest priority; Two to the thirty-first is the lowest priority.
The server can control the allocation of resources (CPU, memory, bandwidth) based on the priority of the stream, and send the highest priority frame to the client first when the response data is ready. High-priority streams should be sent first, but not absolutely. Absolute adherence may again introduce the problem of first-queue blocking: slow high-priority requests block delivery of other resources.
A mixture of priorities is also required to allocate processing resources and bandwidth between client and server. The client will specify which stream is the most important, with dependency parameters, so that one stream can depend on another. Priority levels can change dynamically at run time, telling the browser which image is most important as the user scrolls through the page, or you can filter through a set of streams to suddenly catch the focus stream.
● Highest priority: main HTML
● High priority: CSS files
● Priority: JS file
● Low priority: pictures
06
Server Push
The server can send multiple responses to a client request, and the server pushes resources to the client without the client explicitly requesting them. In addition, the server push can send the resources required by the client to the client along with index.html, saving the step of repeated requests by the client.
Because there are no requests, connections, etc., static resources can be pushed by the server to greatly improve the speed. Server Push makes http1.x era optimizations using embedded resources meaningless; If a request is made from your home page, the server will probably respond with the home page content, logo, and style sheet because it knows the client will use them, which is equivalent to gathering all the resources in one HTML document.
However, in comparison, server push has a big advantage: it can be cached! It also makes it possible to share cached resources between different pages while following homology.
Two points to note:
1. Push follows the same origin policy;
2. This server push is determined based on the request response of the client.
When a server wants to PUSH a resource, it sends a Frame of Type PUSH_PROMISE with the Stream ID that PUSH will create. It tells the client: I’m going to send you something with this ID, and the client is ready to go. When the client parses the Frame and finds that it is of type PUSH_PROMISE, it is ready to receive the stream that the server is pushing.
Http2.0 performance bottlenecks
Enabling HTTP2.0 provides significant performance improvements, but also introduces new performance bottlenecks. Because all the pressure is now concentrated on the bottom TCP connection, TCP is likely to be the next performance bottleneck, such as the problem of blocking at the head of the TCP packet. The loss of a single TCP packet causes the whole connection to be blocked, and all messages will be affected. In the future, server-side optimization for TCP configuration under HTTP 2.0 will be critical.
01
How to upgrade the HTTP2.0 protocol
The nginx server must meet the following requirements when upgrading the HTTP2.0 protocol:
1. Nginx version later than 1.9.5;
–with-http_ssl_module –with-http_v2_module –with-http_ssl_module
— with-http_SSL_module module because http2.0 is an HTTPS protocol.
02
View your Nginx configuration
nginx -V
This is the corresponding module has been added. None of these modules need to be manually compiled and installed.
03
Find the nginx file directory
04
Compile and install nginx files
1./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_v2_module
Copy the code
Then run the following command to compile and install.
1make2make install
Copy the code
05
Change the nginx configuration
Add http2 to port 443 in nginx.config.
06
Start the nginx
Last step, restart nginx nginx restart. At this point your site will be upgraded to the HTTP2.0 protocol.
detection
After the upgrade, how to determine your site is http2.0 protocol? There are generally several methods as follows:
Low chrome devtool
Open chrome debugging tool, check protocol in network, h2 represents http2.0 protocol, you can see that the author’s website has been upgraded;
Low site
SSL lab (5) An SSL server detects the website, performs security rating on the website, and automatically generates a detailed evaluation report based on the detection results;
When the plug-in
HTTP /2 and SPDY Indicator HTTP /2 and SPDY Indicator is a plugin that detects HTTP2.0 and SPDY protocols.
References:
[1].https://http2.github.io/
[2].http://http2.github.io/http2-spec/compression.html
[3].http://http2.github.io/http2-spec/compression.html#rfc.section.A
In [4]. HTTP: / / https://neyoufan.github.io/2017/01/06/android/OkHttp3 / HTTP2 first compression
[5].https://www.ssllabs.com/ssltest/analyze.html
Maybe you’d like to see more
(Click the title or cover of the article to view)
| sohu news recommendation algorithm is presented to you, are you care about
2018-08-30
CTR prediction model of news recommendation system
2019-04-18
The evolution of Internet architecture
2018-08-16
Join sohu technology author day group
Thousand yuan payment waiting for you!
Stamp here! ☛