DNS, HTTP, browser request lifecycle, and QUIC

You typed a URL and hit enter. Before a single byte of your backend code runs, the network has already spent a budget of round trips — and that budget, not your server, is usually what makes a page feel slow.

0. The interview hinge

The canonical version of this question is blunt: "You typed a URL and the page is slow. Walk the stack and tell me where the time goes." A weak answer recites "DNS, then TCP, then the server sends HTML." A senior answer quantifies each hop, identifies which hops are serial RTTs you can collapse, and names the one place the time actually pools (usually the front-end render, not the network). The hinge is therefore: account for the round trips, then attack them.

1. Clarify the contract

This is a "walk the stack" case, so the contract is an explanation contract, not a CRUD API. The candidate must be able to:

• Trace the request path from URL bar to painted pixels, naming every actor (browser cache, OS resolver, recursive resolver, authoritative DNS, CDN, origin).
• Put a round-trip cost on each stage and show what caching / QUIC / 0-RTT removes.
• Compare HTTP/1.1 vs HTTP/2 vs HTTP/3 at the level of head-of-line blocking, not feature bullets.
• Explain the DNS TTL trade-off (failover speed vs. cache hit rate) as a staleness/replication decision.
• Say where page-load time actually goes once the bytes arrive — and it is rarely the network.

What it need not do: design the origin application, choose a database, or solve auth (that is C40). The scope ends at "first byte arrives and the page renders."

2. Put numbers on the round-trip budget

The load-bearing calculation for this entire case is the RTT budget before first byte. Assume a representative RTT = 50 ms to a regional server, a cold cache, and a modern stack (TCP + TLS 1.3). Each handshake is a serial dependency, so the costs add:

Now toggle the optimisations and watch the budget collapse. Each row removes serial round trips from the critical path:

*0-RTT sends the GET with the first crypto flight, so the request RTT and the handshake overlap — the data is in flight on the very first packet. Caveat: 0-RTT early data is replayable, so it is only safe for idempotent requests (a GET, never a "transfer $100").

The headline: QUIC plus 0-RTT collapses connection setup from 3 RTT to 0, taking the pre-request tax from ~150 ms down to ~0. At 50 ms RTT that is a 150 ms win on every cold connection — and on a mobile link at 150 ms RTT the same 3 saved round trips are worth 3 · 150 = 450 ms, which is the difference between "instant" and "sluggish." This is why the round-trip count, not bandwidth, is the number to attack first. Bandwidth helps the transfer; round trips dominate the setup, and for a small page the setup is most of the latency. See foundation lesson 02 for why latency and throughput are independent axes and why percentiles (p99) — not the mean — are the number that bites here (DDIA Ch. 1).

3. Define the surface area

The "API" here is the set of protocol exchanges on the path. Each is a question/answer that costs latency and can fail independently.

4. Model the data

The "data" on this path is the set of cacheable artifacts and the metadata that governs their staleness. Each lives at a different layer with a different TTL, and getting the TTL wrong is the single most common production bug here.

The mental model: a DNS record cached for its TTL is a replica with a staleness bound — exactly DDIA Ch. 5's replication/TTL trade. A long TTL means more clients read a stale (possibly dead) IP after you fail over; a short TTL means more cache misses and more resolver load. The cache headers (Cache-Control: max-age, ETag) play the same role for assets one layer up. The whole case is really "how stale can each replica be, and what does staleness cost when something changes?"

5. Linearized design — follow one request

Walk the request in the order it actually moves. The bottleneck — serial round trips — falls out naturally.

1. Resolve the name. The browser checks its own cache, then the OS cache, then asks the configured recursive resolver. On a true miss the resolver walks root → TLD → authoritative — but each of those is itself cached, so the common case is a single RTT (or zero). This is the first place a round trip either disappears (cached) or stalls the whole load (cold + slow resolver).
2. Open the connection. TCP three-way handshake (1 RTT), or QUIC's combined transport+crypto handshake (1 RTT, or 0 on resumption) directly over UDP.
3. Secure it. TLS 1.3 (1 RTT) for TCP; folded into the QUIC handshake so there is no separate cost.
4. Send the HTTP request. GET with cookies, headers, and cache validators. If the client holds a valid ETag and the resource is unchanged, the origin returns 304 with no body — a full RTT spent but a body transfer saved.
5. Route it. The request lands at the nearest CDN edge / load balancer first. A CDN hit answers from an edge ~10 ms away and the origin never wakes up; a miss proxies back to the origin application server. The CDN is the cheapest RTT reducer because it shrinks every RTT on the path, not just one stage.
6. Return HTML + assets with a cache policy. The origin sets Cache-Control/ETag so the next visit can skip steps 4–6 entirely.
7. Render. The browser parses HTML, discovers subresources (CSS, JS, images, fonts), opens further fetches, runs JavaScript, and paints. This is where the second latency budget lives — see the deep dive on where page-load time really goes.

6. Deep dives

(1) HTTP/2 TCP head-of-line blocking vs HTTP/3/QUIC per-stream delivery

HTTP/1.1 forced one request per connection at a time, so browsers opened ~6 parallel TCP connections per host to fake concurrency — 6× the handshakes. HTTP/2 fixed the application layer: it multiplexes many logical streams over a single TCP connection, so one handshake serves the whole page. But it left a subtler problem unsolved. TCP delivers a single, strictly ordered byte stream. If one packet is lost, TCP holds back every byte that arrived after it — across all streams — until the retransmission arrives, because TCP cannot know those later bytes belong to a different, independent HTTP/2 stream. So a single lost packet for the logo image stalls the CSS, the JS, and everything else multiplexed on that connection. That is TCP head-of-line blocking, and on a lossy mobile link it can erase HTTP/2's multiplexing win entirely (DDIA Ch. 8: networks are unreliable; loss and reordering are the normal case, not the exception).

HTTP/3 runs over QUIC, which is built on UDP and implements its own per-stream reliability. QUIC knows the stream boundaries, so a lost packet only stalls its own stream; the other streams keep delivering. The head-of-line blocking moves from "whole connection" down to "one stream," which is exactly where you want it. QUIC also folds the transport and TLS handshakes into one (the 1-RTT setup above), supports 0-RTT resumption, and — because the connection ID is independent of the IP/port 4-tuple — survives a network change (Wi-Fi → cellular) without a new handshake.

(2) Long vs short DNS TTL — failover speed vs cache hit rate

A DNS record's TTL is the staleness bound on a replicated value (DDIA Ch. 5). Set it long (say 24 h) and the vast majority of lookups hit a cache — zero DNS RTT, low resolver load, fast. But the cost is brutal on the day you need to move traffic: if a data centre or a load balancer IP dies, every client and resolver that cached the old IP keeps hitting the dead address until its TTL expires. A 24 h TTL means up to 24 h of clients pointed at a corpse. Set it short (say 30–60 s) and failover is near-instant — clients re-resolve within a minute and follow you to the new IP — but you pay with cache misses and a constant stream of DNS queries (more resolver load, an added ~1 RTT more often).

The senior move is to match TTL to volatility: long TTL for stable, anycast-fronted endpoints that rarely move; short TTL for the records you steer for failover or blue/green cutover. In practice you keep failover-critical records at 30–60 s and lean on anycast (one IP advertised from many sites, BGP routes you to the nearest live one) so that failover happens in the routing layer and does not depend on DNS TTL expiry at all. This is the same replication/staleness tension that foundation lesson 06 covers for asset caching — and the defer/cache mechanics for fingerprinted assets are taught there, so I won't re-derive them.

(3) Where page-load time actually goes

Here is the answer that separates seniors: for most real pages, the network handshake is not where the time goes — the front-end is. The ~200 ms cold network tax is real and worth attacking, but once the HTML arrives the browser must parse it, discover and fetch dozens of subresources (often the true bottleneck: 50+ requests, each needing a connection or a CDN round trip), parse and execute JavaScript on the main thread, build the render tree, and paint. A typical breakdown for a content page:

So when an interviewer says "the page is slow," the disciplined walk is: (1) is DNS cold or the resolver slow? (2) is this a fresh connection paying 3 setup RTTs we could collapse with QUIC/keep-alive? (3) is TTFB high — i.e. is the origin slow, fixable with a CDN cache hit? (4) or — most often — is the network fine and the page is shipping 2 MB of render-blocking JavaScript? You cannot know without splitting the budget; the failure of the weak candidate is assuming the slowness is "the server."

7. Trade-offs

The sharpest trade is HTTP/3 vs HTTP/2, because the "obvious" answer (newer is better) is incomplete. QUIC's per-stream delivery is a clear win on lossy links — but it rides UDP, and some corporate firewalls and carrier middleboxes throttle or block UDP, or simply haven't been tuned for QUIC's higher packet rates. The correct posture is not "switch everything to HTTP/3"; it is "advertise HTTP/3 via Alt-Svc, let capable clients upgrade, and keep HTTP/2-over-TCP as the fallback for everyone else." You get QUIC's win where the network allows it and lose nothing where it doesn't.

8. Failure modes

9. Interview prompts you should be ready for

Related foundation lessons

Three foundation lessons carry the load here, and I cite rather than re-derive them. Lesson 02 (latency & throughput) owns the RTT/latency math and the percentile argument — the entire round-trip budget above is an application of it. Lesson 06 (caching) owns the hit-rate→origin-load and TTL/staleness mechanics; the asset-cache and defer mechanics live there, so this case covers only the DNS-TTL and CDN-edge deltas. Lesson 15 (rate limiting & the edge) is the companion for what else happens at that same edge — TLS termination, admission control, and why the front door is the cheapest place to enforce cross-cutting concerns.