Introduction

You do it dozens of times a day without thinking about it. You type a URL, hit enter, and a webpage appears. It feels instant. It feels simple. It isn't.

In the half-second between pressing enter and seeing pixels on your screen, your browser quietly runs through a surprisingly deep sequence of steps — translating a human-readable name into a number, negotiating a secure channel, fetching a document, and turning raw bytes into something you can actually read. None of it is magic. All of it is engineered.

It's easy to assume DNS happens, then a request goes out. But the details matter — especially when things go wrong, or when you're trying to understand why a page is slow, or why a user in a different region has a worse experience.

This article walks through the full journey, one layer at a time. Not to overwhelm — but because once you see the whole chain, the pieces start to make sense in a way that a partial explanation never quite does.

How Local DNS Resolution Works

1. Browser cache checked first. If a valid record exists and TTL hasn't expired — cache hit, stops here.
2. OS stub resolver checks /etc/hosts for manual overrides, then the OS-level DNS cache. Cache hit — stops here. (assuming mac for simplicity sake)
3. Router forwards the query to a configured DNS server — usually your ISP's resolver or a custom one like 8.8.8.8.
4. Recursive resolver takes over. If it has the answer cached — returns it immediately. If not — walks the full DNS tree (Root → TLD → Authoritative).

How Recursive DNS Resolution Works

Once the recursive resolver takes over, it walks up the hierarchy in three steps.

Root doesn't know the answer. Returns a referral pointing to the .com TLD nameservers.

.com TLD knows who holds the example.com zone, not the record itself. Returns another referral with the authoritative NS.

Authoritative NS owns the zone file. Gives the definitive A record — IP address + TTL. No more referrals.

Resolver caches the result for 3600s and returns 93.184.216.34 back up the local chain to the browser.

💡 ⚠ Cache note — this diagram shows a full cold lookup. In practice, any node in the chain may have a cached answer. If the recursive resolver already has example.com cached, none of these 3 round trips happen. If it has the .com TLD address cached, round trip 1 is skipped. The walk only goes as deep as the cache misses.

With an IP address in hand, the browser can now open a connection.

How the TCP Handshake Works

SYN (Synchronise) — client picks a random sequence number and asks the server to open a connection. No data yet.

SYN-ACK (Synchronise + Acknowledge) — server acknowledges the client's SYN and sends its own sequence number. Both sides are now synchronized.

ACK (Acknowledge) — client confirms the server's SYN-ACK. The connection is open. The very next packet from the client can carry real data — the TLS ClientHello.

With the connection open, the browser now needs to secure it.

How the TLS Handshake Works

ClientHello — browser advertises what it supports and sends a key share upfront. SNI tells the server which hostname it wants, so the server can pick the right certificate.

ServerHello — server picks a cipher suite and sends its own key share. At this point both sides can independently derive the same shared secret — it is never transmitted over the wire.

Certificate + CertVerify + Finished — server proves its identity with an X.509 cert signed by a trusted CA, proves it holds the private key, and signals the handshake is complete. All three sent in one flight.

Client Finished — client verifies the cert chain, confirms the handshake MAC, and the encrypted channel opens. The very next message is the HTTP GET request.

Key headers explained

Host — required in HTTP/1.1+. Tells the server which virtual host to serve, since many domains can live on the same IP.

Accept-Encoding: gzip, br — browser signals it can decompress. Server compresses the response, cutting transfer size by 60–80%.

Cache-Control: max-age=3600 — browser caches this response for 1 hour. Next visit within that window skips the request entirely.

Content-Length — tells the browser exactly how many bytes to expect. Once that count is reached, the browser knows the response is complete and starts parsing.

How Browser Rendering Works

Once the HTML arrives, the browser's job is just beginning.

The Whole Chain

From the outside, typing a URL feels like flipping a light switch. From the inside, it's six layers of negotiation happening in under a second — a name resolved, a connection opened, a channel secured, a document fetched, a page rendered.

Every slow page, every failed request, every "connection timed out" error is just one of those six layers not going as planned.

Now you know which one to look at.