Free lesson · Computer Networking

Quic Protocol For Http3

Easy11 min readnetworkingcomputer-networkstcp-ip

Why the Internet Needed a New Transport Protocol

TCP has served the internet well for four decades. But as the web evolved - from simple document retrieval to complex applications loading hundreds of resources, streaming video to billions of mobile devices, and running latency-sensitive interactive experiences - TCP's limitations became increasingly painful.

Three problems drove the creation of QUIC:

Head-of-line blocking. HTTP/2 multiplexes many requests over a single TCP connection, but TCP's byte stream ordering means a single lost packet blocks all streams. On lossy mobile networks, HTTP/2 over TCP sometimes performs worse than HTTP/1.1's multiple connections. (You explored this in detail in Module 05, Topic 7.)

Connection establishment latency. A new HTTPS connection requires 2-3 round trips: TCP handshake (1 RTT) + TLS handshake (1-2 RTTs). On a 100ms RTT mobile connection, that is 200-300ms before the first byte of application data. For the mobile web, where connections are frequently established to new servers, this latency is a significant fraction of total page load time.

Protocol ossification. TCP is implemented in operating system kernels and inspected by middleboxes (firewalls, NAT devices, load balancers). Deploying TCP improvements requires updates across the entire ecosystem - OS vendors, middlebox manufacturers, and cloud providers. In practice, this makes TCP evolution glacially slow. Many TCP extensions proposed over the past two decades have failed because middleboxes strip unknown TCP options or drop packets with unfamiliar flags.

QUIC solves all three. Developed by Google starting in 2013, standardized by the IETF as RFC 9000 in 2021, and adopted as the transport for HTTP/3 (RFC 9114), QUIC is a complete transport protocol that runs on top of UDP and provides reliability, ordering, flow control, congestion control, and encryption - but with fundamental architectural improvements over TCP.

sequenceDiagram
    participant C as Client
    participant S as Server

    rect rgb(239, 68, 68)
        Note over C,S: TCP + TLS 1.3 (2 RTTs)
        C->>S: SYN
        S->>C: SYN-ACK
        C->>S: ACK + TLS ClientHello
        S->>C: TLS ServerHello + Finished
        C->>S: TLS Finished + HTTP Request
        S->>C: HTTP Response
    end

    rect rgb(34, 197, 94)
        Note over C,S: QUIC New Connection (1 RTT)
        C->>S: QUIC Initial + TLS ClientHello
        S->>C: QUIC Handshake + TLS ServerHello
        C->>S: QUIC 1-RTT + HTTP Request
        S->>C: HTTP Response
    end

    rect rgb(59, 130, 246)
        Note over C,S: QUIC Resumed (0-RTT)
        C->>S: QUIC 0-RTT + HTTP Request
        S->>C: HTTP Response
    end

This sequence diagram compares connection establishment across three scenarios. TCP plus TLS 1.3 requires 2 round trips: one for the TCP handshake (SYN, SYN-ACK, ACK) and one for the TLS handshake, before the first HTTP request can be sent. A new QUIC connection requires only 1 round trip: the transport and TLS handshakes happen simultaneously. A resumed QUIC connection with a stored session ticket requires 0 round trips: the HTTP request is sent immediately in the first packet. On a 100ms RTT connection, this is the difference between 200ms, 100ms, and 0ms before data flows.

QUIC's Architecture

UDP as the Substrate

QUIC uses UDP as its network-layer interface. This is not because QUIC is "unreliable" - QUIC implements its own reliability, more sophisticated than TCP's. UDP is the substrate because it passes through middleboxes without interference. Firewalls and NAT devices that inspect and modify TCP headers leave UDP payloads untouched. By building on UDP, QUIC avoids the ossification problem - the protocol's logic lives in the application (or a shared library), not in the kernel, and can be updated by deploying new application versions.

Integrated Encryption (TLS 1.3)

QUIC does not layer encryption on top of transport - it integrates TLS 1.3 into the transport handshake itself. The QUIC handshake simultaneously establishes the transport connection and performs the cryptographic key exchange, completing both in a single round trip for new connections.

For repeat connections (where the client has a session ticket from a previous connection to the same server), QUIC supports 0-RTT resumption: the client sends application data in the very first packet, before any handshake completes. The server validates the session ticket and processes the data immediately. This means a returning user's first HTTP request can be sent with zero handshake latency.

The trade-off: 0-RTT data is vulnerable to replay attacks (an attacker could capture and resend the first packet). For this reason, 0-RTT should only be used for idempotent requests (GET) - never for state-changing operations (POST).

Stream Multiplexing Without HOL Blocking

QUIC's most important innovation is independent stream reliability. A QUIC connection supports multiple concurrent streams, each with its own sequence numbers, flow control, and reliability tracking. A lost packet affecting stream 1's data does not block delivery of stream 2's data.

This is architecturally different from HTTP/2 over TCP. HTTP/2 multiplexes at the application layer but relies on TCP's single byte stream for transport - so loss on any stream blocks all streams. QUIC multiplexes at the transport layer with per-stream independence - loss on one stream affects only that stream.

In practical terms: when a web page loads 50 resources over HTTP/3, a lost packet delays only the specific resource it belongs to. The other 49 resources continue loading unimpeded. On a network with 2% packet loss and 100ms RTT, this difference is measurable - Google reported 3-8% improvement in search page load times and 15-18% reduction in YouTube rebuffering after deploying QUIC.

graph TD
    subgraph QUIC_Arch["QUIC Protocol Architecture"]
        direction TB
        APP["Application (HTTP/3)"]
        STREAMS["QUIC Streams<br/>Independent reliability<br/>Per-stream ordering<br/>Per-stream flow control"]
        CONN["QUIC Connection<br/>Connection-level flow control<br/>Congestion control<br/>Connection migration"]
        TLS["TLS 1.3<br/>Integrated encryption<br/>1-RTT / 0-RTT"]
        UDP_LAYER["UDP<br/>Port multiplexing<br/>Checksum<br/>Middlebox traversal"]
        IP["IP Layer"]
        APP --> STREAMS --> CONN
        TLS -.->|"Integrated into"| CONN
        CONN --> UDP_LAYER --> IP
    end

    style APP fill:#4f46e5,stroke:#4338ca,color:#fff
    style STREAMS fill:#7c3aed,stroke:#6d28d9,color:#fff
    style CONN fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style TLS fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style UDP_LAYER fill:#c4b5fd,stroke:#a78bfa,color:#000
    style IP fill:#e2e8f0,stroke:#94a3b8,color:#000

This diagram shows the QUIC protocol architecture as a layered stack. At the top, the application layer runs HTTP/3. Below that, QUIC streams provide independent reliability, per-stream ordering, and per-stream flow control. The QUIC connection layer handles connection-level flow control, congestion control, and connection migration. TLS 1.3 is integrated directly into the connection layer, not layered on top. Below the QUIC connection, UDP provides port multiplexing, checksums, and middlebox traversal. At the bottom is the IP layer.

Connection Migration

TCP connections are identified by the 4-tuple (source IP, source port, destination IP, destination port). When a mobile device switches from Wi-Fi to cellular, the source IP changes and the TCP connection breaks - requiring a new handshake and TLS negotiation, losing the congestion window, and interrupting the application.

QUIC identifies connections using a connection ID - a random value negotiated during the handshake. When the device's IP address changes, QUIC sends a path validation probe on the new address and, upon confirmation, continues the connection seamlessly. No handshake, no TLS renegotiation, no congestion window reset, no application interruption.

Connection migration is particularly valuable for mobile users who frequently transition between networks - walking from Wi-Fi to cellular, moving between cell towers, or switching between VPNs. Each transition that would break a TCP connection is handled transparently by QUIC.

QUIC Flow Control

QUIC implements flow control at two levels, both more granular than TCP:

Stream-level flow control: Each stream has its own receive window. A slow consumer on one stream does not affect the flow control of other streams. The receiver can independently advertise how much data it can accept on each stream, preventing a single slow stream from consuming the entire connection's buffer space.

Connection-level flow control: The total data across all streams is also limited by a connection-level window. This prevents a single connection with many streams from consuming unlimited receiver memory. The connection-level limit is the sum capacity - individual streams can use their full stream-level window as long as the connection-level total is not exceeded.

This two-level system is a direct improvement over TCP, which has only connection-level flow control. In HTTP/2 over TCP, a single slow stream consuming the TCP receive window can starve all other streams - a form of HOL blocking at the flow control level. QUIC's per-stream windows prevent this.

QUIC Packet Structure and Loss Detection

QUIC packets differ from TCP segments in a fundamental way: every packet has a unique, monotonically increasing packet number that is never reused, even for retransmissions. If packet 42 is lost and retransmitted, the retransmission is sent as packet 73 (or whatever the next number is) - not as a second copy of packet 42.

This eliminates TCP's retransmission ambiguity problem. In TCP, when a retransmitted segment is acknowledged, the sender cannot determine whether the ACK is for the original or the retransmission - making accurate RTT measurement difficult. In QUIC, every ACK unambiguously refers to a specific packet, enabling precise RTT measurement and better-calibrated retransmission timeouts.

QUIC's acknowledgment frames are also more expressive than TCP's. A QUIC ACK frame contains multiple ranges of acknowledged packet numbers (similar to TCP SACK, but more flexible), the timestamp of the largest acknowledged packet, and the ACK delay (how long the receiver waited before sending the ACK). This rich acknowledgment information enables more efficient loss detection and faster recovery.

Congestion Control in QUIC

QUIC's congestion control is protocol-independent - the QUIC specification defines how to detect loss and measure RTT, but the congestion control algorithm is pluggable. Implementations can use CUBIC, BBR, or any other algorithm. Google's production QUIC implementation uses BBR v2 (an improved version of BBR), which provides better fairness with CUBIC flows and more accurate bandwidth estimation.

Because QUIC runs in userspace, congestion control algorithms can be updated without OS kernel changes. This accelerates research and deployment - Google can A/B test new congestion control algorithms on live YouTube traffic by deploying updated QUIC libraries to their servers, without waiting for Linux kernel updates to propagate across the internet.

QUIC vs TCP - Side by Side

QUIC Adoption

QUIC adoption has accelerated rapidly since its IETF standardization:

Browsers: Chrome, Firefox, Safari, and Edge all support HTTP/3 over QUIC. Chrome has used QUIC for Google services since 2014 and enables it for all compatible servers.

CDNs: Cloudflare, Akamai, Fastly, and AWS CloudFront support HTTP/3. Cloudflare reports that approximately 30% of their traffic uses QUIC as of 2025.

Servers: Nginx (with quiche or ngtcp2), Caddy (native QUIC), and LiteSpeed have production QUIC support. Custom implementations exist in Go (quic-go), Rust (quinn, quiche), and C (msquic, ngtcp2).

Beyond HTTP: QUIC is being adopted for non-HTTP use cases: DNS over QUIC (DoQ, RFC 9250), WebTransport (low-latency browser-to-server streaming for gaming and interactive applications), and MASQUE (proxying and tunneling). The IETF is also exploring QUIC for media streaming (Media over QUIC / MoQ) as a potential replacement for RTP in some scenarios.

QUIC's Impact on Network Architecture

QUIC changes several assumptions that network architects have relied on for decades:

Middlebox visibility. TCP headers are in cleartext, allowing middleboxes (firewalls, IDS/IPS, load balancers) to inspect connection state, sequence numbers, and flags. QUIC encrypts everything except the connection ID and a few header bits. This means middleboxes cannot perform deep packet inspection on QUIC traffic, cannot track connection state as precisely, and cannot implement TCP-specific optimizations like SYN cookies at the network edge. This is a deliberate design choice - QUIC prevents middlebox interference that caused TCP ossification - but it requires network operators to adjust their monitoring and security strategies.

Load balancer design. TCP load balancers can inspect the SYN flag to identify new connections and distribute them across backends. QUIC load balancers must parse the connection ID to route packets to the correct backend, which requires QUIC-aware load balancing infrastructure. Cloudflare, Google, and Meta have published papers on QUIC-compatible load balancer architectures that route based on connection ID while supporting connection migration.

Network monitoring. Traditional network monitoring tools that analyze TCP state (connections, retransmissions, window sizes) via passive packet capture cannot analyze QUIC connections. New tools must either integrate with the QUIC implementation (via qlog, a standardized logging format for QUIC) or use the limited information visible in QUIC's unencrypted header fields. The qlog format (RFC draft) provides detailed connection-level logging for debugging and analysis.

Server-side deployment. Because QUIC runs in userspace, it is deployed as a library or application feature, not as an OS kernel capability. This means QUIC updates are application deployment events, not OS upgrade events. Organizations can roll out QUIC improvements (new congestion control algorithms, new TLS configurations, bug fixes) through their normal application deployment pipeline - a significant operational advantage over TCP kernel updates.

QUIC's Trade-Offs

QUIC is not universally better than TCP:

Higher CPU usage. QUIC's userspace implementation requires more CPU per byte than TCP's kernel implementation. For high-throughput server-to-server communication in data centers (where loss is rare and latency is low), TCP may be more efficient.

UDP blocking. Some corporate firewalls and networks block or throttle UDP traffic. QUIC implementations must fall back to TCP (HTTP/2) when UDP is unavailable. Chrome implements this fallback automatically.

Debugging complexity. QUIC's encrypted transport makes packet-level debugging harder than TCP. Tools like Wireshark are adding QUIC decryption support, but the debugging experience is not yet as mature as TCP's.

Middlebox compatibility. While QUIC was designed to traverse middleboxes via UDP, some middleboxes throttle or block unknown UDP traffic. Deployment in enterprise environments with strict firewalls may require explicit UDP port 443 allow rules.

Interview: QUIC knowledge demonstrates awareness of modern transport evolution:

"What is QUIC and why does HTTP/3 use it?" - QUIC is a transport protocol running on UDP that provides TCP's reliability with stream-level independence (no cross-stream HOL blocking), integrated TLS 1.3 encryption (1-RTT or 0-RTT connection setup), and connection migration (seamless network switches on mobile). HTTP/3 uses QUIC because HTTP/2's multiplexing over TCP was undermined by TCP's HOL blocking.

"When would you still use TCP over QUIC?" - Server-to-server communication in data centers where loss is negligible and latency is sub-millisecond - TCP's kernel-based processing is more CPU-efficient. Also when operating in network environments that block UDP, or when using protocols that do not yet have QUIC implementations.

"How does QUIC achieve 0-RTT?" - The client stores a session ticket from a previous connection. On reconnection, it sends data encrypted with a key derived from the stored ticket in the very first packet. The server validates the ticket and processes the data immediately. 0-RTT data must be idempotent because it is vulnerable to replay attacks.

What Comes Next

The next topic covers RTP (Real-Time Transport Protocol) - the specialized protocol for real-time audio and video delivery that runs over UDP, with its own mechanisms for sequencing, timestamping, and quality feedback.

Exercise: Starter: Check if your browser is using QUIC. Visit a Google service (google.com, youtube.com), open DevTools (F12), go to the Network tab, and look at the Protocol column. If you see "h3" - that connection is using QUIC/HTTP/3. Right-click on the column headers to add the Protocol column if it is not visible.

Intermediate: Compare HTTP/2 and HTTP/3 performance. Use curl --http2 https://www.cloudflare.com and curl --http3 https://www.cloudflare.com (requires curl 7.66+ with QUIC support). Compare the connection times. The difference is most visible on high-latency connections - try using a VPN to a distant region to increase RTT and repeat the comparison.

Advanced: Research QUIC's loss detection and congestion control. Unlike TCP (which uses byte-level sequence numbers that can be ambiguous for retransmissions), QUIC uses unique packet numbers for every packet, including retransmissions. How does this eliminate the "retransmission ambiguity" problem? How does QUIC's ACK frame differ from TCP's cumulative ACK + SACK? Read the QUIC loss detection RFC (RFC 9002) and compare its approach to TCP's (RFC 6298).

Back to Computer Networking