Simple answer:
HTTP/2 multiplexes TCP connections. In one connection, both the client and the browser can send multiple requests or responses at the same time, and there is no need for one-to-one correspondence in order.
For example, in a TCP connection, the server receives the A request and the B request at the same time, so it responds to the A request first, and finds that the processing process is very time-consuming, so it sends the processed part of the A request, and then responds to the B request, After completion, send A to request the rest.
Explanation of historical reasons:
1. HTTP/1.0 version
The main disadvantage of this version is that only one request can be sent per TCP connection. After the data is sent, the connection is closed. If you want to request other resources, you must create a new connection. To solve this problem, Connection: keep-alive this field needs to be used.
2. HTTP/1.1 version
This version introduces a persistent connection (persistent connection), that is, the TCP connection is not closed by default and can be reused by multiple requests without declaring Connection: keep-alive. The pipeline mechanism (pipelining) is also introduced, that is, in the same TCP connection, the client can send multiple requests at the same time. This further improves the efficiency of the HTTP protocol.
Although version 1.1 allows multiplexing of TCP connections, in the same TCP connection, all data communications are performed sequentially. The server will not proceed to the next response until it has processed one response. If the previous response is particularly slow, there will be many requests waiting in line later. This is called "head-of-line blocking".