What Happens When You Press Enter

Everything in the Networking domain is a zoom into one of these rungs. Read them once as a story: the browser has a URL; the URL names a host; the host has to become an IP address; the IP address has to be reachable through a chain of routers; once reachable, the two machines need a transport that turns unreliable packets into a reliable stream; the stream has to be encrypted and authenticated; and only then can HTTP ask for / and get bytes back that the browser turns into pixels.

Each rung is a separate mechanism with a separate failure. "The site is down" is never one thing: it is DNS returning nothing, or a route that black-holes, or a SYN with no SYN-ACK, or a certificate that expired at midnight, or a 502 from a proxy whose upstream died. The rest of the domain exists so that you can tell those apart in under a minute.

Enter URL / parse URL. The browser splits https://engineer-atlas.dev into a scheme (https, which fixes the default port 443 and the requirement for TLS), a host (engineer-atlas.dev), and a path (/, since none was given). Before touching the network it checks its own caches: an HSTS list that may force HTTPS, a cached HTTP response that may still be fresh, an existing open connection to the same origin that can be reused. Failures here are silent and cheap: a typo becomes a search, a stale cache becomes an old page.

DNS lookup. The host name is not an address. The browser asks the OS resolver, which asks a recursive resolver (your ISP’s, or 1.1.1.1, or a corporate one), which walks root → .dev TLD → the authoritative server for engineer-atlas.dev and returns A (IPv4) and AAAA (IPv6) records with a TTL. Most of the time the answer comes from a cache in a fraction of a millisecond; a cold lookup across the hierarchy costs tens of milliseconds. It fails as NXDOMAIN (the name does not exist), SERVFAIL (the resolver could not get an answer), a timeout (UDP port 53 blocked, resolver down), or, most insidiously, a stale cached answer pointing at a server that moved yesterday. See DNS: Why Names Need a Distributed Database and DNS Failure Modes: What Each One Looks Like.

Choose destination IP. DNS may return several addresses of two families. The browser races them: try IPv6 first, and if no connection is established within ~250 ms start IPv4 in parallel (Happy Eyeballs, RFC 8305). Whichever connects first wins. A broken IPv6 path on your network is why some sites feel "slow to start" by exactly a quarter of a second.

Routing. Your machine does not know where engineer-atlas.dev’s server is. It knows one thing: whether the destination is on its own subnet (then deliver directly) or not (then hand the packet to the default gateway). The gateway does the same with a bigger table, and so on through your ISP, across an exchange point, into the hosting provider’s network. Every router independently looks up the destination prefix and forwards to a next hop — nobody holds the whole path. A packet across a continent crosses 10–20 routers in ~30–80 ms; across an ocean ~150 ms.

Routing fails by black-holing (a router has no route and drops silently, or a firewall drops without a reply), by loops (a misconfiguration that the TTL eventually catches), and by asymmetry (outbound and return paths differ, which is normal but confuses debugging). The symptom is almost always a timeout, never an error — see Why Can’t I Connect? and traceroute: Discovering the Path Hop by Hop.

Establish transport. IP delivers packets, not conversations: they can be lost, reordered, duplicated. TCP builds a reliable, ordered byte stream on top with a three-way handshake (SYN → SYN-ACK → ACK, one round trip), sequence numbers and retransmission. HTTP/3 instead uses QUIC over UDP, which folds the transport and TLS handshakes into one round trip. Failure: SYN sent, nothing returned → connection timed out (a firewall, a dead host, a wrong route). SYN sent, RST returned → connection refused (the host is up but nothing listens on 443).

TLS. The stream is plaintext and unauthenticated; anyone on the path (the coffee-shop access point, your ISP) could read or alter it. TLS 1.3 performs a key agreement in one round trip and the server presents a certificate chaining to a root your browser trusts; the browser checks the name on it matches engineer-atlas.dev. Failures are loud and specific: NET::ERR_CERT_DATE_INVALID (expired), ERR_CERT_COMMON_NAME_INVALID (wrong name), a handshake alert on a protocol mismatch. See Why TLS Exists and Certificates and the Chain of Trust.

HTTP request. Only now does the browser send GET / with Host, Accept, User-Agent, cookies and a few dozen other headers — a few hundred bytes after roughly 2–3 round trips of setup. On HTTP/2 this is one stream on a multiplexed connection; on HTTP/1.1 it is the one request the connection can carry at a time.

Server. The packet arrives at an address that is very likely not the application at all but a load balancer or reverse proxy, which terminates TLS, picks a healthy backend, and opens (or reuses) a second connection to it. The backend process is blocked in accept() or epoll_wait(); the kernel wakes it, it reads the request, runs your code, perhaps queries a database, and writes a response. Failures here have their own vocabulary: 502 (the proxy could not reach the backend), 503 (overloaded or in maintenance), 504 (the backend took too long), 500 (your code threw).

HTTP response and browser. 200 OK, headers, then the body, flowing back through the same connection and the same routers in reverse. The browser starts parsing HTML before the body has finished arriving, discovers stylesheets, scripts and images, and runs the ladder again for each — usually on the same connection, sometimes to new hosts (a CDN), which means new DNS, new TCP, new TLS. A page that "loads slowly" with an idle server is usually dozens of these round trips, not compute; see Where the Time Goes: The Request Timeline.