Why is HTTP 2.0 designed this way?

HTTP 1.0 was released in 1996, laying the foundation for the web. Three years later, HTTP

HTTP 1.1 expanded its functionality. Sixteen years later, HTTP 2.0 was released in 2015.

You may think that after such a long time, and with the version number increased from 1 to 2, there must be a lot of new features. In fact, HTTP 2.0 has no new features, but only optimized performance.

Why is there such a big version upgrade to optimize performance? Is the performance of HTTP 1.1 so poor?

So let's take a look at what the problems are with HTTP 1.1:

HTTP 1.1 Issues

As we know, the underlying protocol of HTTP is TCP, which requires a three-way handshake to establish a connection. In HTTP 1.0, the connection will be disconnected after a request and response are completed, so the next request will require another three-way handshake to establish a connection.

In order to reduce the consumption of establishing TCP connections, HTTP 1.1 supports keep-alive. As long as the request or response header carries Connection: keep-alive, you can tell the other party not to disconnect the connection first, because I will use this connection to send messages later. When you need to disconnect, specify the Connection: close header.

In this way, the same TCP connection can be used for multiple HTTP request responses:

Although this reduces the number of links to be established, it has performance issues because the next request must wait for the previous request to return a response before it can be sent.

This problem has a name, called head-of-line blocking, which is easy to understand, because multiple requests have to queue up, and if the front of the line is stuck, the ones behind it cannot be executed.

How to solve this problem?

HTTP 1.1 introduced the concept of pipeline, which means that multiple requests can be sent in parallel and processed in sequence after the responses are returned.

That is:

In fact, this can partially solve the problem, but the returned responses still need to be processed one by one, and the problem of head-of-line blocking cannot be solved.

Therefore, pipelining is a relatively useless feature. Most browsers now have it turned off by default or even do not support it.

So how can we solve this head-of-line blocking problem?

Why not just open multiple teams?

The browser will generally establish 6-8 TCP links with the same domain name, that is, 6-8 queues. If a queue is blocked by the head of line, it will be placed in other queues.

This alleviates the head-of-line blocking problem.

If we want to open the web pages we write as quickly as possible, we should take advantage of this, such as deploying static resources under different domain names. In this way, each domain name can send 6-8 download requests in parallel, and the web page will open much faster.

This optimization method is called "domain sharding", and CDN generally supports this.

In addition to the head-of-line blocking problem, are there any other problems with HTTP 1.1?

Yes, for example, the header is too large.

I don’t know if you have noticed that even if you only transmit a few characters, you still have to bring a lot of headers:

Moreover, these headers are all text, so they take up a lot of space.

For example, if it is binary, 1 bit is enough to represent true and false, but text must be encoded, so "true" takes up 4 bytes, which is 32 bits. That's a 32-fold difference!

Therefore, when using HTTP 1.1, we should try to avoid small requests, because even if the request content is small, it will carry a large header. This is especially problematic when there are cookies.

Therefore, our web pages need to be packaged, that is, we need a packaging tool to merge modules into multiple chunks for loading. We need to merge small images into large images and use them by adjusting background:position. We need to inline some css, images, etc. And the domain name of static resources must not carry cookies.

These are all to reduce the number of requests to improve loading performance.

Moreover, the underlying layer of HTTP is TCP, which can actually transmit data in both directions. However, it can only be transmitted through the request-response method, which does not fully utilize the capabilities of TCP.

After talking so much, I wonder if you have the urge to optimize it.

It is because of these problems that HTTP 2.0 came into being. It made many performance optimizations and basically solved the above problems.

So what optimizations have been made in HTTP2?

HTTP 2.0 Optimization

Let’s not rush to see how HTTP 2.0 is optimized. As for the above problems, if we were asked to solve them, how would we solve them?

For example, the problem of head-of-line blocking, that is, the second response can only be processed after the first response is processed. How to solve it?

This is easy to solve. Each request and response is given an ID, and each response can find its corresponding request through the ID. Each goes back to its own place, so there is no need to block and wait.

For example, how to solve the problem of header being too large?

Text transmission takes up too much space, would it be much better to switch to binary?

Also, there are many identical headers in each transmission. Can we create a table and only transmit the subscripts when transmitting?

Also, the body can be compressed, so can the header be compressed?

It should be much better after this treatment.

What about not fully utilizing the capabilities of TCP and only supporting the request-response approach?

Then the server is supported to actively push messages, but the client can choose to receive or not.

The above is our thinking on the solutions to these problems. Let's take a look at how HTTP2 solves these problems:

HTTP2 does associate requests and responses through IDs, and it calls this concept stream.

And as we said before, the header needs to be optimized separately, so the header and body parts are transmitted separately, which are called different frames.

Each frame has the following format:

The payload part is the content of the transmission, there is nothing much to say about it.

The header starts with the length, followed by the frame type. There are several types:

• SETTINGS frame: configuration information, such as maximum frame size, whether server push is supported, etc.
• HEADERS frame: request or response header.
• DATA frame: The body of the request or response.
• CONTINUATION frame: When one frame is not enough, it can be divided into frames, which can be used to reference the previous frame.
• PUSH_PROMISE frame: The frame in which the server pushes data.
• END_STREAM frame: indicates the end of stream transmission.
• RST_STREAM frame, used to terminate the current stream.

Among these frames, there is nothing much to say about HEADERS and DATA frames.

The SETTING frame is configuration information, which tells the other party what is supported and how large the frame size is set.

There is an upper limit to the frame size. If the frame is too large, it can be divided into multiple frames. In this case, the frame type is CONTINUATION. It is also easy to understand.

HTTP2 does support server push, and the frame type is also separate, called PUSH_PROMISE.

The stream is used to transmit request responses or server pushes. When the transmission is completed, you can send an END_STREAM frame to indicate that the transmission is complete, and then transmit a RST_STREAM frame.

to end the current stream.

Now that we have explained the frame types, let's move on to the flags field. This field contains different contents in different frame types:

For example, the header frame will set the priority in the flags so that high-priority streams can be processed earlier.

In HTTP 1.1, all requests are processed in queues, and there is no priority. However, HTTP 2.0 implements concurrent requests through streaming, so the priority can be controlled naturally.

There is also an R at the end, which is of no use now and is a reserved bit.

The stream identifier following it is the stream id, which is used to associate multiple frames of the same stream.

After explaining the frame format, you may be a little confused. Indeed, there are many types of frames. The frames are sent in different orders, and different frames are sent in different states, which will also change the state of the stream.

Let's look at the state machine of the stream, that is, what state the stream will enter when it receives a frame, and what frame it will send in what state:

(If you don't understand, you can read on)

At the beginning, the stream is in idle state, that is, idle.

After receiving or sending a HEADERS frame, the device enters the open state.

Multiple DATA frames can be sent or received in the oepn state.

After sending or receiving an END_STREAM frame, the device enters the half_closed state.

Receiving or sending a RST_STREAM frame in the half_closed state closes the stream.

This process is easy to understand. It sends HEADER first, then DATA, and then tells the other party to end, which is END_STREAM, and then closes RST_STREAM.

But HTTP2 can also push data from the server, so there is another state transition process.

The stream is in the idle state at the beginning.

After receiving the PUSH_PROMISE frame, that is, the data pushed by the server, it becomes reserved.

The reserved state can send or receive headers again, and then enter the half_closed state.

The subsequent process is the same, also END_STREAM and RST_STREAM.

This process is unique to HTTP2, that is, data is pushed first, then headers are sent, and then the stream ends.

This is the process of sending a request, response, or server push in http2, all of which are encapsulated in a stream.

Streams can be concurrent and have priorities set, so there is no head-of-line blocking problem. This feature is called multiplexing, which means reusing the same link to establish multiple channels (streams).

And the transmitted header frame is also processed. As we said before, it will be represented in binary format for compression. The compression algorithm is specially designed and is called HPACK:

Both ends maintain an index table and use subscripts to identify headers, which reduces the amount of transmission:

First of all, there are more than just headers in the header. There is also a request line of GET xxx/xxx and a response line of 200 xxx. In order to unify the processing, it is replaced with headers such as :host :path to represent it.

In this way, when sending, you only need to send the subscript:

For example, :method: get only needs to send 2: get.

This code is also set according to the frequency. High frequency uses small code. This method is called Huffman coding.

This achieves header compression.

So far, the main features of HTTP2.0 have been discussed, namely multiplexing, server push, header compression, and binary transmission.

The most important feature is multiplexing, that is, streams and frames, and what frames are sent in what state. Other features are designed around this.

Let's go back and see if all the problems with HTTP1.1 have been solved:

Head-of-line blocking: Requests and responses are identified by streams, and the same stream is divided into multiple frames for transmission. Multiple streams can run concurrently without blocking each other.

The header is too large: By using binary format and HPACK compression algorithm, the header is much smaller.

The features of TCP are not fully utilized: server push is supported.

It seems that HTTP2.0 does solve the problems of HTTP 1.1.

It seems that HTTP 2.0 is already perfect?

Actually not. Although there is no head-of-line blocking problem at the HTTP level, and multiple request responses can be processed in parallel, multiple frames of the same stream still have head-of-line blocking problems, because the TCP level will ensure sequential processing and retransmission if lost, which means that if the previous frame is not received, the next frame cannot be processed.

This problem is caused by the reliable transmission feature of TCP, so if you want to completely solve the head-of-line blocking problem, you can only replace the underlying transmission protocol of HTTP.

This is what HTTP3 does, and its transport layer protocol is changed to UDP. Of course, HTTP3 is not very mature yet, so we can focus on HTTP2 first.

Summarize

HTTP 1.0 was released in 1996, HTTP 1.1 in 1999, and HTTP 2.0 in 2015.

There were 15 years between 1.1 and 2, and a lot did change, but only to optimize performance.

The problem with 1.1 is that the second request can only be sent after the first response. Even if pipelining is used, there will still be blocking between multiple responses. This is the "head of line blocking" problem.

Moreover, the header part is too large and is in plain text, which may be more than the body part.

To address the head-of-line blocking problem of 1.1, we will perform domain sharding. To address the problem of too large headers, we will reduce the number of requests, that is, packaging into chunks, inlining resources, sprite sheets, prohibiting cookies in static resource requests and other optimization strategies.

HTTP 2.0 solves these problems of 1.1 by multiplexing, that is, the request and response are in one stream, and multiple frames are associated with the same stream id to transmit data. Multiple streams can be concurrent.

We looked at the frame format, which includes length, type, stream id, flags, and payload.

There are many types of frames, including HEADRS, DATA, SETTINGS, PUSH_PROMISE, END_STREAM, EST_STREAM, etc.

These frame types are not unrelated. The stream will send and receive different frames in different states, and sending and receiving different frames will also enter different states.

To understand HTTP2.0 stream, you need to understand such a state flow process.

In addition, HTTP 2.0 compresses the header through the HPACK algorithm designed separately, and also supports server push. Moreover, the content is transmitted in binary format, which solves the problems of HTTP 1.1.

However, the underlying layer of HTTP 2.0 is TCP, and its reliable transmission feature means that multiple frames in the same stream are still transmitted sequentially, and there is still a head-of-line blocking problem. This is also because HTP 3 changes the underlying protocol to UDP.

Although there are still some problems, HTTP 2.0 has basically optimized all the performance issues of HTTP 1.1 to the extreme, and it is a very meaningful version upgrade.