Follow one web request from the address bar to the finished page: URL parsing, DNS, the connection, TLS, the HTTP request and response, and how the browser turns it into what you see.
Almost every web problem you will meet in a job is a problem at one step of a single journey: a name that does not resolve, a connection that is refused, a certificate that is rejected, a server that returns an error. If you can narrate the whole journey from start to finish, you can say which step is failing before you open any tool. This chapter is the map. Three other guides here go deep on individual stops.
The seven steps between pressing Enter and seeing a page, what each step does, which guide covers it in depth, and how to watch the steps happen on your own computer.
A URL has parts. In https://example.com/guides/intro, https is the protocol, example.com is the host (which server to talk to), and /guides/intro is the path (which item to ask for). Before anything goes over the network, the browser checks its caches in case it already has this page, or already knows the server's address.
Computers connect using numeric addresses, not names. The browser asks the operating system to look up the host, and if nobody nearby knows, the question climbs through a chain of DNS servers until one gives an answer. The full story is in How DNS Resolution Actually Works. When this step fails, you see messages like "server not found", and the problem is the name, not the website.
With an address in hand, the browser opens a connection to the server, usually on port 443 for a secure site. Most connections use TCP, which begins with a short exchange to confirm both sides are ready. Newer connections can use HTTP/3, which runs over a protocol called QUIC and can save some of those round trips. When this step fails, the usual messages are "connection refused" or "timed out": the address exists, but nothing is answering there.
For an https address, the two sides now agree on how to encrypt everything that follows, and the server proves who it is with a certificate. This is the TLS handshake, explained step by step in TLS/SSL Handshake, Step by Step. A certificate that has expired or does not match the name stops the journey here, with a security warning.
Only now does the browser ask for the page. An HTTP request is a few lines of text: the method (usually GET), the path, and headers that describe the browser, the language it prefers and any cookies for this site. The server's software reads the request, may run application code or query a database, and builds the answer.
The server replies with a status code, headers and a body. The status code is the quickest way to tell what happened: 200 means success, 301 and 302 mean "look somewhere else", 404 means not found, and 500 means the server itself failed. HTTP Status Codes in Production shows how to read them when you are on the other side, running the server.
The body is usually HTML. The browser reads it and builds a model of the page. While reading, it finds more things it needs, such as stylesheets, scripts and images, and requests each one. Those requests repeat steps 2 to 6, though the connection to a server it has already used can usually be reused. Finally, the browser lays out the page and paints it on the screen. A "single" page load is often dozens of requests.
You never think about any of this when you type an address. Each layer (names, connections, encryption, requests, rendering) hides the one below it behind a simple interface. That is the idea at the centre of What Computer Science Actually Is, and this journey is one of the clearest places to see it.
On Windows, open PowerShell and run these one at a time, with any site you own or may test:
Resolve-DnsName example.com shows step 2, the name turning into an address.curl.exe -v https://example.com shows steps 3 to 6 in the output: the connection, the TLS handshake lines, the request headers it sent and the status line it got back.Then answer: which step was slowest, and how many requests did one page load make?
Pick the step that surprised you most and read its guide: How DNS Resolution Actually Works or TLS/SSL Handshake, Step by Step. When you can name which step is failing, HTTP Status Codes in Production is where to go next.
What actually happens between typing a hostname and getting an IP address back — the lookup chain, caching layers, and why DNS is so often the first suspect in an outage.
What actually happens during a TLS handshake, why certificate expiry breaks everything at once, and how to read the handshake yourself with openssl and a browser.
The HTTP status codes that actually show up in day-to-day support and operations work, what each one really means, and which ones point at the client vs. the server.