QUIC

QUIC is a transport layer protocol designed to address several major issues with TCP. These issues include slower connection times, poorer congestion control, and head-of-line blocking. QUIC is also the foundation for HTTP/3 and aims to supplant TLS. Its development and initial deployment was led by Jim Roskind at Google in 2012, and continues to increase in public use today.

Background

Communication over the internet is administered by many different protocols operating at different levels of hierarchy. For example, when a user would like to send a message over the internet, the related data must first be formatted properly in the application layer (eg. HTTP). Then, the data is split up into smaller components called packets and handled properly for transit over the internet by the transport layer. These packets are transmitted over the network layer (ie. IP) before lower-level protocols handle the actual sending and receiving of individual bits.

Fig 1. Comparison of various protocol stacks for network communication.

Transmission Control Protocol (TCP) has primarily been the preferred choice of protocol for handling data in the transport layer for several decades due to its reliability. TCP accomplishes this by first establishing a secure connection between two end users using Transport Layer Security (TLS). After a secure link is established and packets of data are sent back and forth, TCP is also responsible for checking if any packets were lost in transit and assembling the data back into original order. TCP stands in contrast to User Datagram Protocol (UDP), which attempts to send data without establishing a connection between two users first, and is thus known to be very unreliable. However, UDP has seen some practical use in cases where speed is a higher priority over reliability or in cases where reliability is implemented at a higher level.

QUIC aims to combine the best of both TCP and UDP by speeding up the connection process, handling network disruptions more smoothly, and including security features by default.

Benefits over TCP

QUIC offers several significant improvements over TCP, especially in the case of speed. In TCP, establishing a secure connection between a user’s device and a server requires multiple steps known as a handshake. This process involves a series of back-and-forth exchanges to first confirm a secure connection and then set up encryption, which can slow down the time it takes to load a website, especially on slower or more unstable networks. QUIC alleviates this issue by combining the connection and encryption setup into a single handshake, reducing overall latency.

Even greater speedup is present in the way QUIC addresses head-of-line (HOL) blocking. In TCP connections, data packets are sent in a strict sequence so that lost packets are easier to detect. However, this means that the loss of a single packet can cause the entire stream of data waiting in queue for delivery to be delayed until the lost packet is detected and re-sent. This can especially be disruptive in cases where responsiveness is critical, such as in live calls or online gaming. This is partially resolved by maintaining a “window” of packets that must be confirmed at a time, rather than waiting for individual packets – however, this issue still persists to some degree. QUIC solves this by allowing data to be transmitted in independent streams within a single connection, so that a delay in one stream does not hold up the others.

In addition, QUIC handles loss detection by placing any lost packets on future outgoing QUIC packets, rather than retransmitting the individual lost packet. This loss detection depends both on a fixed threshold in regards to the packet number difference and a time-based threshold. Through this, QUIC does not have to stop and wait until a particular packet holding up the queue is re-sent.

Additionally, QUIC improves on congestion control, which is how networks manage the flow of data to prevent overloads. While TCP uses older methods to handle congestion, QUIC uses more advanced algorithms that can adapt more quickly to changes in network conditions. This means it can optimize data flow in real time, reducing the risk of bottlenecks and keeping connections stable even on crowded networks. However, as many devices have not adapted to QUIC yet due to the uncertainty and hassle of adopting newer technologies in pre-existing systems, QUIC generally supports backwards compatibility whenever older packets or users are detected.

Fig 2. Comparison of initial connection handshakes required for TCP and QUIC.

Data Delivery with QUIC

When two devices first communicate using QUIC, they establish a connection using unique Connection IDs. These IDs are independent from IP addresses and port numbers, and help both sides keep track of the session even if the network connection changes, such as when switching between Wi-Fi and mobile data. This makes QUIC more resilient to disruptions, allowing data transfer to continue seamlessly without needing to re-establish the connection.

Once a connection is established, QUIC uses multiple streams to send data. A stream is an independent sequence of data that flows between the client and server. Unlike traditional TCP connections, where data is sent in a strict order, QUIC allows for multiplexing, where multiple streams can be sent simultaneously over a single connection. This is particularly useful for web applications where different resources (like images, scripts, and videos) can be transmitted concurrently without one stream blocking another.

Data in QUIC is sent in units called packets, which are further divided into frames. Frames can hold different types of information, such as actual data, acknowledgments, or control signals. A single QUIC packet can contain multiple frames of different types, including ACK frames that are necessary for acknowledging the receipt of previous packets, helping the sender know which data has been successfully received and detect any lost packets quicker.

Once data is divided into frames and packed into packets, it is sent over the network to the recipient. To avoid overwhelming the network, QUIC includes advanced congestion control mechanisms. These mechanisms adjust the rate of data transmission based on current network conditions, such as available bandwidth and packet loss rates, optimizing data flow to prevent congestion. Upon receiving a packet, the recipient uses the Connection ID to identify the correct session, extracts the frames, and processes them based on their types (e.g., stream frames are passed to the appropriate stream, and ACK frames are used to update the sender on successful deliveries).

References

[1] https://www.rfc-editor.org/rfc/rfc9000.html [2] https://cabulous.medium.com/http-3-quic-and-how-it-works-c5ffdb6735b4 [3] https://www.potaroo.net/ispcol/2022-11/quicvtcp.html