LESSON 4.1
How a request travels
DNS, TCP, TLS and HTTP in the order they happen, what each one costs, and why connection reuse matters so much for latency.
7 min read
When someone taps a button in your app, a surprising amount happens before your code runs. You don't need to be a network engineer for system design interviews, but you do need to know the steps, roughly what each costs, and which design choices make them cheaper.
The steps, in order
- DNS. The client turns
api.example.cominto an IP address. The answer is cached by the operating system, the browser and resolvers along the way, for as long as the record's TTL allows. A cold lookup can take tens of milliseconds; a cached one costs nothing. - TCP handshake. The client and server exchange SYN, SYN-ACK and ACK so both sides agree a connection exists. That is one full round trip before any data moves.
- TLS handshake. For HTTPS, the two sides agree on keys and the server proves its identity with a certificate. TLS 1.3 needs one more round trip (TLS 1.2 needed two).
- HTTP request and response. Finally the client sends
GET /feed, the server does its work, and the response comes back: one more round trip plus server time.
So a brand-new HTTPS request costs about three round trips before the server's own work. Within one data center a round trip is about half a millisecond, so nobody notices. Across an ocean it is 100 to 200 ms, and three of them is most of a user's patience gone.
- Same data center
- 0.5 ms
- Same region, different zone
- 1–2 ms
- US east to US west
- about 70 ms
- US to Europe
- about 80–100 ms
- US to Australia
- about 200 ms
Making it cheaper
Almost every networking optimization in a design is about avoiding those round trips or making them shorter.
- Reuse connections. Browsers keep connections alive; services use connection pools to databases and to each other. The handshake is paid once, not per request.
- Terminate TLS close to the user. A CDN or edge load balancer near the user does the handshakes over a short distance, then talks to your servers over long-lived, already-open connections.
- Cache DNS sensibly. Long TTLs make lookups cheap; short TTLs let you move traffic quickly during a failover. Pick per record.
- Move data closer. A CDN serving images from a nearby city removes the long round trips entirely.
HTTP versions
HTTP is the language of the request itself. The version changes how requests share a connection.
HTTP/1.1
- Universal
- Simple
- One request at a time per connection
- Browsers open 6 connections per host to compensate
HTTP/2
- Many requests multiplexed on one connection
- Header compression
- A lost TCP packet stalls every stream on that connection
Pick it when: The default between browsers and servers, and for gRPC.
HTTP/3 (QUIC)
- Multiplexing over UDP, so one lost packet stalls only its stream
- Faster connection setup
- Some networks block or slow UDP
Pick it when: Mobile clients on lossy networks, served from a CDN that supports it.
Where load balancers sit
A layer 4 load balancer forwards TCP connections without looking inside them. It is very fast and protocol-agnostic. A layer 7 load balancer understands HTTP: it can route /api/* to one pool and /images/* to another, terminate TLS, add headers and retry a failed request on another server. Most web systems use layer 7 at the edge; layer 4 shows up in front of databases, message brokers and anything that isn't HTTP.
What this means for your designs
When you draw the client talking to your system, remember three costs: a DNS lookup that is usually cached, handshakes that are paid per new connection, and distance that multiplies everything. Designs for global users put something near the user: a CDN, edge servers, or a full regional deployment. Designs with many internal service calls keep connections pooled and services in the same region, so each hop costs about a millisecond rather than a hundred.
Try it
Content Delivery Network HLD
Design a content delivery network: the system that exists to shorten these round trips.