What is QUIC and How It Boosts HTTP/3? A QUIC One-Stop Solution from End to Cloud on EdgeOne

The Internet Engineering Task Force (IETF) has announced the HTTP/3 standard, designated as RFC 9114. According to the RFC Editor's page, RFC 9114 is currently in the "Proposed Standard" status, not yet an official standard. However, in the industry, approximately 30.2% of websites are already using HTTP/3, according to W3Techs data. It is believed that the era of HTTP/3 will soon arrive in full force.

What is the relationship between QUIC and HTTP/3?

QUIC (Quick UDP Internet Connection) is a transport protocol based on UDP introduced by Google. QUIC is also a transport layer protocol. Above the transport layer, there is the application layer. Theoretically, well-known application layer protocols such as HTTP, FTP, IMAP, etc., can all run on top of QUIC. The HTTP protocol running on top of QUIC is known as HTTP/3, which is the meaning of "HTTP over QUIC, i.e., HTTP/3".

Why is QUIC based on UDP? Because UDP is a simple transport protocol that can support the establishment of secure connections with only one round-trip time. Moreover, as is widely known, UDP is faster than TCP. TCP is a reliable protocol, but the cost is a series of overheads derived from both parties confirming data. Secondly, TCP is implemented in the operating system kernel. If you want to upgrade the TCP protocol, you have to ask users to upgrade their operating systems, which is a high threshold. In contrast, QUIC, based on UDP, allows the client to freely develop as long as there is a server that can connect.

QUIC also implements features such as HTTP/2 multiplexing and header compression based on UDP, absorbing and improving the advantages of HTTP/2.

Key Features of QUIC

Connection Migration

Issues and Concerns with TCP Reconnection

A TCP connection is identified by a four-tuple (source IP, source port, destination IP, destination port). Connection migration refers to maintaining the connection and ensuring that the business logic is not interrupted when any of these elements change. The focus is mainly on the client-side changes, as the client is uncontrollable and the network environment often changes, while the server-side IP and port are generally fixed.

For example, when using a mobile phone to switch between Wi-Fi and 4G mobile networks, the client's IP will undoubtedly change, requiring a new TCP connection to be established with the server. Similarly, when using a public NAT exit, some connections may need to be re-bound to a different port due to competition, causing the client's port to change and requiring a new TCP connection.

From the perspective of TCP connections, this problem is unsolvable.

QUIC's Connection Migration Implementation Based on UDP

When a user's address changes, such as switching from Wi-Fi to 4G, the TCP-based HTTP protocol cannot maintain the connection. QUIC uniquely identifies connections based on connection IDs. When the source address changes, QUIC can still ensure the connection's survival and normal data transmission.

How does QUIC achieve connection migration? Simply put, QUIC is based on the UDP protocol. Any QUIC connection is no longer identified by the IP and port four-tuple but by a 64-bit random number as an ID. This way, even if the IP or port changes, as long as the ID remains the same, the connection is still maintained. The upper-layer business logic is unaware of the change, will not be interrupted, and does not require reconnection.

Since this ID is randomly generated by the client and has a length of 64 bits, the probability of conflict is extremely low.

Low Connection Latency

Since QUIC is based on UDP and does not require a TCP connection, in the best-case scenario, QUIC can achieve 0RTT data transmission for short connections. In contrast, TCP-based HTTPS, even with the best TLS1.3 early data, still requires 1RTT to start data transmission. For the common TLS1.2 full handshake scenario found online, it takes 3RTT to start data transmission. For RTT-sensitive businesses, QUIC can effectively reduce connection establishment latency.

Customizable Congestion Control

QUIC uses pluggable congestion control, which provides more detailed congestion control information compared to TCP. For example, for each packet, whether it is an original packet or a retransmitted packet, it carries a new sequence number (seq). This allows QUIC to distinguish whether an ACK is for a retransmitted packet or an original packet, thus avoiding the problem of TCP retransmission ambiguity. QUIC also carries information about the delay between receiving a data packet and sending an ACK. This information can help calculate the RTT more accurately. In addition, QUIC's ACK Frame supports 256 NACK intervals, which is more flexible than TCP's SACK (Selective Acknowledgment). More abundant information will let the client and server know which packets have been received by the other party.

QUIC's transport control no longer relies on the kernel's congestion control algorithm but is implemented at the application layer. This means that we can implement and configure different congestion control algorithms and parameters based on different business scenarios. Google's proposed BBR congestion control algorithm and CUBIC are completely different in approach. In weak networks and certain packet loss scenarios, BBR is less sensitive and performs better than CUBIC. Under QUIC, we can specify the congestion control algorithm and parameters according to the business, and even different connections of the same business can use different congestion control algorithms.

No Head-of-Line Blocking

The Head-of-Line Blocking Problem in TCP

Although HTTP/2 has implemented multiplexing, due to its reliance on byte-stream-oriented TCP, packet loss will affect all request streams under multiplexing. QUIC is based on UDP and is designed to solve the head-of-line blocking problem.

The main cause of TCP head-of-line blocking is that packet timeouts or losses block the current window from sliding to the right. The most straightforward solution to head-of-line blocking is to prevent timeouts or lost packets from blocking the current window in place. QUIC adopts this approach to solve the TCP head-of-line blocking problem.

TCP ensures reliable communication by using sequence numbers and acknowledgments (ACKs) based on byte sequence numbers. In weak network environments, the head-of-line blocking problem of HTTP/2 results in a terrible user experience.

QUIC's Solution to Head-of-Line Blocking

QUIC is also a reliable protocol. It replaces TCP's sequence numbers with packet numbers, which strictly increase. In other words, even if packet N is lost, the retransmitted packet N will have a different packet number, such as N+M.

QUIC's use of monotonically increasing packet numbers allows packets to be acknowledged out of order, unlike TCP, which requires in-order acknowledgments. When packet N is lost, as long as newly received packets are acknowledged, the current window will continue to slide to the right. When the sender becomes aware of the packet N loss, it will put the packet to be retransmitted into the sending queue, renumber it (e.g., packet N+M), and resend it to the receiver. This process is similar to sending a new packet, so the current window will not be blocked in place due to packet retransmission, thus solving the head-of-line blocking problem. So, since the retransmitted packet N+M and the lost packet N have different numbers, how do we ensure that the contents of these two packets are the same?

QUIC uses a Stream ID to identify which resource request the current data stream belongs to. This is also the basis for assembling multiplexed packets correctly upon receipt. The retransmitted packet N+M and the lost packet N cannot be determined to have the same content based solely on the comparison of their Stream IDs. An additional field, Stream Offset, is needed to indicate the byte offset of the current packet in the current Stream ID.

With the Stream Offset field information, packets belonging to the same Stream ID can also be transmitted out of order (in HTTP/2, only the Stream ID is used for identification, and data frames belonging to the same Stream ID must be transmitted in order). If the Stream ID and Stream Offset of two packets are both consistent, it means that the contents of the two packets are the same.

Future Applications of QUIC

The promotion of any new technology takes time. The prevalence of HTTP/2 and HTTPS, which have been around for years, is not as high as expected, and the same is true for IPv6. However, QUIC has already shown its strong vitality. Let's take a look at some possible application scenarios.

Internet of Things (IoT)

In IoT scenarios, communication mainly occurs between devices and IoT platforms. Since most IoT devices are resource-constrained, their physical and network resources are limited. Therefore, the communication protocols mainly used in IoT scenarios are lightweight protocols designed for resource-constrained environments, such as CoAP/LWM2M and MQTT protocols. Due to its limitations, HTTP may not be the preferred protocol for IoT, but in some applications, HTTP-based communication will be very suitable. For mobile devices collecting data from attached sensors, QUIC-HTTP/3 can solve the problem of wireless connection loss. This advantage is also well-suited for IoT devices installed in cars or other mobile facilities.

Web VR

With the continuous enhancement and improvement of browser capabilities, the content landscape and interaction experience are also changing. One such change is Web-based Virtual Reality (VR). VR is still in its infancy, but it plays a crucial role in enhancing collaboration. In the rich interaction process and experience of VR, the network is an essential link, and all information needs to be transmitted based on the network. VR applications rely on more bandwidth resources and more stable network connections to present the complex details of virtual scenes, which will benefit from the evolution and popularization of QUIC.

Mobile Live Streaming

With the development of the internet and the enrichment of internet application types, the mobile live-streaming industry is also growing rapidly. Mobile live streaming, a particular application scenario, has high demands for network transmission performance, making application development and optimization challenging. Using QUIC to improve the live streaming experience can provide a usable service even in cases of packet loss and severe network latency. It can optimize metrics such as buffering rate, request failure rate, instant opening rate, and connection success rate. Moreover, it supports a higher access rate in situations with many page resources and concurrent connections.

EdgeOne QUIC One-Stop Solution

Full-Link Acceleration (FLA) - Mobile Solution

On the mobile side, EdgeOne offers a more convenient SDK (FLA) for using the QUIC protocol, which can be combined with acceleration nodes to enable HTTP/3 features, quickly optimizing the last-mile network transmission.
Tencent EdgeOne QUIC SDK is a development toolkit based on the QUIC protocol, providing simple and easy-to-use API interfaces that help developers integrate the QUIC protocol into their applications more quickly. By initiating requests through the QUIC protocol, it provides stable and high-quality network transmission for applications. Currently, it supports Android and iOS platforms.

Enable QUIC in EdgeOne Platform

Site Enablement

1. In the site details page, click Site Acceleration > Network Optimization to enter the network optimization details page.
2. Click the "switch" of the HTTP/3 module to enable or disable the HTTP/3 function.

Domain Enablement

1. On the site details page, click Rule Engine.
2. In the rule engine management page, click Create Rule to enter the new rule editing page.
3. In the rule editing page, select the Host matching type to match requests for specified domain names.
4. Click Operation > Selection Box, and in the pop-up operation list, select the operation as HTTP/3, and switch the switch to On.