Networking & Protocols

The twelve layers: one URL, seven actors

Crux When you type a URL, seven actors — browser, resolver, router, origin, CA, CDN edge, and render engine — execute twelve phases in sequence. This lesson maps the whole journey.

Your altitude — climbing toward senior

ZeroJuniorMiddleSenior

You are at junior altitude — the surface

◷ 10 min

You type a URL and a page appears in under 400 ms. That gap is not magic — it is twelve distinct phases executed by seven actors who have never met each other and never will. Knowing which actor owns which phase is the foundation of every performance and debugging skill in this chapter.

The seven actors

Every HTTPS request passes through a cast of characters, each owning exactly one concern:

Bea (browser) — initiates the request, renders the result.
Rex (recursive DNS resolver) — translates the hostname to an IP address.
Rita (router network) — carries packets hop-by-hop across the internet.
Cara (certificate authority) — vouched for the server’s identity before the request ever started; her signature lives inside the server’s certificate.
Patty (CDN/proxy) — intercepts the connection at a nearby edge point of presence (PoP), serves cached content, or forwards to origin.
Sven (origin server) — computes the real response when no cache can answer.
Bea’s render engine — parses the HTML/CSS/JS and paints pixels.

Phase	Actor	What happens	Typical cost
1. DNS lookup	Rex	hostname → IP	<1 ms warm / 30–100 ms cold
2. TCP connect	Rita + Sven/Patty	3-way handshake	~10–100 ms (RTT)
3. TLS handshake	Bea + Sven + Cara	key exchange, cert verify	1 RTT new / 0 RTT resumed
4. Proxy / rate-limit check	Patty	health check, cache lookup, WAF	<1–5 ms
5. HTTP request	Bea → Sven	GET / with headers	~1 RTT
6. Origin processing	Sven	auth, DB query, serialise	10–200 ms
7. HTTP response	Sven → Bea	status + headers + body	~1 RTT + body size
8. Subresource fetches	Bea (parallel)	CSS, JS, fonts, images	1–3 RTT (parallelised)
9. DOM + CSSOM parse	Bea	build render tree	0–50 ms
10. Layout + paint	Bea	position elements, rasterise	50–200 ms
11. JavaScript execute	Bea	event handlers, hydration	0–500 ms
12. LCP painted	Bea	largest visible element ready	total: 200–4000 ms

Why the order is fixed

Each phase depends on the output of the previous one. DNS must resolve before Bea knows which IP to connect to. TCP must complete before TLS can exchange keys. TLS must complete before HTTP can send the encrypted request. This strict sequencing is why round-trip count, not round-trip speed, is the primary latency lever — you can shorten each RTT by moving the server closer, but you cannot skip the RTTs without redesigning the protocol.

The one exception: CDN edge caching short-circuits the chain. If Patty has the answer in cache, phases 4–7 collapse into a single CDN response. Bea still pays DNS + TCP + TLS (phases 1–3), but those happen against a server 20 ms away instead of a server 200 ms away. That is the chapter’s central performance insight in one sentence.

The delivery metaphor

Think of the request as a package delivery:

You place an order (HTTP request).
The address is looked up in a phone book (DNS).
A van is dispatched on a road network (TCP + Rita’s routing).
The parcel is sealed in tamper-evident wrap (TLS).
A local depot might have the item already stocked (CDN cache).
The parcel arrives at your door (response).
You unbox and use it (browser render).

Each role is independent; each can be measured and optimised separately.

Why this works

The strict layer dependency exists for a good reason: each layer can be optimised, replaced, or failed independently. DNS can be changed without touching TLS. TLS can be upgraded (1.2 → 1.3) without changing HTTP semantics. This is the separation of concerns principle applied to networking at planetary scale.

Quiz

In what order do the first four phases run for a fresh HTTPS request?

Order the steps

Order the phases from keystroke to first paint:

1 DNS resolves the hostname to an IP
2 TCP three-way handshake
3 TLS 1.3 handshake and certificate verify
4 HTTP request sent
5 HTTP response received
6 Browser fetches subresources (CSS, JS, fonts) in parallel
7 Browser lays out DOM and paints the first visible content

Complete the analogy

Fill in the blank: the network stack is a _______ where each layer wraps the one below it.

Recall before you leave

01
Name the seven actors in an HTTPS request and one concern each owns.
02
Why can you not parallelise DNS, TCP, TLS, and HTTP?
03
What makes CDN edge caching the highest-leverage latency optimisation?

Recap

One URL triggers a twelve-phase chain executed by seven actors: Rex resolves the hostname, Rita’s routers carry packets, Bea negotiates TLS with Sven using Cara’s certificate, Patty may answer from cache, and Bea’s render engine paints the result. The phases are strictly ordered — each depends on the previous — so round-trip count, not round-trip speed, is the primary latency lever. A CDN edge hit at 20 ms instead of 200 ms shortens all three handshakes simultaneously. Knowing which actor owns which phase is the foundation for diagnosing every slow page load.

Connected lessons

unlocks

deepens into

appears again in199

Continue the climb ↑DNS, TCP, TLS in sequence: where the milliseconds go