What are the new features of HTTP/2 compared to HTTP/1.1? How to solve head-of-line blocking and header compression?

[[398710]]

This article is reprinted from the WeChat public account "Learn Front-end in Three Minutes", author sisterAn. Please contact the WeChat public account "Learn Front-end in Three Minutes" to reprint this article.

introduction

This article mainly introduces HTTP/2 step by step through the following four aspects:

• What has changed since HTTP/1.1 was invented?
• HTTP/1.1 protocol performance flaws
• HTTP/2 New Features
• HTTP/2 Legacy Issues

What has changed since HTTP/1.1 was invented?

If you look closely at the resources that the most popular website homepages download in recent years, you’ll find a very clear trend:

• Messages are getting bigger: from a few KB to a few MB;
• More page resources: from less than 10 resources per page to more than 100 resources per page;
• The content forms have become more diverse: from simple text content to pictures, videos, audio and other content;
• Higher real-time requirements: More and more applications require real-time performance of pages;

As shown in the figure below, the size of data transferred and the average number of resources requested have continued to grow since 2011, with no signs of slowing down (green: size of data transferred, red: average number of resources requested):

Since HTTP/1.1 was released in 1997, we have been using HTTP/1.x for quite some time, but the explosive growth of content in recent years has made HTTP/1.1 increasingly unable to meet the needs of the modern network.

HTTP/1.1 protocol performance flaws

1. High latency: page access speed decreases

Although network bandwidth has grown rapidly in recent years, we have not seen a corresponding reduction in network latency. This is mainly due to the Head-Of-Line Blocking problem.

HTTP/1.1 introduced the pipelining mechanism, which means that in the same TCP connection, the client can send multiple requests at the same time, further improving the efficiency of the HTTP protocol.

However, this requires the server to return responses in the order in which the requests were sent. When multiple files are requested sequentially, if one of the requests is blocked for some reason, all the requests queued behind it will also be blocked. This is called Head-Of-Line Blocking.

Head-of-line blocking causes bandwidth to not be fully utilized

Therefore, people have tried the following methods to solve the head-of-line blocking problem:

• Use multiple domain names: Distribute the resources of the same page to different domain names to increase the upper limit of concurrent connections, because browsers usually can only make a maximum of 6 HTTP connections to the same domain name.
• Introducing Sprite images: Merge multiple small images into a large image for browser JavaScript to cut and use. This can merge multiple requests into one request, but it brings new problems. When a small image is updated, it is necessary to request the large image again, wasting a lot of network bandwidth.
• Inline thumbnails: Encode the binary data of the image using base64 and embed the encoded data into HTML or CSS files to reduce the number of network requests;

 .icon {
    background: url(data:image/png;base64,<data>) no -repeat;
 }

Use tools such as webpack to package: package and compress multiple JavaScript files into one file, replacing multiple requests with one request. However, this brings the problem that when a js file changes, all js files in the same package need to be requested again.

Load on demand: to reduce the number of HTTP requests in the first place

2. Plain text transmission: unsafe

When HTTP/1.1 transmits data, all transmitted content is in plain text, and neither the client nor the server can verify the identity of the other party, which to a certain extent cannot guarantee the security of the data.

3. Stateless: huge head cut and repeated

Since the HTTP protocol is stateless, each request must carry an HTTP header, especially for headers that carry cookies, which are usually very large in size. In addition, there are User Agent, Accept, Server, etc., which are usually hundreds of bytes or even thousands of bytes, but the Body is often only tens of bytes.

4. Server push is not supported

HTTP/1.1 does not support server push messages, so when the client needs to get notifications, it can only continuously pull messages through a timer, which undoubtedly wastes a lot of bandwidth and server resources.

HTTP/2 New Features

In HTTP/1.x, for performance reasons, we introduced sprite sheets, inlined small images, used multiple domain names, etc. However, there were still some key points that could not be optimized, such as huge and repeated HTTP headers, unsafe plain text transmission, and the server could not actively push. To change these, the HTTP protocol must be redesigned, so HTTP/2 came out!

In 2015, HTTP/2 was released. HTTP/2 is a replacement for the current HTTP protocol (HTTP/1.x), but it is not a rewrite. The HTTP methods/status codes/semantics are the same as HTTP/1.x. HTTP/2 is based on SPDY and focuses on performance. The biggest goal is to use only one connection between the user and the website.

Judging from the current situation, some of the top-ranked sites at home and abroad have basically implemented the deployment of HTTP/2. Using HTTP/2 can bring 20%~60% efficiency improvement.

You can use this link to get a feel for how much faster HTTP/2 is than HTTP/1: https://http2.akamai.com/demo

1. Binary transfer

How does HTTP/2 achieve "breaking through the performance limitations of HTTP1.1, improving transmission performance, and achieving low latency and high throughput" without changing the semantics, methods, status codes, URIs, and header fields of HTTP/1.x?

One of the keys is to add a binary framing layer between the application layer (HTTP/2) and the transport layer (TCP or UDP).

In the binary framing layer, HTTP/2 divides all transmitted information into smaller messages and frames, and encodes them in binary format. The header information of HTTP1.x will be encapsulated into the HEADERS frame, and the corresponding Request Body will be encapsulated into the DATA frame. After HTTP/2 data framing, the "Header+Body" message structure completely disappears, and the protocol only sees "fragments".

In HTTP/2, all communications under the same domain name are completed on a single connection, which can carry any number of bidirectional data streams. Each data stream is sent in the form of a message, which in turn consists of one or more frames. Multiple frames can be sent out of order and can be reassembled according to the stream identifier in the frame header.

2. Header Compression (HPACK)

HTTP protocol does not have state, and all information must be attached to each request. Therefore, many fields of the request are repeated, such as Cookie and User Agent. The same content must be attached to each request, which wastes a lot of bandwidth and affects the speed.

HTTP/2 optimizes this by introducing a header compression mechanism. On the one hand, the header information is compressed using gzip or compress before being sent; on the other hand, the client and server simultaneously maintain a header information table, in which all fields are stored and an index number is generated. In the future, the same field will not be sent, only the index number will be sent, which increases the speed.

3. Multiplexing

Multiplexing technology is introduced in HTTP/2. Multiplexing solves the problem of browsers limiting the number of requests under the same domain name. It also makes it easier to achieve full-speed transmission. After all, opening a new TCP connection requires slowly increasing the transmission speed.

Multiplexing means that multiple streams can exist in one TCP connection. In other words, multiple requests can be sent, and the other end can know which request it belongs to through the identifier in the frame.

This feature greatly improves HTTP transmission performance, mainly in the following three aspects:

Multitasking

HTTP/2 reuses TCP connections. In one connection, both the client and the browser can send multiple requests or responses at the same time, and they do not need to correspond one by one in sequence, thus avoiding "head of line blocking"

Data Flow

HTTP/2 sends multiple requests/responses in parallel and interleaves them without affecting each other.

Therefore, the packet must be marked to indicate which request/response it belongs to.

HTTP/2 calls all packets of each request or response a data stream. Each data stream has a unique number. When a data packet is sent, it must be marked with a data stream ID to distinguish which data stream it belongs to. It also stipulates that the ID of the data stream sent by the client is always an odd number, and the ID of the data stream sent by the server is an even number.

When the data stream is halfway through being sent, both the client and the server can send a signal (RST_STREAM frame) to cancel the data stream. The only way to cancel a data stream in version 1.1 is to close the TCP connection. This means that HTTP/2 can cancel a request while ensuring that the TCP connection is still open and can be used by other requests.

Priority

In HTTP/2, each request can carry a 31-bit priority value, where 0 represents the highest priority and the larger the value, the lower the priority. With this priority value, the client and server can adopt different strategies when processing different streams and send streams, messages, and frames in the best way.

4. Server Push

HTTP/2 allows the server to actively send resources to the client without request, which is called server push.

A common scenario is that a client requests a web page that contains many static resources. Under normal circumstances, the client must parse the HTML source code after receiving the web page, find the static resources, and then send a request for the static resources. In fact, the server can anticipate that after the client requests the web page, it is likely to request static resources again, so it proactively sends these static resources to the client along with the web page.

This can reduce the delay time relatively. Of course, you can also use prefetch if the browser is compatible.

Note: The server can actively push, and the client can also actively choose whether to receive. If the resource pushed by the server has been cached by the browser, the browser can reject it by sending a RST_STREAM frame. In addition, active push also complies with the same-origin policy.

5. Improved security

For compatibility reasons, HTTP/2 continues the "plain text" feature of HTTP/1. It can transmit data in plain text as before, and does not force the use of encrypted communication. However, HTTPS is already a general trend, and major browsers have publicly announced that they only support encrypted HTTP/2. Therefore, HTTP/2 in real applications is still encrypted:

HTTP/2 Legacy Issues

Does HTTP/2 still cause head-of-line blocking?

HTTP/2 also suffers from head-of-line blocking issues, such as packet loss.

If it causes head-of-line blocking, the problem may be more serious than http1.1, because there is only one TCP connection, and subsequent transmissions have to wait for the previous one. HTTP/1.1 has multiple TCP connections, and if one is blocked, the others can still run normally.

Will there still be congestion under HTTP/2?

Network congestion is improved due to the reduction of TCP connections;

Slow start time is reduced, and recovery from congestion and packet loss is faster.

refer to

Deciphering the new features of HTTP/2 and HTTP/3: https://www.infoq.cn/article/ku4okqr8vh123a8dlccj