What happens when you open a website

You type www.example.com, press Enter, and a page appears in well under a second. In that moment, your laptop, a router in your home, machines at your internet provider, a chain of DNS servers, several backbone routers and a server in a data center all cooperate — none of which you ever see.

This lecture follows that journey from start to finish. Every later lecture in this course zooms into one part of it, so treat what you learn here as the map.

The cast of characters

Before following the request, meet the machines involved. None of them knows the whole story; each does one small job and passes the work on.

Client: The program asking for something — here, your web browser.
Server: The program answering — here, a web server in a data center.
IP address: A numeric address such as 203.0.113.10 that identifies a device on a network. Packets are delivered by IP address.
DNS: The Domain Name System: the internet’s directory, which turns names like www.example.com into IP addresses.
Router: A device that forwards packets between networks, one hop closer to their destination each time.
Packet: A small chunk of data with addressing information attached. Large messages are split into many packets.
Protocol: An agreed set of rules for communicating — for example DNS, TCP, TLS and HTTP.

Follow the request

Scroll through the story below to follow a single page load. The model stays in view and changes with each step; you can drag to look around the scene at any point.

Scroll storyA request’s journey across the internetStep 1 of 6

Loading 3D model…

1
1 · You press Enter
The browser reads the address: the scheme (https), the host name (www.example.com) and the path (/). It cannot send anything yet — it only has a name, and packets need an IP address.
2
2 · Ask DNS for the address
Your laptop asks a DNS resolver, usually run by your ISP or a public service. If the answer is not cached, the resolver asks a root server, then the .com servers, then example.com’s own servers — and returns 203.0.113.10.
3
3 · Leave your home network
Packets travel over Wi-Fi to your home router. Your laptop’s private address (192.168.1.23) is not valid on the internet, so the router swaps in its public address. This is Network Address Translation (NAT).
4
4 · Cross the internet, hop by hop
Your ISP hands the packets to backbone routers. Each router reads only the destination address and forwards the packet one hop closer. No router knows the full path — each simply knows the best next step.
5
5 · Shake hands: TCP, then TLS
Before any web data flows, TCP sets up a reliable connection with SYN, SYN-ACK and ACK. Then TLS negotiates encryption: the server proves its identity with a certificate and both sides agree on keys.
6
6 · Request and response
The browser sends an HTTP request — GET / — and the server replies with 200 OK and the HTML. The browser then discovers the CSS, JavaScript and images it needs and requests those too, often in parallel.

1. Naming things: DNS

Humans remember names; networks route numbers. The Domain Name System bridges the two. Your operating system first checks its own cache. If the answer is not there, it asks a recursive resolver — typically run by your internet provider, or a public service your company has configured.

The resolver does the legwork. It asks one of the root servers where to find .com names, asks a .com server where to find example.com, and finally asks example.com’s authoritative server for the address of www.example.com. Each answer comes with a time to live (TTL), so the resolver can reuse it for minutes or hours without asking again. That is why the full lookup chain is rare in practice.

AnimationA DNS lookup, start to finish

Loading animation…

Check the local cachesThe browser and the operating system look for a saved answer first. Nothing is cached yet, so the laptop has to ask.
Ask the resolverThe laptop sends one question — the address of www.example.com — to its configured resolver, and waits.
Root server: “ask the .com servers”The resolver does not know the answer either. A root server does not know it, but it refers the resolver to the servers responsible for .com.
TLD server: “ask example.com’s servers”The .com servers know which name servers are responsible for example.com, and refer the resolver there.
The authoritative answerexample.com’s own DNS server answers with the address: 203.0.113.10. The resolver caches it.
Reply and cacheThe resolver returns the address with a time to live of 3,600 seconds. For the next hour, this name resolves instantly from a cache.

2. Leaving home: your router and NAT

Your laptop sends its packets to the default gateway — your home or office router. Inside the building, devices use private addresses such as 192.168.1.23, which can be reused by millions of networks and are never routed on the public internet.

The router rewrites each outgoing packet so it appears to come from the router’s single public address, and keeps a table so it can hand the replies back to the right device. This is Network Address Translation, and it is one reason a whole office can share one public IP address.

3. Across the internet: routing

The internet is not one network; it is tens of thousands of independently run networks that agree to carry each other’s traffic. Your ISP passes packets to larger backbone networks, which pass them toward the network that hosts the server.

Every router along the way does the same simple thing: it looks at the destination IP address, checks its routing table, and forwards the packet out of the most suitable link. A typical request crosses somewhere between a handful and a couple of dozen routers. You will see exactly how those tables work in lecture 4.

4. Handshakes: TCP and TLS

Packets can be lost, duplicated or arrive out of order. TCP hides that from applications. Its three-way handshake — SYN, SYN-ACK, ACK — establishes a connection and synchronizes the sequence numbers both sides will use to put data back in order and detect anything missing.

Because the address starts with https, the browser then runs a TLS handshake. The server presents a certificate proving it really is www.example.com, and both sides agree on encryption keys. From here on, anyone watching the network sees only scrambled bytes.

5. Request and response: HTTP

Finally, the browser sends an HTTP request — a short, structured message saying GET me the page at /, plus headers describing the browser and what it accepts. The server replies with a status code (200 OK), headers and the HTML.

As the browser reads the HTML, it discovers stylesheets, scripts and images and requests those as well. A typical modern page needs dozens of requests; the Modern Web Development course follows what the browser does with them.

Why it usually takes a fraction of a second

With so many steps, it is remarkable that pages load quickly. A few techniques do most of the work:

Caching everywhere. DNS answers, images and scripts are stored and reused by your laptop, your browser and the resolver.
Content delivery networks (CDNs). Copies of popular content are placed in data centers close to users, so the journey is shorter.
Connection reuse. Once a TCP and TLS connection is open, many requests can share it instead of repeating the handshakes.

Experiment with a simplified page load below. Every handshake costs whole round trips, so the distance to the server matters far more than you might expect.

InteractiveWhere a page load’s time goesChange the distance and the optimizations

Loading visual…

Set the round-trip time to 150 ms — a server on another continent — and switch the optimizations on one at a time. A nearby CDN helps most, because every round trip to it is short.

See it on your own machine

You can watch each stage with standard tools. Try these in a terminal (on Windows, use tracert instead of traceroute):

# 1. Resolve the name to an IP address (DNS)
dig +short www.example.com

# 2. List the routers your packets pass through
traceroute www.example.com

# 3. Watch the connection, the TLS handshake and the HTTP exchange
curl -v https://www.example.com/ -o /dev/null

In the next lecture we open up a single packet and see how each protocol in this journey adds its own layer of information around your data.

In this lecture you will