What Happens When You Open https://example.com

DNS, ARP, TCP, TLS and HTTP, in the order they happen, each at its own layer.

Opening an HTTPS page runs through the whole stack in a fixed order: find the gateway's hardware address, resolve the name, open a TCP connection, agree keys with TLS, send the HTTP request and read the response. Each step works at one layer and needs the step before it, which is why a failure at one step stops everything after it.

Follow a laptop on a home network that has just joined Wi-Fi, so nothing is cached, opening https://example.com.

One HTTPS request from a laptop, across the stack

The request, layer by layer

Find the gateway, layer 2

The resolver and the server are on other networks, so every packet goes to the default gateway first. The laptop knows the gateway's IP address from DHCP but needs its MAC address to build a frame, so it asks with ARP and caches the answer.

Resolve the name, the application layer

The laptop asks its configured resolver for example.com, usually in one UDP datagram on port 53. The resolver, which may itself ask root, top-level and authoritative servers, returns an address.

Open a connection, layer 4

The laptop sends a SYN to port 443 at that address, through the router, which rewrites the source with NAT and forwards it across the routers between. The three-way handshake completes in one round trip.

Secure it, TLS

With TLS 1.3, the ClientHello and the server's reply agree keys in one round trip. The laptop checks that the certificate chains to a trusted root and names example.com.

Ask, layer 7

The browser sends GET / with a Host header, encrypted, and reads the response, then the stylesheets, scripts and images it names, reusing the same connection.

Two things are worth noticing.

Every step depends on the one before. Without the gateway's MAC address no packet leaves the laptop; without an address there is nothing to connect to; without a connection there is nothing to encrypt. A failure therefore always shows as the first step that did not complete, and everything after it never happens.

Caches skip steps. On the second visit, the ARP entry, the DNS answer and often an open connection are all still there, so the browser sends the request at once. That is why a page that is slow the first time and fast after points at setup, not at the server.

So a request is a short chain of protocols, one per layer, and debugging is finding the first link that broke.

← → move through sections and cards