Client and Server: The Journey of a Request (HTTP, DNS)
What this episode covers
From typing a web address to the page starting to appear, a request passes six stops in turn: DNS turns the name into an IP, TCP shakes hands with the server, TLS agrees on encryption, and only then do the request, the server's work and the response happen. The millisecond figures here are typical values chosen for the demo; real numbers vary with distance and server, but the structure is the same: the first three stops have nothing to do with the work itself, yet often take the biggest share.
That gives the two most common optimizations: cache the DNS answer, and reuse an established connection so the handshake and encryption happen only once. Slowing any stop adds the same amount to the total, which is why you ask first: which stop is the time going to?
Prerequisites
No prerequisites: you can start right here.
Where it is used in the real world
- Browser prefetching and preconnect Browsers such as Chrome resolve the domains on a page and open connections before you click, stealing time back from the first three stops.
- Public DNS (such as 1.1.1.1 and 8.8.8.8) They cache lookups for millions of users, so most queries never travel all the way to the source.
- HTTP/2 and HTTP/3 HTTP/2 runs many requests over one connection; HTTP/3 merges the transport and encryption handshakes, shortening the early stops further.
Watch next
- API Design: REST and RPC Coming soon
- Load Balancing: Spreading Traffic Over Many Machines Coming soon
- Caching and CDNs: Hit Rate Versus Freshness Coming soon
Episode 1
This is episode 1 of the “System Design” series (29 planned).