One click, many steps
Someone in Berlin clicks https://snip.link/x7Kp. Snip's servers spend about 5 ms finding the long URL. Yet the
person waits several hundred milliseconds before anything happens. Almost all of that time is spent setting up the
conversation, not having it.
Four protocols take turns, each building on the one before:
| Step | Protocol | The question it answers |
|---|---|---|
| 1 | DNS | Which IP address is snip.link? |
| 2 | TCP | Can we open a reliable connection to that address? |
| 3 | TLS | Is this really Snip, and can we talk privately? |
| 4 | HTTP | Where does /x7Kp go? |
Step through it
Here's the first click from a browser that has never visited Snip, with Snip's servers about 100 ms round trip away:
10 messages. Use Next and Back to follow them in order.
Text version
- Browser → DNS resolver: snip.link? — The browser and operating system check their own caches first. Nothing there, so they ask a DNS resolver, usually run by the internet provider or a public service.
- DNS resolver → Name servers: root → .link → snip.link — If the resolver hasn't cached the answer, it asks the root servers who handles .link, then the .link servers who handles snip.link, then Snip's own name servers. Each hop can be a round trip.
- Name servers → DNS resolver: 203.0.113.10, TTL 300 (reply) — Snip's name servers answer with an IP address and a TTL: how many seconds the answer may be cached. Here, five minutes.
- DNS resolver → Browser: 203.0.113.10 (reply) — The resolver passes the answer on and keeps it, so the next person using this resolver skips the lookup.
- Browser → Snip: TCP SYN — Now the browser opens a TCP connection: a three-way handshake (SYN, SYN-ACK, ACK) that costs one round trip before any data can flow.
- Snip → Browser: SYN-ACK (reply) — The server agrees. One round trip gone: about 100 ms.
- Browser → Snip: TLS ClientHello — Next, TLS. The browser proposes encryption settings and a key share.
- Snip → Browser: certificate, key share (reply) — The server proves it owns snip.link with a certificate and completes the key exchange. With TLS 1.3 this is one more round trip; older TLS 1.2 needed two.
- Browser → Snip: GET /x7Kp — Finally the actual request, encrypted.
- Snip → Browser: 302 Location: … (reply) — Snip spends about 5 ms on the lookup and answers. Then the browser does this whole dance again for the long URL's site.
Count the round trips: one or more for DNS, one for TCP, one for TLS, one for the request. At 100 ms each that's 400 ms or more for 5 ms of real work, before the browser even starts on the destination site.
The second click is much cheaper
Almost every step has a cache or a reusable result:
- DNS answers are cached by the browser, the operating system and the resolver, for as long as the TTL allows.
- Connections are kept open. HTTP keep-alive lets the browser reuse the TCP and TLS connection for later requests, so it pays the handshakes once.
- TLS sessions can resume, skipping some of the work on reconnect.
So a returning visitor's click often costs a single round trip. That's why the first visit to a site feels slower than the rest, and why benchmarks that only measure warm connections can mislead.
What this means for design
- Round trips, not bandwidth, dominate small requests. Snip's redirect is a few hundred bytes. Making it faster means fewer or shorter round trips: keep connections open, and put servers closer (02.05 A CDN for static content).
- DNS TTLs decide how fast you can move. If Snip's record has a TTL of a day and you move to new servers, some users keep going to the old address for up to a day. Teams lower the TTL ahead of a planned move, then raise it again afterwards.
- DNS can send users to different places. Many services answer the same name with different addresses depending on where the user is, or which servers are healthy. It's a coarse form of load balancing (03.06 Load balancers), limited by caching: a change only takes effect as caches expire.
- DNS is part of your availability. If nobody can look up your name, it doesn't matter that every server is up. That's why serious services use more than one DNS provider or name server location.
Newer HTTP versions cut the setup cost further. HTTP/2 sends many requests over one connection at once, and HTTP/3 runs over QUIC, which combines the transport and encryption handshakes into one round trip. That's 03.02 TCP vs UDP.
Seen in production
Meta
2021DNS and backbone
During routine maintenance, a command meant to assess Facebook's backbone capacity took down every connection in the backbone, and a bug in an audit tool failed to stop it. Facebook's DNS servers are built to stop advertising themselves when they can't reach the data centres, so they did, and became unreachable even though they were still running. Recovery was slow because the same failure broke internal tools, and engineers had to go on site to secured data centres.
What we foundServers that were running fine became unreachable because nobody could look up their names.
More details about the October 4 outageengineering.fb.com ↗Snip moves to a new hosting provider and updates its DNS record to the new IP address. The old record had a TTL of 86,400 seconds. What happens?
Recap
Interview questions
What happens when you type a URL into a browser and press Enter?