The internet is a network of networks
The internet is not a single machine or a single company. It is a very large collection of separate networks, run by internet service providers, universities, businesses, governments and cloud companies, that agree to exchange data using shared rules. Those shared rules are called protocols. Because everyone follows the same ones, a laptop on a home network can talk to a server in a different country that it has never contacted before.
The web is only one service that runs on top of the internet. Email, video calls, online games and app updates use the same underlying network but different protocols. This article follows a single web page request from start to finish.
Step 1: You type an address or click a link
Say you click a link to a page at example.com (a reserved example name). Your browser first reads the address and splits it into parts: the protocol (usually HTTPS), the site name, and the path to a specific page.
The browser also checks whether it already has what it needs. It may hold a saved copy of the page’s images or an earlier lookup of the site name, which can skip some of the steps below.
Step 2: The name is turned into an address
Computers on the internet locate each other with numbers, not names. A name like example.com is easy for people to remember, but the network needs a numeric address. The lookup system that translates one into the other is the domain name system, often compared to a phone book, although it is really a distributed set of servers rather than one list.
Your device asks a resolver, typically run by your internet provider or a public service you have chosen, and the resolver finds the answer by asking other servers in turn. The result is an address belonging to the server that hosts the site. Many sites have several addresses, and the answer can differ depending on where you are.
Step 3: Your request is broken into packets
Data on the internet does not travel as one continuous stream. It is split into small chunks called packets. Each packet carries a header with the sender’s and receiver’s addresses, similar to the outside of an envelope. These numeric labels are IP addresses, and they let each piece be routed independently.
Splitting data this way lets many conversations share the same cables. It also means that if a packet is lost, only that piece needs to be sent again. A companion protocol called TCP numbers the packets, confirms their arrival and puts them back in order at the other end. Some newer systems use a related transport called QUIC for similar jobs.
Step 4: Packets cross several networks
Your packets first travel through your home equipment. A router connects your devices to your provider, and whether your device uses Wi-Fi or an Ethernet cable, the packets reach the router the same way. From there they pass to your provider’s network.
Routers along the path read each packet’s destination address and decide which direction to forward it next. No router knows the whole route in advance. Each one just makes a local choice using tables that are constantly updated, and providers exchange routing information with each other so that these tables stay reasonably current. The path can pass through a handful to a few dozen routers, and different packets in the same exchange can take different routes.
Much of the long-distance traffic runs on fiber-optic cables, including cables laid across oceans, which carry light signals. The time this takes depends partly on distance and partly on congestion, which is part of why network latency varies from one connection to another.
Step 5: A secure connection is set up
Before any page content is sent, a modern site usually sets up an encrypted connection. The browser and server agree on how to scramble the data, and the server presents a digital certificate to show which site it is. If everything checks out, the browser shows its padlock-style indicator. This is what HTTPS encryption provides: privacy from people on the path, not a guarantee that the site itself is trustworthy.
Step 6: The server answers
Over that connection, your browser sends a request, typically asking for a particular page. The server might be a single machine or one of many in a large cloud infrastructure, with a load balancer choosing which machine answers. It may read a file from storage or build the page on the fly by querying a database. It replies with a status code (200 means success, 404 means the page was not found) and the page’s content.
For popular sites, the reply often does not come from the original server at all. Content delivery networks keep copies of pages, images and videos on servers spread around the world, so the answer can travel a shorter distance. Related ideas such as edge computing move some of the processing closer to users too.
Step 7: The browser builds the page
The first response is usually a text file of HTML, which describes the page’s structure. While reading it, the browser discovers other files it needs, such as stylesheets, scripts, fonts and images, and requests each one, often in parallel. Each request repeats parts of the process above, though connections to the same server are normally reused.
When enough has arrived, web browsers combine the files, work out the layout and draw the result on screen. The page may keep loading in the background after you can already read it. Small files called browser cookies may also be stored and sent back on later requests so that a site can recognize you between visits.
Why it usually feels instant
Several things combine to make this fast. Name lookups are saved temporarily, connections are reused, copies of content sit close to users, and browsers fetch many files at once. Even so, each step takes some time, and a slow step anywhere along the way can delay the whole page.
What can go wrong
Problems tend to fall into a few categories:
- Lookup problems: the name cannot be resolved, so the browser reports that the site cannot be found.
- Connection problems: your network is down, congested, or the route to the server is broken.
- Server problems: the server is overloaded or returns an error.
- Security problems: the certificate is expired or does not match the site, and the browser warns you.
Knowing which stage failed makes error messages easier to interpret. A “site can’t be reached” message points to a different stage than a “404 not found” page, for instance, and a slow page on public Wi-Fi may simply reflect a crowded local connection rather than a problem with the site.