0% completed
What Happens When You Type a URL into the Browser
On This Page
The whole path
The second pass, which is the bigger one
Where the time actually goes
You type an address, press enter, and a page appears. It usually takes less than a second, and in that second the request crosses a dozen separate systems.
This lesson walks the whole path once, in order. Everything in it has appeared somewhere in this course already. What is new is seeing the pieces in the sequence they actually run in.
It is also one of the most common opening questions in an interview, because an interviewer can start it in a minute and follow it as deep as they like.
The whole path
Here is each step.
1. The browser reads the URL. It splits the address into its parts: the scheme that says which protocol to use, the host that names the server, and the path that identifies what is wanted. Those parts are covered in URL vs. URI vs. URN.
2. The name is turned into an address. A host name is not something a network can route to, so it has to become an IP address. The browser checks its own cache first, then the operating system's, and only then asks a resolver, which walks the naming hierarchy on its behalf. That walk is the subject of DNS Resolution Process. Most of the time this step is free, because the answer is already cached somewhere close.
3. A connection is opened. The browser opens a TCP connection to that address. TCP begins with a three-way handshake: the client sends a request to start (SYN), the server agrees and asks the same in return (SYN-ACK), and the client confirms (ACK). Only then can data be sent. That is one full round trip spent before a single byte of the request has moved.
4. If the scheme is HTTPS, the connection is secured. The two sides run a TLS handshake: the server presents its certificate, the browser checks it against an authority it trusts, and the two agree on the keys that will encrypt everything from here on. This is what the padlock means, and it is covered in HTTP vs. HTTPS. It costs another round trip, sometimes two.
5. The request is sent. A single line naming the method and the path, followed by headers such as the host and the cookies belonging to it.
6. What answers is often not the origin. For anything popular, the address from step 2 belongs to a content delivery network, and the request lands on an edge server near the user. If that server has the content, it replies immediately and the rest of the path never runs. See What is CDN.
7. On a miss, the request continues to the origin. There a load balancer chooses one healthy server from a pool of identical ones, and the request may pass an API gateway that handles authentication and rate limiting before any service sees it.
8. The server builds the response. Usually that means checking a cache, and going to the database only when the cache does not have the answer.
9. The response travels back along the same path, and the CDN keeps a copy on the way through so the next user nearby is served from the edge.
10. The browser renders what arrived, and immediately discovers it needs more.
The second pass, which is the bigger one
The first response is only the HTML. Reading it reveals references to stylesheets, scripts, fonts and images, and each of those is another request.
This is where two things from earlier in the chapter start to matter.
The connection is reused. HTTP/1.1 keeps the TCP connection open, so steps 3 and 4 do not repeat for every file. Paying for a handshake per image would be ruinous.
The requests overlap. HTTP/2 sends many of them at once over that single connection instead of queueing them, which is what multiplexing means in HTTP/1.0 vs 1.1 vs 2.0 vs 3.0.
A page of forty resources is forty trips through steps 5 to 9. The first request is the one that pays for everything else.
Where the time actually goes
Count the round trips before the first byte of the page comes back, for a fresh connection over HTTPS.
| Step | Round trips |
|---|---|
| DNS lookup | 0 if cached, 1 or more if not |
| TCP handshake | 1 |
| TLS handshake | 1 to 2 |
| The request and its response | 1 |
Three or four round trips, before the server has done any work at all.
Now put a number on a round trip. Inside one data center it is under a millisecond, so the total is invisible. Across the world it is around 150 milliseconds, so those same three or four round trips are half a second of waiting on a server that has not started yet.
That single comparison explains most of what this course has covered about the network. DNS answers are cached so step 2 disappears. Connections are kept open so steps 3 and 4 do not repeat. Content is served from an edge near the user so every remaining round trip is short. Each of those exists to remove a round trip or to shorten one.
💡 Interviewers use this question to see whether you can hold a whole system in your head, not to test trivia. Walk it in order, and say what you are skipping: "DNS resolves the name, and I will assume a cache hit here." Naming a step and setting it aside is a stronger answer than getting lost in the details of one of them.
Key takeaway: The browser splits the URL into scheme, host and path, resolves the host name to an IP address through DNS, opens a TCP connection with a three-way handshake, and secures it with a TLS handshake if the scheme is HTTPS. The request usually reaches a CDN edge server first, and only on a miss does it continue to the origin, where a load balancer picks a server that checks a cache before the database. The HTML that comes back triggers a request for every resource it references, over the same connection. Three or four round trips are spent before the first byte, which is why caching DNS answers, reusing connections and serving from a nearby edge all matter so much.
That closes the chapter. Next is a Flashcards Review to lock in the terms, then a Chapter Assessment.
On This Page
The whole path
The second pass, which is the bigger one
Where the time actually goes