Networking & Traffic · lesson 1 of 7 · about 30 min
What happens between pressing Enter and the first byte: DNS and its TTL trade-off, the TCP handshake and slow start, why games and calls choose UDP, how HTTP/1.1, 2 and 3 differ under loss, and what happens when the phone book itself goes down. Tap any for a plain-language card.
Pressing Enter
That is why distance matters more than bandwidth for small pages: at an 80 ms round trip, the old TLS 1.2 setup alone is 240 ms before any request. It is also why (QUIC) folds the transport and encryption handshakes into one round trip, and why reusing an open connection is so valuable: a warm connection skips all of this.
Set RTT 150 ms (across an ocean), TLS 1.2, HTTP/2: more than half a second to the first byte. Then try QUIC with 0-RTT.
390 ms to the first byte: 280 ms of setup (DNS 40 ms plus 240 ms of handshakes) before the request even starts, then 80 ms of travel and 30 ms of server time. At short distances the server's own time matters more.
The number of round trips per step is what the protocols specify (TCP 1, TLS 1.2 two, TLS 1.3 one, QUIC one). DNS cost and server time are your inputs.
DNS caching
So the TTL is a trade-off. Short (30 to 60 seconds): moves and failovers take effect fast, but every resolver asks your name servers every minute, which is expensive load, slower first lookups for users and more exposure to a name-server outage. Long (hours): few queries, resilient to a provider hiccup, but an emergency move takes hours to be seen everywhere. A common practice: lower the TTL a day before a planned migration, then raise it again.
Choose a 1-hour TTL and look 5 minutes after the change: about 92% of resolvers still send users to the old address.
With a 5 min TTL, 0% of resolvers still point users at the old address 5 minutes after the change, and everyone has switched after 5 min. The price of that: 1M resolvers refresh about every 5 min, so your name servers answer roughly 3.33K queries a second just to keep caches warm.
Exact for caches whose remaining lifetime is uniform; queries per second = resolvers ÷ TTL. Real resolvers sometimes cap or extend TTLs, so allow extra margin.
TCP in motion
The window needed to fill a link is the : 100 Mbit/s at 80 ms is a million bits, about 1 MB, in flight. That is why transfers over long distances feel slow even on fat links, and why a few percent of packet loss ruins throughput: every loss cuts the window. This is a simplified Reno-style simulation, one round per row.
Send 200 KB at 80 ms RTT with no loss, then add 2% loss and watch the time and the window pattern.
200 KB over a 100 Mbit/s link took 400 ms: 4 round trips of 80 ms, achieving 4.0 Mbit/s (4% of the link). The pure transfer time at full speed would be 16 ms: the rest is handshake and window ramp-up.
Simplified Reno: initial window 10, doubling in slow start, +1 per round trip afterwards, halving on loss, capped by the bandwidth-delay product. Seeded.
TCP or UDP?
Here a sender emits a packet every 20 ms (a game at 50 updates a second). TCP resends losses one round trip later and delivers in order; UDP delivers what arrives. Watch what loss does to TCP's delay (typical and p99) while UDP's delay stays at half a round trip and simply loses some packets.
This is also the idea behind : take UDP's freedom and rebuild reliability per stream, so one loss stalls only its own stream.
Set 100 ms RTT and 2% loss: UDP stays at 50 ms but loses 2%; TCP's p99 jumps to well over 100 ms.
At 2.0% loss, UDP delivers 97.5% of packets after 50 ms each and drops the rest. TCP delivers all of them, but 9.8% arrive late because they waited behind a gap, and its p99 is 155 ms (worst 155 ms). For real-time data, the late ones are no use.
3,000 seeded packets. A lost TCP packet is resent one round trip after it would have arrived; delivery is in order. UDP delay is half the round trip.
HTTP versions
The model is deliberately simplified (it ignores caching, priorities and congestion details), but it captures the three effects: waves of requests for 1.1, a connection-wide stall per loss for 2, a single-stream stall for 3. Try high latency with low loss, then low latency with high loss, and see which version wins where.
At 100 ms and 1% loss with 60 resources, HTTP/2 beats 1.1 on a clean link, and falls behind HTTP/3 as loss rises.
For 60 resources at 100 ms with 1.0% loss, the fastest is HTTP/3 (QUIC). Loss is where HTTP/3 pays off: a dropped packet stalls only one stream instead of the whole connection.
A simplified analytical model, not a browser benchmark: 30 KB per resource; 1.1 uses waves of 6 requests; each loss costs one round trip, applied to a single connection (2), to one of the streams (3), or to one of six connections (1.1).
Pick the transport
The right transport depends on what a late or lost packet means to the application. Each answer is worth 20 XP.
Ask: is a late packet still useful? and must everything arrive?
A bank's REST API for moving money. Every byte must arrive, once, in order.
Tip: press 1 to 3 to answer, Enter for the next one.
Who lives by this
Four real systems and standards behind everything in this lesson.
resolver → root → .com → the site's name servers
The root of DNS is served under 13 named identities (a.root-servers.net to m.root-servers.net), run by 12 independent organisations, each announced from many sites using anycast, so a query is answered by a nearby copy. It is a textbook case of a critical directory made resilient by replication and independent operators.
your domain → anycast name servers → health-checked answers
AWS publishes a 100% availability SLA for Route 53's DNS service, backed by name servers spread across many locations with anycast, and offers health checks and failover records so that an answer can change when a target stops responding. The same pages recommend keeping TTLs low enough for failover to matter.
Mirai botnet → DNS provider overwhelmed → sites unreachable
In October 2016 a DDoS attack from the Mirai botnet overwhelmed DNS provider Dyn. Many large sites that relied on it alone were unreachable for many users for hours although their own servers were fine. The incident is the standard argument for using two independent DNS providers.
UDP + TLS 1.3 + streams → RFC 9000 and RFC 9114
QUIC began as a Google experiment and was standardised by the IETF in 2021 (RFC 9000), with HTTP/3 in RFC 9114 (2022). It moves reliability and encryption into a UDP-based transport with independent streams and connection migration, to remove TCP's head-of-line blocking and shorten connection setup.
Interview angle
Six questions, each worth 20 XP. “What happens when you type a URL and press Enter?” is one of the oldest interview questions.
Walk the chain in order, DNS, TCP, TLS, HTTP, and say where each round trip goes and what you would cache.
Roughly how many round trips before a browser can send the HTTP request on a brand-new HTTPS connection with TLS 1.3 over TCP (ignoring DNS)?
Tip: press 1 to 3 to answer, Enter for the next one.
Break it
Why not everyone at once? keep a cached answer until its runs out. During an outage, users behind a resolver whose cache is still valid keep working; as each cache expires and cannot refresh, those users fail. So the failing share grows as t ÷ TTL until everyone has expired or the provider returns. A longer TTL buys time (at the price of slow changes, last scene); a second, independent DNS provider lets resolvers refresh from the other and removes the failure altogether.
Start with one provider, a 5-minute TTL and a 2-hour outage: everybody fails. Then raise the TTL, then add the second provider.
The outage (120 min) outlasts the 5 min TTL, so every cached answer expired with nothing to refresh it: all users are cut off, with every web server healthy.
Failing share = min(1, time ÷ TTL) for a single provider (caches expire uniformly); zero with two providers. A simplified model of the 2016 pattern.