Networking & Protocols
QUIC internals: prove it on the wire
Reading about QUIC is not the same as watching a connection survive a network change in a packet capture. Stand up a real HTTP/3 server, prove each headline claim of the unit on the wire, then measure the CPU bill — so the deployment decision is grounded in your own numbers, not the marketing.
Turn the unit’s mental model into evidence: capture and read a 1-RTT handshake, demonstrate stream independence under loss, watch a connection migrate across an IP change, expose the 0-RTT replay risk, and measure QUIC’s CPU cost versus TCP on a fast link — then write the deployment call.
Run an HTTP/3 (QUIC) server and a TCP/HTTP-2 baseline, and produce a wire-evidence report that demonstrates the unit's five core mechanisms and quantifies QUIC's CPU-vs-latency tradeoff — every claim backed by a capture, a trace, or a measurement.
- An annotated handshake artifact (qlog or trace) showing QUIC at 1 RTT and TCP+TLS at 2 RTT to first application byte, with the round trips marked.
- A loss-injection comparison: a trace or metric proving QUIC stalls only the lost stream while HTTP/2 stalls all streams under the same loss, with the per-stream stall times reported.
- A migration capture showing one Connection ID across two source addresses plus the PATH_CHALLENGE/PATH_RESPONSE pair, and confirmation that no re-handshake occurred.
- A before/after for the 0-RTT defense: the replayed request executing twice without the guard, and rejected (or 425 Too Early) with it.
- A CPU-vs-goodput table: QUIC and TCP at the same bitrate, QUIC with and without UDP GSO, with the per-byte CPU overhead and the GSO recovery stated as percentages.
- A one-page deployment recommendation naming which paths (WAN/mobile vs fast LAN) should run QUIC versus TCP, justified by your own handshake, loss, and CPU numbers.
- Swap the congestion controller (NewReno → CUBIC → BBR) on the QUIC server and compare goodput and tail latency under the same injected loss, illustrating why pluggable CC makes cross-stack benchmarks unfair.
- Build a small observability layer: parse qlog into the four signals a network team lost when packets went opaque (per-stream request counts, RTT, loss rate, fallback rate) and show it reconstructs what tcpdump no longer can.
- Rotate Connection IDs (NEW_CONNECTION_ID) on migration and confirm in the capture that an on-path observer cannot link the pre- and post-migration identities.
- Add an anti-amplification probe: send a spoofed-source Initial smaller than 1200 bytes and confirm the server refuses to over-respond, then verify it honors the 3x budget to an unvalidated address.
This is how QUIC stops being abstract: you watch the 1-RTT handshake, see one stream stall while others flow, capture a connection surviving an IP change, and trip the 0-RTT replay yourself before fixing it — then you put a number on the CPU bill and write the deployment call. Doing it once on the wire turns the unit’s claims into things you have verified rather than read, which is exactly the posture you need when the production decision lands on your desk.