What did HTTP/2 do wrong? Just two brilliant years are about to be abandoned! ?

GitHub 19K Star Java engineer into god road, don’t come to understand it!

GitHub 19K Star Java engineer into the way of god, really don’t come to understand it!

GitHub 19K Star Java engineer into the way of god, really really don’t come to understand it!

HTTP/3 has been in the news a lot lately, and more and more large international companies have started using HTTP/3.

So, with HTTP/3 already in the works, it’s only a matter of time before it’s fully available, so it’s time for us, as leading developers, to understand what HTTP/3 is and why we need it.

So I started to write this article, but the only thing I couldn’t get around to talking about HTTP/3 was HTTP/2, so as it got longer and longer, I split it into two parts.

In this article, we will review HTTP/2, and then focus on what is wrong with HTTP/2 and why it should be deprecated.

HTTP/2 is not brilliant?

Although the HTTP/2 standard was officially released as RFC 7540 in May 2015, it was supported by most browsers by the end of 2015.

Real widespread use, however, is not expected until around 2018, but it was also in November 2018 that the IETF gave official approval to make HTTP-over-Quic HTTP/3.

Back in 2018, I wrote an article on what the Hell IS HTTP/2? At the time, HTTP/2 was still a new technology and was just beginning to be supported by software. Two short years later, HTTP/3 has quietly arrived.

** According to W3Techs, as of June 2019, only 36.5 percent of websites globally support HTTP/2. ** So, HTTP/3 May have arrived before many websites started to support HTTP/2.

So, for many sites, upgrading directly to HTTP/3 May be a better option.

Review the HTTP / 2

Before reading this article, I strongly recommend reading what is HTTP/2? This article, which introduces the history of HTTP, introduces the various versions of the HTTP protocol birth background.

By the time you read this, I assume you have a basic understanding of HTTP/2.

As we know, HTTP/2 was created primarily to solve the efficiency problem in HTTP/1.1. The core technology in HTTP/2 is multiplexing, which allows multiple request-response messages to be sent simultaneously over a single HTTP/2.0 connection.

At the same time, it also implements binary frame splitting, header compression, server push and other technologies.

In the 24 years since THE birth of HTTP/1.0 to HTTP/2, THE HTTP protocol has been upgraded three times, but there is one key technical point that remains unchanged, that is, all of the HTTP protocol is based on the TCP protocol.

Flowing HTTP, iron TCP. This is because TCP is more reliable than UDP.

Although the introduction of HTTP/2 on top of HTTP/1.1 has greatly improved efficiency, many people consider it to be a “temporary solution”, which is why the industry has already invested heavily in THE development and promotion of HTTP/3.

And the deep reason behind this is because it is based on TCP protocol implementation. Although TCP protocol is more reliable, but there are still some problems, the next specific analysis.

HTTP / 2 issues

Team head block

The term head-blocking is not new, since head-blocking has been a problem since the HTTP/1.1 era.

But many people will see arguments in some sources that HTTP/2 solves the congestion problem. But this is only half true.

HTTP/2 solves the HTTP queue header problem, but it does not solve the TCP queue header problem!

If you know anything about the history of HTTP, you know that. The major improvement over HTTP/1.0 is the introduction of keep-alive connections.

Persistent connections are the ability to transmit multiple HTTP requests and responses over a SINGLE TCP connection, reducing the cost and latency of establishing and closing connections.

With the introduction of persistent connections, the HTTP protocol has improved significantly in terms of performance.

In addition, HTTP/1.1 allows the use of request pipes over persistent connections, which is another performance optimization over persistent connections.

A request pipeline is a place where multiple requests can be queued before the HTTP response arrives. By the time the first HTTP request makes its way across the network to the server, the second and third requests can be sent. In high-latency networks, this can reduce the network loopback time and improve performance.

However, there are some limitations and requirements to piping, one of which is that the server must send back HTTP responses in the same order as the request.

This means that if there is a delay in the return of a response, subsequent responses will be delayed until the response from the head of the queue arrives. This is known as HTTP queue header blocking.

But the problem of HTTP queue header blocking is effectively addressed in HTTP/2. HTTP/2 scrapped the piped approach and introduced innovative concepts such as frames, messages, and data streams. A client and server can split an HTTP message into separate frames, send them out of order, and reassemble them at the other end.

Since there is no order, there is no need to block, effectively solving the problem of HTTP blocking queue headers.

However, HTTP/2 still has the problem of TCP queue header blocking because HTTP/2 relies on TCP.

During TCP transmission, data is divided into sequential packets. These packets are transmitted to the receiving end over the network. The receiving end combines these packets into original data in sequence, thus completing data transmission.

But if one of the packets does not arrive in the right order, the receiver will hold the connection waiting for the packet to return, blocking subsequent requests. This causes TCP queue header blocking.

The pipelinized persistent connections of HTTP/1.1 also allow the same TCP connection to be used by more than one HTTP, but HTTP/1.1 allows six TCP connections to a domain name. In HTTP/2, the same domain name is just a TCP connection.

Therefore, in HTTP/2, the effect of TCP queue blocking is even greater because of the multiplexing technology of HTTP/2, which means that multiple requests are based on the same TCP connection, so if one request causes TCP queue blocking, multiple requests will be affected.

TCP Handshake Duration

When you think of TCP, the first thing that comes to mind is its three-handshake and four-close feature.

Because TCP is a reliable communication protocol, and this reliability is achieved by the three-way handshake, through the three-way handshake, TCP in the transmission process can ensure that the data received by the receiver is complete, orderly, error-free.

The problem, however, is that a three-way handshake takes time, and here’s a concept about network latency.

Network delay is also called Round Trip Time (RTT). It refers to the time it takes for a request to send a request packet from the client browser to the server and receive a response packet from the server. RTT is an important indicator of network performance.

As we know, the TCP three-way handshake requires three interactions between the client and the server, which means 1.5 RTT is consumed.

In addition, if the secure HTTPS protocol is used, the TLS protocol needs to be used for secure data transfer. This process consumes another RTT (handshake mechanism is different between different versions of TLS).

So a pure HTTP/2 connection consumes 1.5 RTTS, and an HTTPS connection consumes 3-4 RTTS.

The specific time consumed varies according to the distance between the server and the client. If the distance between the server and the client is relatively close, the time consumed is less than 100ms, which may not be perceived by users. However, if the time of an RTT reaches 300-400ms, then the total time of a connection establishment may reach about one second. Users will notice that the page is slow to load.

Is TCP upgrade feasible?

Based on the problems we’ve mentioned, many people have asked: Since TCP has these problems, and we know about them, and even the solution is not difficult to think about, why not do an upgrade to the protocol itself to solve these problems?

In fact, this involves a “rigid agreement” problem.

So when we look at data on the Internet, the data transfer process is extremely complicated.

As we know, there are several premises to use the network at home. First, we need to open the network through the operator, and we need to use a router, which is an intermediate device in the process of network transmission.

Intermediate equipment refers to the auxiliary equipment inserted between the data terminal and the signal conversion equipment to perform some additional functions before modulation or after demodulation. Hubs, switches and wireless access points, routers, secure demodulators, communication servers, and so on are all intermediate devices.

There are many, many more of these mediums out there, and a network needs to be forwarded through countless mediums to reach the end user.

If the TCP protocol needs to be upgraded, then it means that all of these intermediates need to be able to support the new features. We know the router and we can replace it, but what about the other intermediates? Especially the larger devices? The cost of replacement is enormous.

Also, in addition to the middleware, the operating system is an important factor, because the TCP protocol needs to be implemented through the operating system kernel, and the operating system update is also very late.

Therefore, this kind of problem is called “intermediary inflexible”, is also leads to “agreement inflexible” important reason. This is also an important reason to limit the update of THE TCP protocol.

As a result, many of the new TCP features standardized by the IETF in recent years have not been widely deployed or used due to a lack of widespread support!

Give up TCP?

The root cause of all the problems mentioned above is that HTTP/2 is based on the TPC implementation, and TCP itself is difficult to upgrade.

The only solution left, then, is to abandon TCP.

Abandoning TCP leaves you with two options: use an existing protocol or create a new one.

As the smart reader must have figured out, creating new protocols can also be affected by the rigidities of the middleware. In recent years, efforts to create new transport layer protocols have largely failed because of the difficulty of deploying them over the Internet!

Therefore, the only way to upgrade to the new HTTP protocol is to make some modifications and support based on the existing protocol, and UDP is a good choice.

conclusion

Because HTTP/2 is implemented using TCP protocol, although the solution to the HTTP queue header blocking problem, but for the TCP queue header blocking problem is powerless.

During TCP transmission, data is divided into sequential packets. These packets are transmitted to the receiving end over the network. The receiving end combines these packets into original data in sequence, thus completing data transmission.

But if one of the packets does not arrive in the right order, the receiver will hold the connection waiting for the packet to return, blocking subsequent requests. This causes TCP queue header blocking.

In addition, the reliable transmission of TCP is achieved by the three-way handshake, which requires three interactions between the client and the server, that is, 1.5 RTT is consumed. If it’s HTTPS then it consumes more RTT.

However, because many intermediate devices are old and the replacement cost is huge, it is almost impossible to upgrade THE TCP protocol or adopt new protocols.

Therefore, HTTP/3 chose a new technology solution, that is based on UDP to do the modification, this technology is called QUIC.

So the question is, how does HTTP/3 use UDP? What changes have been made? How do I ensure connection reliability? UDP protocol does not have a rigid problem?

These questions will be analyzed in depth in the next article. Stay tuned!

References:

http3-explained.haxx.se/

baike.baidu.com/item/ Intermediate /3…

Time.geekbang.org/column/arti…

Juejin. Cn/post / 684490…

Time.geekbang.org/column/arti…

About the author: Hollis, a person with a unique pursuit of Coding, is an Alibaba technologist, the co-author of three Courses for Programmers, and the author of a series of articles on how Java Engineers Become Gods.

If you have any comments, suggestions, or want to communicate with the author, you can follow the public account [Hollis], directly leave me a message in the background.