Understanding the HTTP/3 Protocol

TCP is designed for single connections, where the requesting end places the data to be transmitted in order into a pipeline, and the final data appears at the other end of the pipeline in the same order.

unsetunsetTCPunsetunset

HTTP/1.1

TCP Data Transmission Process Diagram

The sent data is split into packets, which are transmitted over the network to the receiving end, where these packets are reassembled in order to form the original data.

TCP Packet Loss

During data transmission, if a packet is lost due to network failure or other reasons, the entire TCP connection will be paused, waiting for the lost packet to be retransmitted. However, browsers open 6 TCP connections for each domain, so if one TCP connection experiences head-of-line blocking, the other 5 connections can still continue to transmit data.In the TCP transmission process, the blocking caused by the loss of a single packet is referred to as head-of-line blocking in TCP.

HTTP/2

Multiplexing

Multiple requests run over a single TCP pipeline, and if any data stream experiences packet loss, it will block all requests in that TCP connection. As the packet loss rate increases, the transmission efficiency decreases. Test data shows that when the system reaches a 2% packet loss rate, the transmission efficiency of HTTP/1.1 performs better than that of HTTP/2.

TCP Connection Establishment Delay

The round-trip time (RTT) is the total time taken for a data packet to travel from the browser to the server and back again. RTT is an important indicator of network performance, also known as network latency.

RTT spent during TCP connection establishment

• Establishing a TCP connection requires three-way handshake with the server to confirm successful connection, consuming 1.5 RTT before data transmission can begin.
• For HTTPS TLS connections, approximately 1-2 RTT is required.

Therefore, before data transmission, 3-4 RTT must be consumed. The approximate time required is as follows:

• If the physical distance between the browser and server is short, 1 RTT may take less than 10 milliseconds, totaling 30-40 milliseconds.
• If the physical distance between the browser and server is far, 1 RTT may take over 100 milliseconds, making the entire handshake process take 300-400 milliseconds, which is noticeably “slow”.

TCP Protocol Rigidity

1. Intermediate DevicesThe Internet is a mesh structure of interconnected networks. To ensure the normal operation of the Internet, various devices need to be built throughout the Internet, referred to as intermediate devices. There are various types of intermediate devices, such as routers, firewalls, and switches. They typically rely on software that is rarely upgraded, which uses many TCP features. If a client upgrades the TCP protocol, the new protocol’s packets may be incomprehensible to these intermediate devices, leading to packet loss. This is known as intermediate device rigidity.
2. Operating SystemThe TCP protocol is implemented through the operating system kernel, and applications can only use it without modification. Therefore, freely updating the TCP protocol in the kernel is very difficult.

unsetunsetHTTP/3unsetunset

HTTP/3 adopts a compromise approach, implementing TCP-like functionality based on UDP.

QUIC Protocol

Functions of the QUIC Protocol:

1. It adds a layer on top of UDP to ensure reliable data transmission, providing packet retransmission, congestion control, and other features present in TCP.
2. Multiple independent logical data streams exist over the same physical connection, allowing for separate transmission of data streams and solving the head-of-line blocking issue in TCP.
3. Using 0-RTT or 1-RTT to establish connections means QUIC can send and receive data at the fastest speed, significantly improving the speed of the first page load.

QUIC Multiplexing

unsetunsetChallenges of HTTP/3unsetunset

1. There is no comprehensive support for HTTP/3 on both the server and browser sides.
2. Deploying HTTP/3 also presents significant challenges, as system kernels are not optimized for UDP to the same extent as for TCP.
3. The issue of intermediate device rigidity. These devices are far less optimized for UDP than for TCP, and statistics show that when using the QUIC protocol, there is approximately a 3%-7% packet loss rate.