How the Internet Works: The Full Journey

You type google.com into your browser’s address bar and press Enter.

In the next 200 milliseconds or so, your browser silently performs hundreds of individually remarkable operations. It consults a distributed database spread across thousands of servers worldwide to translate a human-readable name into a machine-readable address. It opens a connection using a protocol engineered to survive packet loss on unreliable networks. It negotiates an encrypted channel using mathematics that would take a classical computer longer than the age of the universe to crack without the right key. It speaks a protocol that was redesigned from scratch in 2015 because the original had a fundamental architectural bottleneck. It receives a stream of raw bytes, builds two separate in-memory tree structures, merges them into a third, calculates the exact pixel coordinates of every visible element on the page, and hands the final rendering instructions to your GPU.

Then it shows you a search box.

Most developers work with the results of all of this — the DOM, fetch(), CSS properties, network requests in DevTools — without ever looking at the machinery underneath. This series is about that machinery.

What This Series Is

The browser engineer’s view of the stack. Every concept here is chosen because it shows up in real work — in DevTools, in network logs, in performance profiles, in debugging sessions. We don’t cover OSI layers for their own sake. We don’t care about physical transmission media or switching theory. We care about the version of the stack that matters when you’re building or debugging a web application.

One example, traced end to end. Every post in this series uses the same running example: a single request to google.com. The same journey, examined from a different vantage point in each post. By the time you finish the series, you will have seen that one trip in complete detail.

The Full Journey

Before looking at any individual block, here is the complete picture — every hop the packet makes from your laptop to Google’s server and back.

That visual tells you almost everything at a glance. Your browser generates the request. Your OS sends it over WiFi to your router. Your router performs NAT — replacing your private 192.168.x.x address with your public IP — and forwards it through your ISP. Your ISP connects to the internet backbone. Within milliseconds, the request reaches a Google edge server, gets forwarded to the backend, and the response makes the same trip back in reverse.

Each arrow in that diagram is a story. This series tells all of them.

The 8 Blocks

The journey is divided into 8 blocks. Each is a logical stage of the trip, covered in one or more dedicated posts. They’re sequenced so that each block builds naturally on the previous one — TCP makes more sense once you know what DNS found, TLS makes more sense once you understand what TCP established — but most posts are self-contained enough to read standalone if you already know the surrounding context.

1. Block 1 — The Browser's First Move (1 post)

   Before a single byte leaves your device, the browser runs a quiet decision sequence. Is this domain on the HSTS preload list — meaning every connection must be HTTPS, enforced by the browser itself before any network call? Is there a valid DNS result already cached from a previous visit? Is the full HTTP response sitting in memory or on disk? Has a Service Worker registered to handle this navigation before the network is even consulted?

   Most developers only discover this layer when caching causes hard-to-debug behaviour. This post makes it explicit.

2. Block 2 — DNS: The Internet's Phone Book (2 posts)

   Your browser knows google.com. Your router doesn’t speak names — it only routes IP addresses. DNS is the distributed translation system between the two.

   Two posts cover it. The first traces the full recursive resolution journey: your browser asks a resolver, the resolver asks a root server, which points to the TLD server, which points to Google’s authoritative server, which finally returns 142.250.80.46. Every cache check, every TTL, every hop. The second post goes deeper: every DNS record type that matters (A, AAAA, CNAME, MX, TXT, NS), how to use dig to inspect resolution in real time, glue records, and how modern DNS has added encryption via DoH and DoT.

3. Block 3 — The Physical Journey: WiFi → Router → ISP (1 post)

   IP address in hand, a packet needs to physically travel across the planet. This post covers the whole chain: how 802.11 WiFi works at the radio level, what your home router actually does (DHCP, NAT, and why 192.168.x.x is a private address that never appears on the public internet), how your ISP connects you to the backbone, what an Internet Exchange Point (IXP) is and why it matters for latency, and how BGP — the routing protocol that makes the internet one coherent network — decides where the packet goes next.

4. Block 4 — TCP: The Reliable Pipe (1 post)

   IP delivers packets. It offers no guarantee they arrive, no guarantee they arrive in order, and no guarantee they arrive at all. TCP is the layer that adds those guarantees — and it pays for them with a connection setup cost.

   Before a single HTTP byte flows, TCP runs a 3-way handshake: SYN, SYN-ACK, ACK. That exchange costs one full round trip. Once connected, TCP tracks sequence numbers, sends acknowledgements, retransmits dropped packets, and adjusts the transmission rate to avoid overwhelming the receiver or the network. This post explains exactly how — and why that round-trip cost matters so much for web performance.

5. Block 5 — TLS: Locking the Door (3 posts)

   Three posts for the security layer, because it has three genuinely distinct stories worth understanding separately.

   The first covers the certificate system: what an X.509 certificate actually contains, who the Certificate Authorities are, how your browser builds a chain of trust from an unknown server certificate up to a root CA baked into your OS. The second covers Let’s Encrypt: the non-profit that automated certificate issuance using the ACME protocol, dropping the cost of HTTPS from hundreds of dollars to zero and driving adoption from ~30% to over 90% of the web. The third covers the TLS 1.3 handshake itself: the cryptographic exchange that happens in one round trip, establishing shared encryption keys between two parties who have never met before.

6. Block 6 — HTTP: The Language of the Web (3 posts)

   HTTP is the protocol browsers and servers use to communicate — the actual application-layer conversation. Three posts cover its evolution across 30 years.

   The first dissects HTTP anatomy: the structure of requests and responses, what every method and status code means, how HTTP/1.1’s persistent connections work, and why head-of-line blocking meant browsers opened 6 parallel connections per domain as a workaround. The second covers HTTP/2: the 2015 redesign that introduced binary framing, stream multiplexing (many concurrent requests over one TCP connection), and HPACK header compression. The third covers HTTP/3 and QUIC: why Google moved HTTP from TCP to UDP, what connection migration means, and how 0-RTT makes reconnections faster.

7. Block 7 — The Response Arrives (2 posts)

   The server has responded. Bytes are arriving. Two posts cover what happens in this window.

   The first covers the response itself: how streaming works and why the browser begins parsing HTML before the full file has downloaded, how Content-Type, Content-Encoding, and chunked transfer work, and why Brotli compresses better than gzip. The second is a deep dive into HTTP caching: the full model behind Cache-Control, ETag, Last-Modified, and Vary, how conditional requests and 304 Not Modified save bandwidth, and how Service Workers give you a programmable cache layer that runs before any network call.

8. Block 8 — How Browsers Work: Architecture to Pixels (5 posts)

   The richest block — five posts covering the browser’s internals from process architecture down to the last pixel.

   Browser architecture covers Chrome’s multi-process model: why each tab runs in its own sandboxed renderer process, what the browser process, GPU process, and network process are responsible for, and why this design makes tab crashes survivable. The navigation pipeline traces what happens between pressing Enter and receiving the first byte of HTML — the UI thread, the network thread, Safe Browsing checks, MIME detection, and the renderer process being prepared in parallel. DOM and CSSOM covers how HTML bytes become a DOM tree (incrementally, via streaming) and how CSS bytes become a CSSOM (necessarily render-blocking), plus how async, defer, and type="module" change script behaviour. Layout and paint covers how the render tree is built, how the browser calculates geometry for every visible element, what triggers a reflow vs a repaint, and how the display list is constructed. Compositing and GPU covers layer promotion, the compositor thread, rasterization, GPU acceleration, and why transform animations are cheap while width animations are not — finishing with Core Web Vitals mapped back to the pipeline stages.

The Complete Map — All 18 Posts

Posts are published weekly and linked here as they go live.

Block 1 — Browser’s First Move

Block 2 — DNS: The Internet’s Phone Book

Block 3 — The Physical Journey

Block 4 — TCP

Block 5 — TLS / HTTPS

Block 6 — HTTP

Block 7 — The Response Arrives

Block 8 — How Browsers Work: Architecture to Pixels

How to Read This Series

In order, start to finish — the sequencing is deliberate. Block 4 (TCP) makes Block 5 (TLS) significantly clearer. Block 5 makes Block 6 (HTTP) clearer. If you’re new to this material, the linear path is the fastest one.

Jump to a specific block — each post opens with enough context to stand on its own. The diagrams use a consistent colour scheme throughout the series (indigo for DNS, blue for TCP, green for TLS, amber for HTTP, violet for browser/DOM), so visuals from earlier posts will feel familiar even if you skipped them.

Use it as a reference — every sequence diagram, packet anatomy breakdown, and decision flow in this series is built to be bookmarked and returned to. The TLS handshake post, the caching decision flow, the rendering pipeline — these are the kind of things worth revisiting when you hit something confusing in production.

Posts are published weekly. This table will be updated with links as each one goes live.