Source: Reprinted with permission from Hollis (ID: hollischuang)
Author: Hollis
Since HTTP/1.0 and up to HTTP/2, regardless of how the application layer protocols have improved, TCP has always been the foundation of the HTTP protocol, primarily because it provides a reliable connection.
However, starting with HTTP 3.0, this situation has changed.
Because, in the newly released HTTP 3.0, the TCP protocol has been completely abandoned.
TCP Head-of-Line Blocking
We know that during TCP transmission, data is split into packets that are **ordered** and sent over the network to the receiving end, where they are reassembled in **order** to complete the data transmission.
However, if one of these packets does not arrive in order, the receiving end will keep the connection open waiting for the packet to return, which will block subsequent requests. This is known as **TCP head-of-line blocking.**
HTTP/1.1’s pipelined persistent connections allow multiple HTTP requests to use the same TCP connection, but HTTP/1.1 specifies that a single domain can have six TCP connections. In contrast, HTTP/2 uses only one TCP connection for the same domain.
Therefore, in HTTP/2, the impact of TCP head-of-line blocking is more significant because the multiplexing technology of HTTP/2 means that multiple requests are actually based on the same TCP connection. If one request causes TCP head-of-line blocking, then multiple requests will be affected.
TCP Handshake Duration
We all know that TCP’s reliable connection is established through a three-way handshake and a four-way teardown. However, the problem is that the three-way handshake takes time.
The TCP three-way handshake involves three interactions between the client and the server, which means an additional 1.5 RTT is consumed.
> RTT: Round Trip Time. It refers to the time it takes for a request to be sent from the client browser to the server and for the response to be received back from the server. RTT is an important indicator of network performance.
In cases where the client and server are far apart, if one RTT reaches 300-400ms, then the handshake process will seem very “slow”.
Upgrading TCP
Based on the two issues mentioned above, some have suggested: since TCP has these problems, and we know about them, and even the solutions are not difficult to conceive, why not upgrade the protocol itself to solve these issues?
In fact, this involves a problem of “protocol rigidity“.
To put it simply, when we browse data on the internet, the process of data transmission is extremely complex.
We know that to use the internet at home, there are several prerequisites: first, we need to activate the internet through an ISP, and we need to use a router, which is an intermediary device in the data transmission process.
Intermediary devices refer to auxiliary devices that are inserted between data terminals and signal conversion devices, completing certain additional functions before modulation or after demodulation. For example, hubs, switches, wireless access points, routers, security demodulators, communication servers, etc., are all intermediary devices.
In places we cannot see, there are many such intermediary devices, and a network needs to pass through countless intermediary devices to reach the end user.
If the TCP protocol needs to be upgraded, it means that all these intermediary devices must support the new features. We know we can replace routers, but what about the other intermediary devices? Especially the larger ones? The cost of replacement is enormous.
Moreover, in addition to intermediary devices, the operating system is also a crucial factor because the TCP protocol needs to be implemented through the operating system kernel, and updates to operating systems are often very slow.
Thus, this issue is referred to as “intermediary device rigidity,” which is also a significant reason for “protocol rigidity.” This is a major limitation on the updating of the TCP protocol.
Therefore, in recent years, many new features of TCP standardized by the IETF have not been widely deployed or used due to a lack of broad support!
QUIC
Thus, the only path for HTTP/3.0 is to abandon TCP.
As a result, HTTP/3.0 implements the QUIC protocol (Quick UDP Internet Connections) based on UDP and the Diffie-Hellman algorithm.
QUIC has the following characteristics:
Transport layer protocol based on UDP: It uses UDP port numbers to identify specific servers on designated machines.
Reliability: Although UDP is an unreliable transport protocol, QUIC has made some modifications based on UDP to provide reliability similar to TCP. It offers packet retransmission, congestion control, transmission pacing, and other features present in TCP.
Supports unordered, concurrent byte streams: A single data stream in QUIC can guarantee ordered delivery, but multiple data streams may be unordered, meaning that while the delivery of a single data stream is sequential, the order in which the receiver receives multiple data streams may differ from the order in which the sender sent them!
Fast handshake: QUIC provides 0-RTT and 1-RTT connection establishment.
Uses TLS 1.3 transport layer security protocol: Compared to earlier versions of TLS, TLS 1.3 has many advantages, but the main reason for using it is that it requires fewer round trips during the handshake, thus reducing protocol latency.
Obstacles
Above, we have introduced many advantages of QUIC compared to TCP, and it can be said that this protocol is indeed superior to TCP in some respects.
Because it is based on UDP and does not change the UDP protocol itself, it only enhances it. Although it can avoid the problem of intermediary device rigidity, there are still issues with its promotion.
First, many companies, operators, and organizations intercept or limit UDP traffic other than port 53 (DNS) because this traffic has recently been abused for attacks.
In particular, 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 UDP-based QUIC protocol may be blocked.
Additionally, because UDP has always been characterized as an unreliable connection, many intermediary devices do not support or optimize it well, so there is still a possibility of packet loss.
However, regardless of the challenges, the era of HTTP/3.0 will undoubtedly come, and the era of QUIC fully replacing TCP will also arrive. Let us wait and see.
1. Microsoft Issues Latest Warning! Mysterious New Virus Outbreak, Many Windows Users Affected
2. The Chaos of Domestic Databases
3. The Shocking Consequences of a Programmer Being Interrupted 10 Times a Day!
4. Major Disclosure: Hundreds of Important Chinese Systems Infected with Trojans by the US
5. Global 3-Nanometer Milestone! Samsung Rushes to Mass Produce Chips, Overtaking TSMC?
Share
Like
See Again