Life of a request

"What happens when you type a URL into a browser and press Enter?" is a common interview question because there is no bottom to it. A good answer touches every layer. A great answer attaches numbers to each layer and says where the time actually goes.

This page ties the networking pages together. We follow one request from a browser in Mumbai to a server in Virginia and back, through caches, DNS, TCP, TLS, a CDN, a load balancer, an app server, a cache and a database. Then we put numbers on each step.

The full path

Here is the journey for https://shop.example.com/products/42, with nothing cached yet:

1. The browser checks its HTTP cache. A fresh copy ends the story at 0 ms of network time. See HTTP.
2. DNS. The browser checks its host cache, then the OS resolver, then a recursive resolver, which asks the authoritative servers on a miss. The CDN's DNS returns the IP of a nearby point of presence (PoP). See DNS.
3. TCP handshake to that IP: SYN, SYN-ACK, ACK. One round trip. See networking basics.
4. TLS 1.3 handshake: one more round trip, and the client checks the certificate chain. See TLS. With HTTP/3, steps 3 and 4 merge into one QUIC round trip.
5. The request reaches the CDN edge. A cacheable response is answered there. Otherwise the edge forwards the request to the origin over a connection it already holds open. See CDNs.
6. The origin load balancer picks a healthy app server. See load balancing.
7. The app server. The kernel accepts the connection and wakes the event loop through epoll (async I/O). The framework parses the request, runs middleware such as auth and rate limits, and calls the handler (how code runs).
8. Cache and database. The handler checks Redis, a sub-millisecond round trip inside the data center. On a miss, it queries Postgres. The query planner (query execution) uses a B-tree index (B-tree storage engines), and the pages come from memory, not SSD. That is the memory hierarchy at work.
9. The response is serialized (serialization), compressed, encrypted and sent back through the load balancer and CDN. The CDN may cache it on the way.
10. The browser renders. It fetches CSS, JavaScript, fonts and images, often over the same HTTP/2 or HTTP/3 connection. Then it builds the DOM, runs JavaScript, lays out the page and paints it.

Concepts in this section

Read them in order. The first one puts numbers on the path, and the rest use those numbers.

Common mistakes

• Optimizing code before counting round trips. For distant users, the network often costs more than the handler.
• Creating a new HTTP client per request. Each one pays handshakes again.
• Skipping the CDN for dynamic pages. A CDN also shortens handshakes and slow start on misses.
• Looking only at the median. A p99-only problem has a different cause than a problem that moves every request.

Key takeaways

• A cold HTTPS request costs DNS, one round trip for TCP, one for TLS and one for the request. At 200 ms round trip, that is nearly a second before your code matters.
• The speed of light sets a floor. Mumbai to Virginia cannot go below about 130 ms of round trip.
• A CDN helps even on misses, by ending handshakes close to the user and reusing warm origin connections.
• Second requests are faster because DNS, TCP, TLS and slow start are already paid for.

Further learning

ByteByteGo's animated walkthrough covers the same path from URL to rendered page in a few minutes.

What happens when... (alex/what-happens-when) collects the detailed version of this question.

High Performance Browser Networking (Ilya Grigorik) explains each layer in depth.