What are we talking about when we talk about HTTP team head blocking?

What we're talking about when we're talking about HTTP team head blocking. What we're talking about when we're talking about HTTP team head blocking.

Recently visited the website, obviously feel the support HTTP/2 website more and more, is a good trend for the industry. HTTP/2 's RfC is very thick, but in summary it does the following:

1. Reduce latency through TCP multiplexing;

2. A single TCP connection allows disorderly request-response to solve the problem of block head blockage;

3. At the implementation level, most browsers require HTTP/2 to turn on TLS to address data security issues to some extent.

Among them, the team head blocking problem is really solved.
http/1.1 Why the team head is blocked.

http/1.1 uses pipelining pipeline technology to send multiple requests at once to improve throughput and performance, such as sequence 2 in the figure above. However, when receiving a response, this technique requires that it be returned in the order in which the request was sent. If the first request is blocked, the subsequent request will need to wait even after processing, as in sequence 3 in the figure above.

So, how did HTTP/2 solve the problem? That's the data frame: Multiple requests reuse a TCP connection, and each request-response is split into frames to send, so that even if a request is blocked, no other requests are affected, as shown in sequence 4 above. The problem was solved perfectly. Exactly, only part of the solution.

If the granularity of the team head blocking is the HTTP request level, then HTTP/2 over TCP does solve the problem in http/1.1. However, HTTP/2 is now based on TCP (yes, HTTP has never said that it must be implemented via TCP, you can use it for other transport protocols), so HTTP/2 does not solve the data transfer layer of the Head (packet) blocking problem.

As shown in the figure above, when the first packet is dropped, the TCP protocol will block and the data retransmission will occur. Although TCP has a mechanism such as fast retransmission to alleviate this problem, it can only be mitigated. cannot be completely avoided.
How to solve the problem of the queue head blocking in the transport layer.

The application layer cannot resolve the problem with the transport layer. Therefore, to completely solve the problem of team head blocking, we need to redesign and implement the transport layer. For now, the real landing in the app only sees Google's Quic (Https://www.chromium.org/quic). Its simple principle is that the use of UDP to achieve a reliable multiplexing transport layer. We know that UDP is data-oriented, and there is no blocking constraint between packets, and Quic is to take advantage of this feature to solve the problem of queue head blocking in the transport layer. Of course, Quic's protocol implementations have a lot of detail, and Google does very well, and if you want to learn more about them, you can focus on their open source implementations (https://chromium.googlesource.com/chromium/src/+/ master/net/quic/).
Summary

1. HTTP/2 over TCP (our most visited HTTP/2) solves the problem of queue header blocking at HTTP request level

2. HTTP/2 over Quic solves the problem of team head blocking in the transport layer, which is what we understand to really resolve the issue.

Source: https://liudanking.com/arch/what-is-head-of-line-blocking-http2-quic/

Copyright statement: The content source network, the copyright belongs to the original person. Unless it is impossible to confirm, we will mark the author and source, and if there is any infringement please inform us that we shall immediately delete and apologize. Thank you.