The Uptime Engineer
👋 Hi, I am Yoshik Karnawat
You'll learn why HTTP/2's multiplexing doesn't eliminate head-of-line blocking (it just moves it to the transport layer), how QUIC achieves 81.5% faster transfers under packet loss by abandoning TCP entirely, and why connection IDs matter more than IP addresses for mobile reliability.
🔧 This Week's Command
curl -I https://www.cloudflare.com/ --http3-only -w "\nHTTP Version: %{http_version}\nTime to First Byte: %{time_starttransfer}s\n"Test if a server supports HTTP/3 and measure TTFB. If connection fails, server doesn't support QUIC. Compare with --http2 flag to benchmark protocol performance differences.
🔥Tool Spotlight
QuicDraw. Open-source HTTP/3 security testing tool for racing and fuzzing QUIC servers. Can send 117+ streams in a single packet for race condition testing. Essential for testing HTTP/3 apps.
💼 Hot Jobs
DevOps Engineer) @ Zoom - Remote
$87,600 - $186,000 / year
Apply →
Senior Software Engineer - Devops @ Roku
Apply →
Your users are waiting 200ms longer than they need to.
Not because your backend is slow. Not because your CDN is misconfigured.
Because HTTP/2, the protocol 84% of production systems run on has a fatal flaw that no amount of tuning can fix.
It's called head-of-line blocking.
And HTTP/3 eliminates it by doing something radical: abandoning TCP entirely.
The Problem HTTP/2 Couldn't Solve
HTTP/2 introduced multiplexing. Multiple requests over a single TCP connection.
No more juggling 6-8 parallel connections like HTTP/1.1.
Headers compressed. Server push enabled. Problem solved, right?
Wrong.
HTTP/2 still runs on TCP.
TCP guarantees ordered delivery. If packet 5 gets lost, TCP buffers packets 6, 7, 8 and waits for retransmission.
This happens at the transport layer, invisible to HTTP/2.
The cascade:
Your HTTP/2 connection multiplexes 20 streams. Packet carrying data for Stream 3 gets lost.
TCP blocks all 20 streams including streams that have nothing to do with the lost packet.
Under 2% packet loss, HTTP/2 performs worse than HTTP/1.1.
At 12% packet loss, HTTP/2 takes 113 seconds to complete transfers that HTTP/3 finishes in 21 seconds.
That's 81.5% slower.
HTTP/3's Architecture: QUIC Over UDP
HTTP/3 replaces TCP with QUIC (Quick UDP Internet Connections).
QUIC runs on UDP, not TCP.
This sounds insane. UDP is connectionless, unreliable, no ordering guarantees.
But QUIC reimplements TCP's reliability, congestion control, and flow control at the application layer with critical improvements TCP can't make due to kernel ossification.
The Three Architectural Wins
1. Stream-level independence
QUIC natively understands streams.
Packet loss affects only the stream that packet belongs to.
Lost packet for Stream 3? Streams 1, 2, 4-20 continue processing immediately.
TCP head-of-line blocking: eliminated.
2. Combined handshake
TCP + TLS handshake: 3 RTT before application data flows.
QUIC handshake: 1 RTT for new connections, 0 RTT for resumed connections.
Cloudflare measures 12.4% faster time-to-first-byte with HTTP/3 (176ms vs 201ms).
3. Connection migration
TCP connections are identified by: source IP, source port, dest IP, dest port.
Change networks (Wi-Fi → cellular)? Your source IP changes. TCP connection breaks.
QUIC uses connection IDs independent of IP address.
Switch networks mid-transfer? Connection continues seamlessly.
This matters for mobile users constantly roaming between networks.
QUIC Internals
UDP doesn't guarantee delivery or ordering.
QUIC builds these guarantees on top.
Packet structure:
Connection ID (not tied to IP)
Packet number (for loss detection)
Encrypted payload (TLS 1.3 built-in)
Stream frames (multiplexed data)
Unlike TCP, QUIC encrypts packet metadata including packet numbers.
Attackers can't infer user behavior from packet counts or timing.
Loss detection:
QUIC tracks sent packets. When ACK doesn't arrive within timeout, marks packet lost and retransmits.
Retransmitted packets get new packet numbers (unlike TCP).
This avoids retransmission ambiguity. You always know which transmission triggered an ACK.
More accurate RTT measurements = better congestion control.
Congestion control:
QUIC implements congestion control at the application layer.
Because QUIC runs in userspace (not kernel), algorithms can be updated without OS patches.
Cloudflare can ship improved congestion control logic without waiting for Linux kernel updates.
Aspect | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
Transport | TCP | TCP | QUIC (UDP) |
Multiplexing | No (6-8 parallel connections) | Yes (single connection) | Yes (QUIC streams) |
Head-of-line blocking | HTTP-layer only | TCP-layer (fatal) | Eliminated |
Handshake RTT | 3 RTT (TCP + TLS) | 3 RTT (TCP + TLS) | 1 RTT (0 RTT resume) |
Connection migration | No | No | Yes |
Encryption | Optional (TLS) | Optional (rarely cleartext) | Mandatory (TLS 1.3) |
Performance at 12% packet loss | Baseline | 81.5% slower than HTTP/3 | 81.5% faster than HTTP/2 |
When HTTP/3 Wins (and When It Doesn't)
HTTP/3 advantages:
High packet loss (>2%): Mobile networks, congested Wi-Fi, long-distance
Mobile network switching: Connection migration prevents reconnection storms
Small transfers (<50KB): Faster handshake benefits API requests, initial page loads
HTTP/2 advantages:
Low packet loss, high bandwidth: Data center to data center, clean fiber
Large transfers (>1MB): Kernel TCP avoids userspace overhead
Mature tooling: Load balancers, proxies, monitoring tools have 10 years of HTTP/2 optimization
HTTP/3 Discovery
Servers can't just start speaking HTTP/3. Clients need to discover support.
The upgrade flow:
Client connects via HTTP/2 (TCP/TLS)
Server returns
Alt-Svc: h3=":443"headerClient learns: "This server supports HTTP/3 on UDP port 443"
Client caches this information
Future requests attempt HTTP/3 first, fallback to HTTP/2 if unavailable
Example from YouTube:
HTTP/2 200 alt-svc: h3=":443"; ma=2592000
ma=2592000 = cache for 30 days.The Fallback Reality
HTTP/3 implementations must always fallback to HTTP/2 or HTTP/1.1.
Why?
UDP traffic often blocked or rate-limited by:
Corporate firewalls
Mobile carriers
Middleboxes that don't understand QUIC
Misconfigured routers
35% of websites support HTTP/3, but only ~40% of traffic uses it.
Enabling HTTP/3 should never break clients. If QUIC fails, client falls back to TCP.
What Changes
HTTP/2's TCP head-of-line blocking causes all streams to stall when any packet is lost.
HTTP/3 eliminates transport-layer head-of-line blocking through stream-level independence.
QUIC combines TCP and TLS handshakes into 1 RTT (vs 3 RTT), reducing connection latency by 12.4% in production.
HTTP/3 outperforms HTTP/2 by 81.5% under high packet loss, but HTTP/2 can win on pristine networks.
All major CDNs support HTTP/3, but adoption requires UDP 443 reachability and QUIC-capable origin servers.
Join 1,000+ engineers learning DevOps the hard way
Every week, I share:
How I'd approach problems differently (real projects, real mistakes)
Career moves that actually work (not LinkedIn motivational posts)
Technical deep-dives that change how you think about infrastructure
No fluff. No roadmaps. Just what works when you're building real systems.
👋 Find me on Twitter | Linkedin | Connect 1:1
Thank you for supporting this newsletter.
Y’all are the best.