QUIC Protocol

Introduction: QUIC as a Transport Protocol

TCP provides ordered and reliable transport, but its connection setup and single-stream delivery model create costs for internet applications. Establishing a connection requires a TCP handshake, and TLS adds another phase. Loss of a segment delays later bytes in the stream, while changes to a TCP implementation usually depend on the operating-system stack.

The QUIC project, initially developed in part by Google, used UDP as a simple datagram substrate. It added reliability, congestion control, multiple streams, and cryptographic protection above that substrate. This arrangement lets the transport functions evolve with an application without waiting for changes to the system TCP stack.

The protocol is QUIC. RFC 9000 uses QUIC as the protocol name and does not expand it to Quick UDP Internet Connections. QUIC operates over UDP but provides reliability, congestion control, multiple independent streams, and mandatory cryptographic protection based on TLS 1.3. UDP does not provide retransmission, ordering, or congestion control by itself, so the QUIC layer supplies those functions. A user-space implementation makes the protocol easier to update without waiting for changes to the system TCP stack. QUIC is the transport used by HTTP/3.

Problems in the TCP and TLS Stack Addressed by QUIC

To assess QUIC's architecture, separate the functions of the traditional stack. Secure web traffic commonly uses TCP with a separate TLS (Transport Layer Security) layer. Combining TCP with separate TLS requires separate connection-establishment phases and leaves the multiplexing of many resources inside one TCP byte stream.

1. Connection Establishment Latency

Loading a secure webpage requires a multi-step conversation that involves multiple round trips across the network.

• The TCP Handshake: TCP first establishes a connection through the three-way handshake (SYN, SYN-ACK, ACK), which covers one full Round-Trip Time (RTT). In a typical exchange, application data is sent after this stage; an implementation may use additional extensions.
• The TLS Handshake: After TCP is established, TLS performs its own handshake to authenticate the server and negotiate encryption keys. A full TLS 1.3 exchange usually adds one RTT, while older versions or other scenarios can require one to two RTTs. Session resumption can reduce this exchange.

In a typical TCP connection with a full TLS 1.3 handshake, at least two RTTs occur before the browser sends its first request. With high network latency, these stages can total hundreds of milliseconds. TLS resumption and other mechanisms can change the result.

QUIC handshake packets carry transport information and TLS messages together. Without packet loss, a client can usually begin protected data exchange after a handshake that fits within one RTT, although application response time still depends on the network and server.

2. TCP Head-of-Line Blocking

One limitation of TCP is Head-of-Line Blocking. TCP provides a single, strictly ordered byte stream. A webpage contains many resources, including HTML, CSS, JavaScript, and images. HTTP/2 multiplexes these resources over one TCP connection, but they still use the same byte stream.

Loss of a segment carrying part of an image creates a gap in the stream. TCP does not deliver bytes after that gap to the application, even when they belong to CSS or JavaScript and have already arrived. Delivery resumes after the missing data is retransmitted. This is a limitation of multiplexing HTTP/2 over one TCP stream.

3. TCP in the Kernel and Protocol Ossification

TCP is commonly implemented in the operating-system kernel. Keeping the stack in the kernel supports system-level optimization, but changes require updates to system components.

Deploying a new TCP feature requires agreement between specifications, system implementations, and host deployments. Updates can therefore spread more slowly than a change to an application library. Network middleboxes such as firewalls and NAT devices recognize established TCP traffic patterns and may block unknown extensions. This is known as protocol ossification.

The QUIC Architecture: Transport Functions in User Space

QUIC moves many transport functions into an implementation that runs over UDP. UDP supplies datagrams, while QUIC adds reliability, congestion control, flow control, and encryption.

The protocol does not require one library-deployment model. An implementation can run as an application library, a separate module, or part of another stack as long as it follows the required packet formats and transport rules.

Using UDP lets QUIC leave datagram handling to lower layers and define its own transport functions:

• Updating Implementations: Many QUIC implementations run as libraries within applications such as browsers and servers. Shipping QUIC as a library lets transport updates reach applications without waiting for a system TCP-stack change.
• Middlebox Handling:From the network's perspective, QUIC is UDP traffic, so intermediate devices do not need to implement TCP features for it. Networks that restrict UDP can still restrict QUIC, while cryptographic protection detects data modification.

A typical user-space QUIC implementation provides reliability, flow control, congestion control, and mechanisms for a multi-stream transport. Running these functions outside the kernel allows protocol work to proceed independently of the operating-system release cycle.

Key QUIC Mechanisms

1. Reduced Connection Latency: 0-RTT and 1-RTT Handshakes

QUIC combines transport and cryptographic handshakes into one process, reducing the number of stages needed before data exchange.

• First Connection (1-RTT): During the first connection, a full QUIC handshake can begin protected data exchange after one RTT when no packets are lost. The client and server negotiate cryptographic keys and connection parameters in this exchange.
• Subsequent Connections (0-RTT): A client that retained parameters from an earlier session can send early application data in its first flight of packets. QUIC 0-RTT data does not provide replay protection against an attacker. The server may reject it, and an application should use this mode only for operations that are safe to repeat, such as reads or idempotent requests. The mechanism reduces the wait before data is sent but does not remove network latency or request-processing time.

2. Streams and Reduced Head-of-Line Blocking

A single QUIC connection contains multiple independent data streams. Each stream keeps its own ordering and flow-control state, while the connection shares transport parameters.

Flow control applies both to an individual stream and to the connection as a whole. The receiver can therefore limit one stream or the total number of buffered bytes independently of loss detection and congestion control.

When a browser uses HTTP/3, it can map resources to separate QUIC streams. Loss of a packet carrying stream 3 data delays ordered delivery of the missing bytes in that stream but does not block data ready for delivery in other streams. QUIC therefore removes the cross-stream blocking caused by multiplexing HTTP/2 over one TCP byte stream, but it does not remove blocking within the stream affected by loss.

3. Connection Migration: Surviving Network Changes

A TCP connection is associated with a 4-tuple of IP addresses and ports. When a phone changes from Wi-Fi to a cellular network, its IP address may change, so the TCP connection usually must be established again. An application carrying video may then pause or buffer.

QUIC uses connection identifiers so a connection can survive a path change. In version 1, a Connection ID has variable length up to 20 bytes, and it can be zero length in some cases. After a network change, an endpoint selects an active identifier and validates the new path to reduce the risk of redirecting traffic to an unauthorized receiver. The mechanism can also handle a NAT rebinding when the endpoints accept the new path. The server can recognize a packet as belonging to an existing connection, so the session can continue despite an IP-address change. Endpoints can also receive and retire additional identifiers during the connection.

4. Security by Default: Built-in Encryption

With TCP, TLS is a separate layer added above the transport. With QUIC, TLS 1.3 participates in the handshake and data packets use authenticated encryption with associated data (AEAD). The payload of a protected packet is encrypted, and modification of protected fields causes verification to fail. Packet numbers support loss detection and progress acknowledgment. Some header fields remain visible; header protection masks selected bits, while AEAD authenticates the payload and header fields used as associated data. Version Negotiation and Retry packets follow separate rules.

Default protection secures user data and makes packet contents harder for middleboxes to inspect or modify. This limits some causes of protocol ossification, while devices that filter UDP can still affect QUIC availability.

5. Configurable Congestion Control

In a typical implementation, QUIC congestion control runs in user space, which makes it easier to test and deploy algorithms with the application. RFC 9002 defines a sender-side controller similar to TCP NewReno and allows another algorithm when it follows the applicable congestion-control guidelines. An implementation can use CUBIC, BBR, or another suitable algorithm while reacting to acknowledgments and observed loss.

QUIC in HTTP/3 and Other Uses

One of QUIC's main uses is transporting the web protocol. HTTP/3 defines a mapping of HTTP semantics onto QUIC.QUIC's independent streams let HTTP/3 deliver resources without blocking streams whose data is ready, which can limit the effect of packet loss on mobile paths.

QUIC has been standardized by the IETF (Internet Engineering Task Force) as an open protocol. Browser, server, and service implementations can deploy HTTP/3 and QUIC, while actual use depends on support at both endpoints and on network conditions.

QUIC changes how transport functions can be placed in the Internet stack. Moving part of the control into an implementation shipped with the application allows faster transport updates while retaining reliability, congestion control, multiple streams, and cryptographic protection.