Putting it together - what happens when you type a URL

Introduction

This is the last part of the series. There are no new concepts. Instead, we follow how the previous five parts mesh together, from the moment you type http://www.example.com into the address bar and press Enter to the moment the page appears. All of this usually finishes within a second.

Parsing the URL

The browser first decomposes the URL. The protocol is http, the host is www.example.com, the path is /. To start communicating it needs the host’s IP address.

DNS lookup: from name to address (part 5)

The browser checks its own and the operating system’s DNS caches first, and if there is no hit it asks a recursive resolver. The resolver follows root → com → the example.com nameserver in turn and comes back with 93.184.216.34.

One thing worth noting here: the DNS question itself is a packet going out over the network. A UDP datagram (part 4) is encapsulated (part 1) in an IP packet (part 3) and then in an Ethernet frame (part 2) to make the round trip to the resolver. Every layer in the series has already been called on once at this stage.

TCP connection setup: the three-way handshake (part 4)

With the IP address in hand, the browser asks the operating system for a socket and sends a SYN toward 93.184.216.34:80. Three exchanges — SYN → SYN+ACK → ACK — align both sides’ sequence numbers, and a reliable channel opens.

The packet’s journey: through the gateway, hop after hop (parts 2 and 3)

Whether it is the SYN or a later HTTP request, every packet takes the same journey.

The host determines that the destination 93.184.216.34 is outside its own subnet, so it decides to hand the packet to the default gateway (the router). It looks up the gateway’s MAC address in the ARP cache, asking by broadcast if it is missing (part 2). The router translates the private address to a public one via NAT (part 3), and the packet heads out to the ISP’s routers.

From there the packet passes through routers, guided to the next step at every hop. Each router picks the most specific matching entry in its routing table and hands the packet onward; nobody knows the whole path (part 3). Along the way the destination IP address is preserved to the end, while the frame is stripped and rebuilt at every hop so the MAC addresses keep changing (part 2).

HTTP request and response (part 5)

Once the channel is open, the browser sends its request.

GET / HTTP/1.1
Host: www.example.com

The web server process waiting on port 80 receives and handles it, and responds with 200 OK and some HTML. A large response arrives split into several segments; if some are lost, TCP fills the gaps by retransmitting and restores the order (part 4), so the browser is handed one uninterrupted document.

Rendering, and repeating

The browser parses the HTML it received and paints the screen. When it finds images, CSS, and scripts inside the document, it repeats this whole process (from checking the DNS cache to the HTTP request) for each one. Dozens of requests for a single page is entirely normal. Connections that are done go through a teardown and are cleaned up.

The whole flow, mapped to layers

Closing the series

The core question of this series is the one from part one: how do you divide up an enormous communication problem? The answer was layering. The link layer handles one hop, IP handles the way to the host, TCP handles reliability to the process, and the application layer handles content. Each layer meets the others only at an agreed boundary, knowing nothing of their internals — and it is that ignorance that let a design nearly fifty years old scale to the internet we have today.

The same division applies when diagnosing problems in practice. When the internet is down you check as far as the IP layer with ping, then check separately whether DNS resolves, then check the HTTP response — narrowing the layers one at a time. Working out which layer is responsible is half of network debugging.

The internet was not built out of perfect components, but out of components with clear boundaries of responsibility.