​From HTTP/1.0 to HTTP/2, no matter how the application layer protocol is improved, TCP has always been the basis of the HTTP protocol, mainly because it can provide reliable connections.

However, starting with HTTP 3.0, this situation has changed.

Because, in the latest HTTP 3.0, the TCP protocol has been completely enabled.

TCP head of queue blocking

We know that during the TCP transmission process, the data will be split into data packets arranged in order. These data packets are transmitted to the receiving end through the network, and the receiving end will combine these data packets in order. into the original data, thus completing the data transmission.

However, if one of the data packets does not arrive in order, the receiver will keep the connection and wait for the data packets to return, which will block subsequent requests. This happens **TCP head of queue blocking. **

The piped persistent connection of HTTP/1.1 also allows the same TCP connection to be used by multiple HTTPs, but HTTP/1.1 stipulates that a domain name can have 6 TCP connections. In HTTP/2, the same domain name only uses one TCP connection.

Therefore, in HTTP/2, the impact of TCP queue head blocking will be greater, because the multiplexing technology of HTTP/2 makes multiple requests actually based on the same TCP connection, then if a certain request causes TCP If the head of the queue is blocked, then multiple requests will be affected.

TCP handshake duration

We all know that the reliable connection of TCP is based on three-way handshake and four-way wave. But the problem is that the three-way handshake takes time.

In the process of TCP three-way handshake, the client and the server need to interact three times, which means that an additional 1.5 RTT is consumed.

> RTT: Network Delay (Round Trip Time). It refers to the period of time when a request sends a request packet from the client browser to the server, and then gets a response packet from the server. RTT is an important indicator reflecting network performance.

When the distance between the client and the server is relatively far, if an RTT reaches 300-400ms, then my handshake process will be very "slow".

Upgrade TCP

Based on the two problems we mentioned above, someone said: Since TCP has these problems, and we also know that these problems exist, and even the solutions are not difficult to think of, why can't the protocol itself be upgraded to solve these problems Woolen cloth?

In fact, this involves a "protocol rigidity" problem.

In this way, when we browse data on the Internet, the data transmission process is actually extremely complicated.

We know that there are several prerequisites for using the network at home. First, we need to open the network through the operator, and we need to use the router, and the router is an intermediate device in the network transmission process.

Intermediate equipment refers to the auxiliary equipment inserted between the data terminal and the signal conversion equipment to complete some additional functions before modulation or after demodulation. For example, hubs, switches and wireless access points, routers, security modems, communication servers, etc. are all intermediate devices.

In places we can't see, there are many, many such intermediate devices. A network needs to be forwarded by countless intermediate devices to reach the end user.

If the TCP protocol needs to be upgraded, it means that these intermediate devices need to support new features. We know that we can replace the router with another one, but what about the other intermediate devices? Especially those larger devices? The cost of replacement is enormous.

Moreover, in addition to the intermediate device, the operating system is also an important factor, because the TCP protocol needs to be implemented through the operating system kernel, and the update of the operating system is also very lag.

Therefore, this problem is called "rigidity of the middle equipment", and it is also an important reason for the "rigidity of the protocol". This is also an important reason to limit the update of the TCP protocol.

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

QUIC

Therefore, there is only one way in front of HTTP/3.0, and that is to give up TCP.

As a result, HTTP/3.0 implements the QUIC protocol (Quick UDP Internet Connections) based on the UDP+Diffie–Hellman algorithm.

The QUIC protocol has the following characteristics:

UDP-based transport layer protocol: It uses the UDP port number to identify a specific server on a given machine.

Reliability: Although UDP is an unreliable transport protocol, QUIC has made some modifications on the basis of UDP, making it provide similar reliability to TCP. It provides packet retransmission, congestion control, pacing of transmissions, and some other features that exist in TCP.

 Unordered and concurrent byte streams are implemented: QUIC's single data stream can guarantee ordered delivery, but multiple data streams may be out of order, which means that the transmission of a single data stream is in order, but multiple data streams The order received by the receiver may differ from the order sent by the sender!

Fast handshake: QUIC provides 0-RTT and 1-RTT connection establishment

Use TLS 1.3 Transport Layer Security: TLS 1.3 has many advantages over earlier TLS versions, but the main reason to use it is that its handshake takes fewer round trips, which reduces protocol latency.

hinder

Above, we have introduced many advantages of QUIC compared to TCP. It can be said that this protocol is indeed better than TCP.

Because it is based on UDP, it does not change the UDP protocol itself, but only makes some enhancements. Although it can avoid the problem of rigid middle equipment, it is not completely without problems in promotion.

First, many enterprises, operators, and organizations block or limit UDP traffic other than port 53 (DNS), because these traffic are often abused for attacks recently.

In particular, some existing UDP protocols and implementations are vulnerable to amplification attacks, where attackers can control innocent hosts to send large amounts of traffic to victims.

Therefore, the transmission of the QUIC protocol over UDP may be blocked.

In addition, because UDP has always been positioned as an unreliable connection, there are many intermediate devices that do not support and optimize it to a high degree, so there is still the possibility of packet loss. . .

But no matter what, the era of HTTP/3.0 will definitely come, and the era of QUIC protocol to completely replace TCP will also come, let's wait and see.