jd five

UDP, QUIC & HTTP/3

Learning goals

Know when UDP beats TCP for an application design, explain QUIC and HTTP/3 at a high level, and describe how multiplexing without TCP head-of-line blocking improves web performance—connecting back to everything you learned about HTTPS on TCP.

UDP: minimal transport

UDP sends datagrams: bounded payloads with source/dest ports and checksum—no guaranteed delivery, order, or retransmission. The application (or a library like QUIC) decides what to do with loss and ordering.

Plain English: TCP is a reliable phone call; UDP is postcards—you might get them out of order or not at all, but there is less ceremony per message.

When UDP wins:

Use case Why UDP
DNS queries Single small request/response; speed over setup
Real-time media (VoIP, games) Prefer drop to delay; app-specific recovery
QUIC / HTTP/3 Custom reliability on top, integrated encryption
Broadcast/multicast patterns TCP model does not fit

When TCP still wins: bulk transfer where simplicity and kernel-tuned congestion control matter, legacy protocols, many middleboxes that assume TCP for “normal” traffic.

QUIC in plain English

QUIC (Quick UDP Internet Connections) is a transport protocol on UDP—typically port 443—that combines:

  1. Encryption by default (TLS 1.3 integrated; no separate TLS-over-TCP layering cost).
  2. Connection ID — survives IP address changes (mobile Wi‑Fi ↔ cellular handoff).
  3. User-space congestion control — evolves faster than OS kernel TCP stacks.
  4. Independent streams — loss on one stream does not block others (fixes TCP HOL for multiplexing).

First visit still does crypto handshake; 0-RTT resumption (where enabled) can send early data on repeat visits—trade-offs with replay risk for non-idempotent ops.

Precise picture:

HTTP/3  →  QUIC streams  →  QUIC packets  →  UDP datagrams  →  IP

Compare HTTP/2:

HTTP/2  →  frames/streams  →  TCP byte stream  →  IP

HTTP/3

HTTP/3 is HTTP semantics (methods, headers, status codes—the previous chapters) mapped onto QUIC instead of TCP+TLS.

Browsers negotiate via Alt-Svc or HTTPS DNS records (SVCB/HTTPS) advertising h3 support. Fallback remains HTTP/2 or HTTP/1.1 over TCP when QUIC is blocked.

Benefits you may observe:

  • Faster handshakes on repeat connections to the same host.
  • Less head-of-line blocking under packet loss on lossy Wi‑Fi or mobile.
  • Smoother parallel asset loading for modern pages with many small resources.

Caveats:

  • Some corporate firewalls treat UDP 443 strictly or block it—sites keep TCP fallbacks.
  • Server and CDN support must be enabled; debugging tools are still catching up vs TCP.

Multiplexing compared

HTTP/1.1: one request at a time per connection (pipelining rarely used)—browsers open many TCP connections (6+ per host historically).

HTTP/2: many requests as streams on one TCP connection—efficient until a packet loss stalls all streams (TCP HOL).

HTTP/3: many streams on one QUIC connection, each stream independently retransmitted—loss on stream A does not block delivery of stream B’s data (within QUIC’s design).

Plain English: HTTP/3 keeps the “one connection, many things in flight” win of HTTP/2 without sharing one strict ordering queue at the transport layer.

When you still choose TCP

  • Internal service mesh with mature HTTP/2 and stable datacenter links.
  • Protocols and proxies that do not speak QUIC yet.
  • Scenarios where UDP is filtered and fallback would negate benefits.

Public internet-facing sites increasingly serve HTTP/3 at the edge (Cloudflare, Fastly, major browsers) while origin-to-edge may stay HTTP/2 or HTTP/1.1.

Debugging intuition

curl -I --http3 https://example.com    # if curl built with QUIC

Browser devtools Network panel may show Protocol: h3. If you only see h2 or http/1.1, QUIC may be blocked or not advertised.

Compare latency on lossy network simulation: HTTP/3 often degrades more gracefully than HTTP/2—not always faster on pristine fiber.

Common mistakes (beginners)

  1. “UDP is always faster than TCP.” — True only when your app tolerates loss or you add QUIC’s smarts; naive UDP without recovery is not a free speed boost.
  2. Assuming HTTP/3 replaces HTTPS on TCP everywhere overnight. — Negotiation and fallback remain; measure your audience’s paths.
  3. Ignoring security on custom UDP protocols. — QUIC embeds TLS; rolling your own UDP RPC without encryption repeats historical mistakes.
  4. Confusing QUIC connection migration with load balancer stickiness. — Connection IDs help endpoints; L4/L7 routing still needs compatible designs.
  5. Using 0-RTT for non-idempotent POST blindly. — Replay risk; restrict to safe/idempotent traffic or disable.

Practice checkpoint

  1. Why is DNS often UDP?

    • Answer: Small query/response fits one datagram; low setup overhead; app can retry on timeout.

  2. What problem does QUIC multiplexing solve that HTTP/2 on TCP still has?

    • Answer: TCP head-of-line blocking—all HTTP/2 streams wait when one TCP segment is lost; QUIC streams recover independently.

  3. HTTP/3 runs on which transport?

    • Answer: QUIC over UDP (typically UDP port 443).

  4. Name one reason a site might still serve HTTP/2 to some clients.

    • Answer: QUIC/UDP blocked on network path, no h3 advertisement, or client/server without HTTP/3 support—fallback to TCP.

Interview angles

  • “TCP vs UDP?” — TCP: reliable ordered byte stream, congestion control. UDP: datagrams, best effort; apps or QUIC add semantics.
  • “Why did Google push QUIC?” — Reduce handshake latency, fix HOL blocking, deploy transport improvements without OS kernel cycles; standardized as IETF QUIC.
  • “How does browser pick HTTP/3?” — Prior visit Alt-Svc cache or HTTPS RR in DNS; attempts QUIC, falls back to HTTP/2/1.1 on failure.

Next: /networking/learn/transport/tls-certificates-pki/