Networking Essentials
What happens between typing a URL and seeing a page, which latency numbers matter, and when to pick HTTP, gRPC or WebSockets in an interview.
On this page
Your server builds the product page in 30 ms. A shopper 8,000 km away still waits about 270 ms for the first byte, and that is with the address already cached. Almost 90% of that wait is three trips across the ocean and back.
Interviewers rarely ask about packets, but where that time goes decides where servers live and whether you need a CDN.
The idea
For small requests, distance costs more than bandwidth. You pay in round trips: a message out, a reply back. Light in fibre covers about 200 km per millisecond, so a round trip over 8,000 km takes at least 2 × 8,000 ÷ 200 = 80 ms. Real routes bend, so that is a lower bound.
A fresh HTTPS request needs three round trips before the first byte comes back: one to open the connection, one to set up encryption, one for the request. That is 3 × 80 = 240 ms, plus 30 ms on the server: the 270 ms from the hook. Most tricks in this module cut round trips or shorten them.
What happens when you open a URL
- round trips to server
- 0
- elapsed ms
- 0
1Nothing is cached locally, so the browser asks a nearby DNS resolver for the IP address of
shop.example.com.- round trips to server
- 0
- elapsed ms
- 40
2The resolver asks the domain's authoritative servers, which return
203.0.113.10with a TTL of 300 seconds. Say the lookup takes 40 ms.- round trips to server
- 0
- elapsed ms
- 40
3Resolver and browser both cache the answer for up to 300 seconds, so the next visit skips DNS.
- round trips to server
- 1
- elapsed ms
- 120
4TCP handshake: SYN out, SYN-ACK back. One round trip, 80 ms, and no page data has moved yet.
- round trips to server
- 2
- elapsed ms
- 200
5TLS 1.3 handshake: both sides agree on keys and the browser checks the certificate. Another 80 ms. The load balancer holds the certificate, so encryption ends here.
- round trips to server
- 3
- elapsed ms
- 270
6The encrypted
GET /crosses the ocean. The load balancer forwards it to an app server about 0.5 ms away, which spends 30 ms building the page.- round trips to server
- 3
- elapsed ms
- 310
7The first byte arrives after 40 + 80 + 80 + 80 + 30 = 310 ms. Only 30 ms of that was your code.
- round trips to server
- 4
- elapsed ms
- 420
8The browser asks for
/carton the same connection: no DNS, no handshakes, so 80 + 30 = 110 ms. Reusing connections is the cheapest speed-up there is.- round trips to server
- 4
- stale answer left (s)
- 300
9Failure: the machine at
203.0.113.10dies and you point DNS at a new address. Users whose resolvers cached the old answer keep hitting the dead one for up to 300 seconds; some clients cache even longer.
So the address in DNS should belong to something that survives one machine dying, such as a pair of load balancers sharing a floating IP.
Four layers, briefly
DNS turns a name into an IP address, and every layer caches the answer for the record's TTL. GeoDNS returns a different address depending on where the resolver is, which is how users reach the nearest region.
TCP gives a reliable, ordered byte stream: lost packets are resent and bytes arrive in order. The price is the handshake and head-of-line blocking: one lost packet holds up everything behind it. UDP has no handshake and no guarantees. Use it when late data is worthless (voice, video calls, game state) and let the app handle loss.
TLS encrypts the connection and proves the server's identity. TLS 1.3 takes one round trip to set up; the older TLS 1.2 takes two. Most designs terminate TLS at the load balancer, so app servers do not each manage certificates.
HTTP is request and response: method, path, headers, body, status code. HTTP/1.1 sends one request at a time per connection. HTTP/2 runs many requests as streams over one TCP connection, though a lost packet still stalls them all. HTTP/3 runs over QUIC, which is built on UDP: streams are independent and connection plus encryption setup takes one round trip.
HTTP, gRPC or WebSockets
| Option | Good at | Bad at | Pick it when |
|---|---|---|---|
| HTTP with JSON (REST) Usual default | Works everywhere: browsers, phones, caches, CDNs. Easy to read and debug. | Bigger text payloads. The client must ask; the server cannot push. | Public and client-facing APIs. |
| gRPC | Compact binary messages, typed schemas with generated clients, streaming, over HTTP/2. | Browsers need a proxy to call it. Harder to inspect by hand. | High-volume calls between your own services. |
| WebSocket | One long-lived connection where both sides send whenever they like. | Every open connection is state on a server, which changes scaling and deploys. | Two-way realtime features: chat, multiplayer, live editing. |
The default to say: "REST over HTTPS for clients, gRPC between services." Change your mind on the client side when the server must push; Realtime Communication compares the push options.
Numbers worth remembering
- Light in fibre: about 200 km per ms, so every 1,000 km adds at least 10 ms of round trip.
- Round trip inside one data center: about 0.5 ms. Across a continent (4,000 km): 40 ms or more. Across an ocean (8,000 km): 80 ms or more.
- New HTTPS connection: 3 round trips to the first byte with TLS 1.3, 4 with TLS 1.2. Reused connection: 1.
- 1 Gbit/s is 125 MB/s, because a byte is 8 bits.
A user 6,000 km from your only region opens your site, with the DNS answer already cached. How long until the first byte of the page arrives?
- Light in fibre: about 200 km per ms
- TLS 1.3: 3 round trips including the request
- The server takes 20 ms to build the page
Show the working
- One way: 6,000 ÷ 200 = 30 ms, so a round trip is 60 ms
- TCP + TLS + request: 3 × 60 = 180 ms
- Plus the server: 180 + 20 = 200 ms
Estimate 200 ms (anything from 100 ms to 600 ms is a good answer)
A server twice as fast saves 10 ms. A region near the user saves most of the 180.
In the interview
Bring networking up when distance matters: users on several continents with a latency target, mobile clients, or a feature where the server pushes. Phrases that show judgement: "Every round trip costs at least 80 ms from there, so I want fewer round trips, not faster servers." "TLS ends at the load balancer." "Clients get REST, services talk gRPC."
Users about 8,000 km from our only region say the app is slow. What do you do?
First I'd check where the time goes. If the server takes 30 ms but users wait a second, it's round trips: each costs at least 80 ms from there, and a new connection plus a few sequential API calls adds up fast.
So what's the fix?
Cheapest first: static files on a CDN, connections terminated at edge locations near users so handshakes are short, and one batched call for the home screen instead of five. If that's not enough, a read replica region near them, since most of this traffic is reads.
Follow-ups to expect:
- "TCP or UDP for a video call?" UDP, or a protocol built on it. A late frame is useless, so resending it only adds delay.
- "Is traffic behind the load balancer encrypted?" Inside a private network it often is not. If compliance or a zero-trust policy asks for it, re-encrypt to the servers or use mutual TLS between services, at some cost in CPU and certificates.
- "Why not fail over by changing DNS?" Cached answers live until the TTL runs out, sometimes longer. DNS moves traffic between regions over minutes; it does not survive a machine failure.
Common mistakes
The user from the estimate (60 ms round trip, 20 ms server, DNS cached) reaches a server that only speaks TLS 1.2. How long until the first byte?
Thirty internal services call each other hundreds of thousands of times a second, and teams want typed contracts. What fits those calls?
You moved a service to a new IP. The DNS record's TTL is 3,600 seconds. Twenty minutes later some users still reach the old address. Why?
What to practise next
The box that received every request in the tracer is next: Load Balancing. To see distance shape a whole design, work through Design Video Streaming.