What problems does each generation of HTTP protocol solve?

Recently, I briefly studied the development history of the HTTP protocol and made some summaries on it.

Let's review the version evolution of HTTP one by one: HTTP/1.0 -> HTTP/1.1 -> HTTP/2.0 -> HTTP/3.0 (QUIC).

HTTP/1.0

HTTP 1.0 was first released in 1996, which stipulates that the connection between the browser and the server is only short-lived. Each browser request needs to establish a TCP connection with the server, and the TCP connection is immediately disconnected after the server completes the request processing. However, this method has defects, because the establishment of the TCP connection requires a three-way handshake, which causes each HTTP request to re-execute this cumbersome process, which is quite inefficient.

HTTP/1.1

HTTP 1.1 was released in 1997 and introduced a default persistent connection (Connection: keep-alive), eliminating the need to re-establish a TCP connection for each HTTP request. However, it did not solve the HOL (head of line) blocking problem. HOL blocking refers to when the number of parallel requests allowed by the browser is exhausted, subsequent requests need to wait for the previous request to complete.

HTTP/2.0

HTTP 2.0 was released in 2015, and it solved the HOL blocking problem by introducing multiplexing. This version divides a TCP connection into multiple streams, each of which can transmit multiple messages, and each message consists of multiple minimum binary frames. By assigning a stream ID to each user operation, a TCP channel is established with the server. This method allows each request from the client to start the next request, thus solving the head-of-line blocking at the application layer.

However, although HTTP/2.0 solves the head-of-line blocking problem at the application layer, the transport layer (TCP) still has head-of-line blocking. Due to the reliability of the TCP protocol, that is, sending and receiving data in sequence, and being affected by congestion control, a small amount of packet loss may cause all flows on the entire TCP connection to be blocked.

HTTP/3.0

The first draft of HTTP 3.0 was released in 2020 and officially became the RFC9114 standard on June 6, 2022. HTTP/3.0 abandons TCP and adopts the QUIC protocol on UDP to transmit application layer data, thereby eliminating the head-of-line blocking problem at the transport layer.

QUIC uses the UDP protocol to establish multiple independent streams between two endpoints, which means that in most cases, packet loss in one stream will not affect other streams. This innovation effectively solves the head-of-line blocking problem, making HTTP/3.0 a big step forward in performance and efficiency.

HTTP 3.0 is not yet widely used, and there are only two problems I can think of.

The first is the QOS or blocking of UDP in the CN region. It is not clear whether it will be relaxed in the future.

The second is that the UDP protocol relies on 4-tuple information. Most devices without public IPv4 need to go through NAT conversion of routers or firewalls to communicate with the server. NAT devices cannot know when the UDP connection is disconnected, so deleting their own NAT records may cause the UDP connection that is still communicating to be disconnected.

Later, my colleague told me that the QUIC protocol has something like ConnectionId, which can restore the connection even if the network environment is unstable.

I looked it up and the technical term is: Connection Migration, and there is a proposal: https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-23#section-9 .

Finally, I attach a picture drawn by other big guys.

picture

refer to

• https://github.com/ByteByteGoHq/system-design-101