Anatomy of a Web Request

You press Enter on twitter.com

Your browser knows the name twitter.com. That is all. It does not have an address. It does not have a connection. It does not have any data.

Before the page can load, four things must happen, one after the other.

1. Find Twitter's address. 2. Open a connection to that address. 3. Lock the connection so nobody else can read it. 4. Ask for the page and wait for an answer.

That is the whole web in four steps. The next few pages walk through each one.

Step 1. Find the address

Computers do not understand names. They only talk to each other using numbers called IP addresses. They look like this: 104.244.42.193.

When you type twitter.com, your browser needs to find Twitter's number. So it asks a helper service called a DNS resolver. The resolver is run by your internet provider, or by a public service like 1.1.1.1 (run by Cloudflare) or 8.8.8.8 (run by Google).

The resolver does the lookup for you. If it does not already know the answer, it asks three different servers, one at a time.

First it asks a root nameserver. "Who handles dot-com names?" The root says, "Go ask the .com server."

Then it asks the .com server. "Who handles twitter.com?" The .com server says, "Twitter runs their own. Go ask them."

Finally it asks Twitter's own nameserver. "What is the IP for twitter.com?" That server replies with the number.

The resolver sends the IP back to your browser. The whole trip takes about 20 to 100 milliseconds. The answer is then saved for a few minutes or hours, so the next time you visit Twitter, your browser already knows where to go.

Step 2. Open a connection

Now your browser knows the server's address. But just knowing the address is not enough. Your browser needs a way to actually send messages back and forth without losing pieces. That is what a TCP connection gives you.

Opening one is like a quick three-step hello between two computers.

Your browser says, "Hi, I want to talk." The server replies, "Got it. I am ready." Your browser says, "Great, let us begin."

This is called a three-way handshake. It takes about 30 to 100 milliseconds, depending on how far away the server is. Once it is done, both sides have an open line to send and receive data on.

There is a newer protocol called HTTP/3 that skips the handshake to save time. That is one of the main reasons it was invented.

Step 3. Lock the connection

If the URL starts with https://, the next step is to lock the connection so nobody else on the network can read what you send.

Locking it works like this. The server shows your browser a digital ID card. The card is signed by a trusted authority. Your browser checks the signature to make sure the server is really Twitter, and not someone pretending to be Twitter.

Once your browser trusts the card, the two sides agree on a secret password. From this point on, everything sent between them is scrambled using that password. Only the two of them can unscramble it.

This is what makes HTTPS safe. Someone watching the network can see that you are talking to Twitter. They cannot see what you and Twitter are saying.

The locking step takes another 1 or 2 round trips. Newer versions of this protocol, like TLS 1.3, finish it faster by doing some steps in parallel.

Step 4. Ask for the page

Only now, after all that setup, does your browser actually ask for the page. The request is a small text message. It says what you want to do (GET), where the page lives (/), which site (twitter.com), and a few extra details like which browser you are using and the cookie that proves you are logged in.

The server reads the request and starts working. For something like a Twitter home feed, the work usually goes like this.

First the server checks your cookie to figure out who you are. Then it asks the database, "What tweets should this person see?" Then it builds a page out of that data.

Depending on the page, this takes anywhere from 10 milliseconds (if the answer was already cached) to a few seconds (if the page touches many different services).

The server sends back a response. The response has a status code that says what happened (200 OK if all went well, 404 Not Found if the page does not exist), some extra info, and the actual page content.

Step 5. Turn the page into pixels

Your browser now has the page data. But the page is just text. The browser still has to turn it into the buttons, images, and layout you see.

It reads through the page and finds all the extra pieces it needs. Stylesheets that describe how things look. Scripts that make buttons work. Images, fonts, videos. Each of those has to be fetched separately.

Every one of those fetches is its own little version of the same four steps you just learned. Find the address. Open a connection. Lock it. Ask for the file. Browsers are smart about reusing connections to save time, and many of these files come from servers placed close to you, but it still adds up.

That is why one "page load" can involve dozens or even hundreds of separate requests. And it is why every millisecond of delay matters when you are trying to make websites feel fast.

Putting it all together

Every page you ever load goes through these same steps.

DNS turns the name into an address. TCP opens a connection. TLS locks the connection. HTTP is the actual question and answer. The browser turns the answer into something you can see.

Caches, CDNs, load balancers, databases. You will hear all these words a lot. Every one of them is just a piece of this picture, trying to make one of these steps faster or more reliable.

You now know the basic shape of the web. The rest of the lessons fill in the details, one concept at a time.