Read HTTP/2 characteristics

HTTP/2 is the first update to the HTTP protocol since the 1999 HTTP 1.1 release, primarily based on the SPDY protocol. Developed by the hypertext Transfer Protocol Bis (httpbis) Working Group of the Internet Engineering Task Force (IETF). The organization submitted the HTTP/2 standard proposal to IESG for discussion in December 2014 and was approved on February 17, 2015. The HTTP/2 standard was formally published in May 2015 in RFC 7540.

What are the specific changes in the HTTP/2?

Binary Sub-frame

To understand several concepts first:

FRAME: HTTP/2 minimum unit message for data communication: Refers to the logical HTTP message in HTTP/2. such as requests and responses, messages are made up of one or more frames.

Stream: A virtual channel that exists in the connection. A stream can host two-way messages, each with a unique integer ID.

HTTP/2 transfers data in binary format, rather than HTTP 1.x text format, the binary protocol is more efficient to parse. HTTP/1 's request and response messages are made up of the starting line, the header and the entity body (optional), separated by a text-newline character. The HTTP/2 splits the request and response data into smaller frames, and they are encoded in binary.

In HTTP/2, all communications under the same domain name are completed on a single connection that can host any number of bidirectional traffic. Each data stream is sent as a message, and the message is made up of one or more frames. Multiple frames can be sent in random order, according to the frame header flow identification can be reassembled.

Multiplexing

Multiplexing, instead of the original sequence and blocking mechanism. All that is requested is done concurrently through a TCP connection. HTTP 1.x, if you want to concurrent multiple requests, you must use multiple TCP links, and the browser in order to control resources, there will be a single domain name 6-8 TCP link request limit, for example, red circled requests because the number of domain links has exceeded the limit, and was suspended waiting for a period of time:

In HTTP/2, with binary sub-frames, HTTP/2 no longer relies on TCP links to implement multi-stream parallelism, in HTTP/2:

• All communications under the same domain name are completed on a single connection.

• A single connection can host any number of bidirectional data streams.

• The data stream is sent as a message, and the message is made up of one or more frames, and multiple frames can be sent in random order, because the flow ID of the frame header can be reassembled.

This feature allows for a significant improvement in performance:

• The same domain name requires only one TCP connection, eliminating the latency and memory consumption caused by multiple TCP connections.

• Requests and responses can be interleaved in parallel on a single connection, not interfering with each other.

• In HTTP/2, each request can take a 31bit priority, 0 represents the highest priority, and the higher the value, the lower the priority level. With this priority value, the client and server can take different policies when dealing with different streams, sending streams, messages, and frames in an optimal manner.

Server push

The server can actively push other resources when the page HTML is sent, rather than wait until the browser resolves to the appropriate location, initiating the request and responding. For example, the server can proactively push JS and CSS files to the client, without requiring the client to parse the HTML before sending these requests.

The server can be actively pushed, the client also has the right to choose whether to receive. If the server pushes a resource that has been cached by the browser, the browser can reject it by sending a rst_stream frame. Proactive push also adheres to the same-origin policy, the server does not casually push third-party resources to the client.

Head compression

The size of the HTTP 1.1 request becomes larger and sometimes larger than the initial size of the TCP window, because they need to wait for a response with an ACK back before they can continue to be sent. HTTP/2 compresses the message header with Hpack (a compression format designed for the HTTP/2 head), which saves traffic on the network that the message header occupies. and http/1.x each request, will carry a large number of redundant head information, wasting a lot of bandwidth resources.

HTTP Each communication carries a set of headers that describe the resources, browser properties, cookies, etc. for this communication, such as

To reduce the resource consumption and improve performance of this block, HTTP/2 has adopted a compression strategy for these headers:

• HTTP/2 uses the "Header table" on both the client and server side to track and store previously sent key-value pairs, and for the same data, it is no longer sent through each request and response;

• The first table is always present during the HTTP/2 connection, and is incrementally updated by both the client and the server;

• Each new header key-value pair is either appended to the end of the current table or replaces the previous value in the table.

For example: In two requests, the request sends all the header fields, and the second request only sends the difference data, which reduces redundant data and reduces overhead.

Let's take a look at a practical example, below is a wireshark crawl to access the Google home page package:

is to access the https://www. google.com/ caught the head of the first request, can see the contents of the head, a total of occupied 437 bytes, we select the head of the cookie, you can see the total amount of cookies occupied 118 bytes. Next we look at the head of the second request:

As you can see, thanks to head compression, the second request has a cookie that only takes up 1 bytes, so let's take a look at the changed accept field:

Because the Accept field differs from the content in request one, it needs to be sent to the server, so it takes up bytes

Read HTTP/2 characteristics