HTTP/3 runs over QUIC instead of TCP. What is QUIC, why was it built on UDP, and where does TLS fit into it?
answer
- QUIC = reliable, multiplexed transport over UDP
- UDP chosen for deployability, not for being lossy
- TLS 1.3 fused into the handshake — always encrypted
- 1 RTT new, 0 RTT resumed
- HTTP/3 = HTTP semantics mapped onto QUIC streams
basics
~20 sQUIC is a reliable, multiplexed transport implemented on top of UDP, with TLS 1.3 built into the protocol rather than layered above it. UDP was chosen because it passes through existing networks and lets the transport live in user space, so it can evolve without OS or middlebox changes.
solid answer
~50 sQUIC is a general-purpose transport protocol that provides what TCP provides — reliable, ordered, congestion-controlled delivery — but with **independent streams** and **integrated TLS 1.3**. HTTP/3 is simply HTTP mapped onto QUIC streams. UDP is not the feature; it is the delivery vehicle. Deploying a genuinely new IP protocol is impossible in practice because firewalls and NAT devices drop what they do not recognize, and TCP changes need OS kernel updates on every machine. Running over UDP means QUIC ships as a library in the application, so a browser or server can update its transport with a normal release. Security is not optional: the QUIC handshake *is* the TLS 1.3 handshake, and packets are protected from very early on — even most transport header fields are encrypted. A fresh connection completes in one round trip (versus TCP's handshake plus a separate TLS handshake), and a resumed connection can send data in the first flight.
code
bash · 1 linecurl -sSI --http3-only https://example.com/ -w '%{http_version}\n' -o /dev/nullgo deeper
Say: QUIC is a reliable transport over UDP with TLS 1.3 built in, and HTTP/3 is HTTP over QUIC. Know that UDP was chosen for deployability.
Add the handshake round-trip comparison, ALPN selecting h3, and independent streams as the headline transport gain.
Bring in ossification and user-space evolution as the real motivations, plus the CPU cost of user-space stacks and UDP-blocked networks.
Discuss it as a deployability and evolvability strategy — encrypting the transport to prevent future ossification, and the operational shift of moving transport state into the application.
## What QUIC actually is QUIC (RFC 9000) is a transport protocol. It sits where TCP sits in the stack and provides the same guarantees applications rely on — reliability, ordering within a stream, flow control, congestion control — plus two things TCP does not have: many **independent streams** within one connection, and **mandatory, integrated encryption**. HTTP/3 (RFC 9114) is the mapping of HTTP semantics onto QUIC: each request/response pair takes a bidirectional QUIC stream, and a few unidirectional streams carry control and header-compression state. The HTTP semantics themselves — methods, status codes, header fields — are unchanged from HTTP/1.1 and HTTP/2. ## Why UDP Three independent reasons, all about deployability: **1. Middlebox ossification.** The internet is full of NATs, firewalls and "optimizers" that inspect and rewrite TCP. A new IP protocol number is dropped by a large fraction of paths, and even new TCP options are often stripped. UDP is one of the two protocols that reliably passes, so it is the only realistic substrate for a new transport. **2. User-space deployment.** TCP lives in the kernel. Changing TCP means shipping OS updates to every client and server, which takes a decade. QUIC is a library linked into the application, so Chrome, Firefox, or your server can change congestion control or loss recovery in a normal release cycle. This is why QUIC evolves quickly. **3. Protection against future ossification.** QUIC encrypts almost everything, including most transport-level header fields (packet numbers, frame types, acknowledgements). Middleboxes cannot parse or "help", so they cannot come to depend on details that would then be frozen forever. Only a small invariant part of the header — a few flag bits and the destination connection ID — is visible. UDP is *not* used for its unreliability. QUIC re-implements acknowledgements, retransmission, and congestion control itself, in user space, on top of UDP datagrams. ## Where TLS fits In the TCP world, TLS is a layer above the transport: you complete a TCP handshake (1 RTT), then a TLS 1.3 handshake (1 more RTT), then send your request. QUIC fuses them (RFC 9001): the TLS 1.3 handshake messages are carried inside QUIC's own CRYPTO frames, and the keys TLS derives are used to protect QUIC packets. There is no such thing as unencrypted QUIC. Consequences: - **A new connection is 1 RTT** to first application data, versus roughly 2–3 for TCP + TLS 1.3 (and more with TLS 1.2). - **A resumed connection can be 0 RTT**: with a pre-shared key from a previous session, the client attaches application data to its very first flight. That data is replayable, so it must be restricted to safe, idempotent requests. - **ALPN in the handshake** selects `h3`, exactly as it selects `h2` over TLS-on-TCP. ## What you get above the handshake The headline transport property is **independent streams**. In TCP everything is one ordered byte stream, so a lost segment blocks delivery of everything behind it, including bytes that belong to unrelated requests. QUIC tracks loss per packet and delivers each stream's data as soon as *that stream's* bytes are complete, so an unrelated stream is unaffected. Additional properties worth naming: **connection IDs** that survive an IP address change, per-stream and connection-level flow control, and pluggable congestion control. ## Practical costs QUIC is not free. Its user-space stack burns noticeably more CPU per byte than kernel TCP with hardware offload — early deployments reported several times the cost, narrowed since by optimized UDP paths (GSO/GRO, `sendmmsg`), better stacks, and offload work. Some networks rate-limit or block UDP, so clients discover HTTP/3 opportunistically and fall back to HTTP/2 over TCP. Operational tooling is different too: connection state lives in the application, so per-connection debugging needs the stack's own logging (qlog) rather than kernel socket tools. ## The summary sentence QUIC is TCP's job re-done in user space over UDP, with TLS 1.3 built in, so that transport features can ship at application speed and so that loss on one stream stops blocking the others.
- If QUIC re-implements reliability, why not just use TCP and fix it?TCP lives in the kernel and on the wire is visible to middleboxes, so every change needs OS updates on both ends plus paths that do not strip it — historically a decade or more per feature, and some features never deploy at all. QUIC in user space ships with the application, and encrypting the transport headers stops middleboxes from freezing the design again.
- Does HTTP/3 change HTTP itself?No. Methods, status codes, and header field semantics are identical; RFC 9110 defines them independently of version. What changes is the mapping onto the wire: requests ride on QUIC streams, header compression uses QPACK instead of HPACK, and there are no TCP-level connection mechanics to reason about.
TCP is a road built into the ground: changing it means digging up every street. QUIC is a vehicle that drives on the existing road (UDP) and can be redesigned every model year without touching the road.
saying these in an interview costs you the question
- Saying HTTP/3 uses UDP so it is unreliable or fire-and-forget — QUIC provides reliability itself
- Describing TLS as a layer running on top of QUIC rather than fused into its handshake
- Claiming QUIC is faster purely because UDP is faster than TCP
- Believing HTTP/3 changed methods or status codes