How a Web Request Travels (End-to-End)

📘 Chapter 2: How the Internet Works ⏱️ 9 min read 🎯 Networking Fundamentals

You type https://www.amazon.com and press Enter. In under a second, a complex page with personalized recommendations, live prices, and dynamic content appears. What happened in that second? Let's trace every hop.

The Complete Journey

End-to-End Request Journey 1. User types URL amazon.com + Enter 2. DNS Resolution ~5ms (cached) to ~50ms 3. TCP Handshake ~15ms (1.5 × RTT) 4. TLS Handshake ~10ms (TLS 1.3) 5. HTTP GET Request Headers + cookies sent 6. CDN / Load Balancer Route to best server ~2ms 7. Application Server Process logic ~50ms 8. Database Query ~5ms (cached) to ~30ms 9. Cache (Redis) ~1ms for cached data 10. Response: HTTP 200 OK + HTML body (~50KB gzipped) Content-Encoding: gzip | Cache-Control: private, max-age=0 | Set-Cookie: session=abc... 11. Parse HTML Discover CSS, JS, images 12. Fetch Sub-resources 50+ parallel requests (HTTP/2) 13. Render & Paint DOM + CSSOM → pixels Total: ~200-500ms to first meaningful paint DNS: 5ms | TCP: 15ms | TLS: 10ms | Server: 80ms | Transfer: 30ms | Render: 60-300ms Where things can go wrong at each step: DNS: Slow resolver, expired cache, propagation delay TCP/TLS: Cold connection (no reuse), distant server Server: Slow query, no caching, blocking I/O, cold start Network: Congestion, packet loss, routing issues Response: Too large, not compressed, not cached Render: Blocking JS, unoptimized images, layout thrash
Fig 1. The complete journey of a web request — from keypress to pixels on screen.

Step-by-Step Breakdown

1–4: The Connection Phase (30–75ms)

Before a single byte of your actual request is sent, three handshakes must complete:

  • DNS: Translate the domain to an IP (often cached, ~0-5ms; cold lookup ~50ms)
  • TCP: Establish a reliable connection (1.5 round trips)
  • TLS: Negotiate encryption (1 round trip with TLS 1.3)

Why Latency Adds Up

If the server is 50ms away (US East Coast to Europe), the connection phase alone costs:

DNS:  50ms (1 RT if uncached)
TCP:  75ms (1.5 × 50ms RTT)
TLS:  50ms (1 RT with TLS 1.3)
─────────────────────────────
Total: 175ms before any data flows

This is why CDNs place servers close to users — reducing that 50ms RTT to 5ms transforms the experience.

5–6: Routing (2–20ms)

The HTTP request hits infrastructure before reaching application code:

  • CDN edge: For static content, the CDN responds directly from cache — no origin server needed
  • Load balancer: Routes to a healthy server with capacity (round-robin, least connections, or consistent hashing)
  • Reverse proxy: May add headers, strip paths, rate-limit, or serve cached responses

7–9: The Server Work (10–200ms)

This is where your application code runs:

  • Authentication: Validate the session cookie or JWT token
  • Business logic: Determine what data this user needs
  • Cache check: Is this response already computed? (Redis: ~1ms)
  • Database queries: Fetch personalized data (5–30ms per query)
  • Response assembly: Serialize JSON or render HTML template

10–13: The Response Phase (30–300ms)

Data flows back and the browser renders:

  • Transfer: Response bytes stream over the connection (gzip cuts this 60-80%)
  • Parsing: Browser builds DOM from HTML, discovers additional resources
  • Sub-resources: CSS, JavaScript, images — each may trigger new requests (HTTP/2 multiplexes these)
  • Render: Layout calculation → paint → composite → pixels on screen

Connection Pooling and Keep-Alive

The connection phase (DNS + TCP + TLS) is expensive. Smart systems avoid repeating it:

TechniqueSavesUsed Where
Keep-AliveTCP + TLS handshake on subsequent requestsBrowser → server (HTTP/1.1 default)
Connection poolingPre-established connections ready to useServer → database, service → service
HTTP/2 multiplexingOne connection for all requests to a hostBrowser → CDN/server
DNS prefetchDNS lookup happens before user clicks<link rel="dns-prefetch">
TCP preconnectConnection established before request needed<link rel="preconnect">

Anatomy of a Request to amazon.com

Here's an approximate breakdown of what happens when you load Amazon's homepage (from a US East Coast location):

PhaseTimeNotes
DNS lookup~2msCached in local resolver (Amazon's TTL: 60s)
TCP + TLS~12msConnecting to nearby CloudFront edge
HTTP request sent~1msGET / with cookies (~2KB of headers)
Server processing~80msPersonalization, recommendations engine
First byte received (TTFB)~95msTotal time to first response byte
HTML downloaded~20ms~80KB gzipped
Sub-resource requests~50ms200+ resources via HTTP/2 (already connected)
First contentful paint~400msAbove-the-fold content visible
Fully interactive~2.5sAll JS loaded, hydrated, clickable

Notice: 95% of perceived latency is after the first byte arrives — rendering and JavaScript execution dominate. But the network phase is where system designers have the most control.

Geographic Considerations: Speed of Light

Light in fiber travels at ~200,000 km/s. This creates a hard physical limit:

RouteDistanceMin RTT (speed of light)Real-world RTT
NYC → London5,570 km~56ms~75ms
NYC → Tokyo10,850 km~108ms~170ms
NYC → Sydney16,000 km~160ms~230ms
NYC → same city~10 km~0.1ms~2ms

Why Server Location Is a Design Decision

If your servers are in US-East and your users are in Australia, every request starts with a 230ms penalty — and that's just the RTT. TCP handshake needs 1.5 RTTs (345ms), TLS adds another RTT (230ms). Your user waits 575ms before a single byte of your response.

Solutions: CDN edge caching, regional deployments, or edge computing (run logic closer to users).

Optimization Opportunities at Each Layer

Quick Wins by Layer

  • DNS: Use a fast provider (Cloudflare, Route53), prefetch DNS for known links
  • Connection: Enable HTTP/2, use preconnect, keep connections alive
  • TLS: Use TLS 1.3, enable session resumption, OCSP stapling
  • Request: Minimize cookies (they're sent on every request), use CDN for static assets
  • Server: Cache aggressively (Redis/Memcached), optimize queries, async processing
  • Response: gzip/Brotli compression, paginate large responses, stream when possible
  • Rendering: Critical CSS inlined, defer non-essential JS, optimize images (WebP/AVIF)

Request Journey Walkthrough

Step through a request to https://shop.example.com/products/42 and see what happens at each hop:

Click "Next" to trace the request through the network stack.

🎯 Key Takeaway

Every millisecond in the request path is a design decision. DNS choice, server location, connection reuse, caching strategy, compression, and rendering optimization — each is a lever you can pull. Understanding the full path reveals that performance isn't one big fix; it's dozens of small wins that compound. The engineers who build fast systems understand every hop and optimize the ones that matter most for their users.

Further reading: "High Performance Browser Networking" by Ilya Grigorik (free at hpbn.co) · WebPageTest.org for real request waterfalls · Chrome DevTools Network panel for hands-on exploration