Source: Reprinted with permission from Programmer cxuan (ID: cxuangoodjob)
Author: cxuan
HTTP 3.0 is the third major version of the HTTP protocol, with the first two being HTTP 1.0 and HTTP 2.0. However, I believe HTTP 1.1 is the true HTTP 1.0.
If you are not familiar with HTTP 1.1 and HTTP 2.0, you can read my two articles on these topics.
After reading this article on HTTP, you will have no problem discussing it with interviewers.
HTTP 2.0: It’s explosive!
As we all know, HTTP is an application layer protocol, and the data generated at the application layer is transmitted to other hosts on the internet through a transport layer protocol, which is the TCP protocol, the mainstream model before HTTP 2.
However, as the shortcomings of the TCP protocol have become increasingly apparent, the new generation of HTTP protocol – HTTP 3.0 has decisively severed its ties with TCP and embraced the UDP protocol. To be more precise, HTTP 3.0 actually embraces the QUIC protocol, which is built on top of the UDP protocol.
HTTP 3.0
HTTP 3.0 was officially released on June 6, 2022, and the IETF established the HTTP 3.0 standard in RFC 9114. Compared to HTTP 2.0, the changes in HTTP 3.0 are much smaller than those from HTTP 1.1 to HTTP 2.0, with the biggest improvement being efficiency. By replacing the TCP protocol with the UDP protocol, HTTP 3.0 achieves lower latency, and its efficiency is even more than three times faster than HTTP 1.1.
In fact, the continuous development of each generation of the HTTP protocol is based on the shortcomings of the previous generation. For example, the biggest problem with HTTP 1.0 was the lack of transmission security and support for persistent connections, which led to the introduction of HTTP 1.1, which introduced the Keep-Alive mechanism to maintain long connections and TLS to ensure communication security. However, at that time, the concurrency of the HTTP protocol was still not good enough.
With the continuous development of the internet, the number of resources (CSS, JavaScript, images, etc.) required by each website has been increasing year by year. Browsers have found that they need more and more concurrency when fetching and rendering web pages. However, since HTTP 1.1 only allows a single HTTP request exchange between the client and server, the only way to achieve concurrency at the network layer is to use multiple TCP connections to the same origin in parallel, but using multiple TCP connections defeats the purpose of keep-Alive.
Then the SPDY protocol emerged, mainly to solve the inefficiency of HTTP 1.1, including reducing latency, compressing headers, etc. These have been proven to produce optimization effects by the Chrome browser. Later, HTTP 2.0 was based on SPDY and introduced the concept of **streams**, which allows different HTTP exchanges to be multiplexed over the same TCP connection, thus enabling the browser to reuse TCP connections.
The main function of TCP is to transmit the entire byte stream from one endpoint to another in the correct order. However, when some packets in the stream are lost, TCP needs to retransmit those lost packets, and HTTP cannot process them until the lost packets arrive at the corresponding endpoint. This is known as the TCP head-of-line blocking problem.
Some may consider modifying the TCP protocol, but this is actually an impossible task. TCP has been around for too long and is embedded in various devices, and this protocol is implemented by the operating system, making updates impractical.
For this reason, Google developed a QUIC protocol based on UDP and used it in HTTP/3. Before HTTP/3, it was called HTTP-over-QUIC, and from this name, we can see that the biggest transformation of HTTP/3 is the use of QUIC.
QUIC Protocol
QUIC is written in lowercase as quic, which sounds like “quick”. It is a transport protocol based on UDP proposed by Google, so QUIC is also called Quick UDP Internet Connection.
The first feature of QUIC is speed. Why is it fast, and where does its speed come from?
We all know that the HTTP protocol uses TCP for message transmission at the transport layer, and HTTPS and HTTP/2.0 also use the TLS protocol for encryption, which leads to connection delays due to the three-way handshake: one for TCP and two for TLS, as shown in the figure below.
For many short connection scenarios, this handshake delay has a significant impact and cannot be eliminated. After all, RTT is the ultimate struggle between humans and efficiency.
In contrast, QUIC’s handshake connection is faster because it uses UDP as the transport layer protocol, which reduces the time delay of the three-way handshake. Moreover, QUIC’s encryption protocol uses the latest version of TLS TLS 1.3, which allows clients to start sending application data without waiting for the TLS handshake to complete, supporting 1 RTT and 0 RTT, thus achieving fast connection establishment.
We also mentioned that although HTTP/2.0 solved the head-of-line blocking problem, its established connections are still based on TCP, which cannot solve the request blocking problem.
UDP itself does not have the concept of connection establishment, and the streams used by QUIC are isolated from each other, so they do not block the processing of other stream data, meaning that using UDP does not cause head-of-line blocking.
In TCP, to ensure data reliability, TCP uses a sequence number + acknowledgment number mechanism. Once a packet with a synchronize sequence number is sent to the server, the server will respond within a certain time. If no response is received after this time, the client will retransmit the packet until the server receives the data packet and responds.
So how does TCP determine its retransmission timeout?
TCP generally uses a adaptive retransmission algorithm, and this timeout is dynamically adjusted based on the round-trip time (RTT). Each time the client uses the same SYN to determine the timeout, leading to inaccurate calculations of this RTT result.
Although QUIC does not use the TCP protocol, it also ensures reliability. The mechanism for ensuring reliability in QUIC is the use of Packet Number, which can be considered a substitute for the synchronize sequence number. This packet number is also incremented. Unlike SYN, regardless of whether the server has received the data packet, the Packet Number will increment by 1, while SYN only increments after the server sends an ACK response.
For example, if a data packet with PN = 10 is delayed in reaching the server for some reason, the client will retransmit a packet with PN = 11. After a while, when the client receives a response for PN = 10, it will send back a response message. The RTT at this point is the survival time of the PN = 10 packet in the network, making this calculation relatively accurate.
While QUIC ensures the reliability of packets, how is the reliability of data guaranteed?
QUIC introduces the concept of a stream offset, where one stream can transmit multiple stream offsets. Each stream offset is essentially a data packet identified by a PN. Even if a PN identified data is lost, the retransmitted data will still be the one identified by PN, and once all PN identified data is sent to the server, they will be reassembled to ensure data reliability. The stream offsets that reach the server will be assembled in order, which also ensures the order of the data.
As we all know, the specific implementation of the TCP protocol is done by the operating system kernel, and applications can only use it without modifying the kernel. With the increasing number of devices connecting to the internet, performance has become a very important metric. Although mobile networks are developing rapidly, user-side updates are very slow. I still see many computers in various regions using Windows XP, even though it has been many years since its release. Server-side systems do not rely on user upgrades, but operating system upgrades involve updates to underlying software and runtime libraries, making them conservative and slow.
One important feature of the QUIC protocol is its pluggability, allowing for dynamic updates and upgrades. QUIC implements congestion control algorithms at the application layer without requiring support from the operating system and kernel. When switching congestion control algorithms, it only requires reloading on the server side without downtime or restart.
We know that TCP’s flow control is implemented through a sliding window. If you are not familiar with the sliding window, you can refer to my article on
TCP Basics
which mentions some concepts of the sliding window.
QUIC also implements flow control, using window updates window_update to inform the peer of the number of bytes it can accept.
The TCP protocol header is not encrypted or authenticated, so it is likely to be tampered with during transmission. In contrast, the headers of QUIC packets are authenticated and encrypted. Therefore, any modification to QUIC packets can be detected by the receiving end, ensuring security.
In summary, QUIC has the following advantages:
- Uses the UDP protocol, eliminating the need for three-way handshake connections and shortening the time to establish TLS connections.
- Solves the head-of-line blocking problem.
- Achieves dynamic pluggability, implementing congestion control algorithms at the application layer that can be switched at any time.
- Packet headers and bodies are authenticated and encrypted separately, ensuring security.
- Connections can migrate smoothly.
Connection migration refers to the ability of your mobile device to switch between 4G signals and WiFi without dropping the connection, allowing users to experience seamless signal switching without any awareness.
The QUIC protocol has been documented in RFC 9000.
1. Microsoft is also not immune to the domestic rogue software bundle, is it really not suitable?
2. The world is heating up, and Google’s servers have already crashed.
3. Youku has been trending for being charged for screen casting…
4. What are the main differences between Alibaba P6 and P7?
5. What really happens when you input xxxhub?
Click to share
Click to like
Click to view