What Happens When You Type a URL, Step by Step

Loading the interactive diagram…

What Happens When You Type a URL, Step by Step

What happens when you type a URL into your browser: DNS finds the server, TCP and TLS connect securely, a CDN serves the page.

Your computer

Browser: Client · Documented. Where you type the address and where the page appears.
Operating system: Service · Documented. Your computer's own DNS helper: the hosts file, a small cache, and who to ask next.

DNS: finding the address

DNS resolver: Service · Documented. Does the searching: asks other DNS servers in turn until it has the answer.
Root name servers: External · Documented. The top of DNS: they know which servers handle each ending, like .com or .in.
.com name servers: External · Documented. Know which name servers are in charge of each .com domain.
Site's name servers: External · Documented. Hold the site's own DNS records, including the IP address to connect to.

The website

CDN edge server: Gateway · Hypothetical. A server near you that answers first and keeps copies of the site's files.
Load balancer: Gateway · Hypothetical. Spreads requests across the site's app servers.
App server: Service · Hypothetical. Runs the site's code and builds the page from a template and data.
Database: Database · Hypothetical. Stores the site's data, such as posts, products or accounts.

Flow: Type a URL and press Enter

The whole trip on a first visit, when nothing is cached yet: find the server's address, connect securely, ask for the page, and get it back.

Browser → Operating system (IP for example.com?). You type example.com and press Enter. The browser treats it as https://example.com/, finds no address for it in its own cache, and asks the operating system.
Operating system → DNS resolver (IP for example.com?). The operating system checks the hosts file and its own cache. Nothing there, so it asks the DNS resolver your network uses: often your internet provider's, or a public one.
DNS resolver → Root name servers (Where is .com?). The resolver hasn't seen this name recently either, so it starts at the top of DNS and asks a root name server.
Root name servers → DNS resolver (Ask the .com servers). The root server doesn't know example.com, but it knows which servers handle every name ending in .com, and sends back their addresses.
DNS resolver → .com name servers (Where is example.com?). The resolver asks one of the .com name servers.
.com name servers → DNS resolver (Ask the site's servers). The .com server knows which name servers the site's owner registered, and points the resolver to them.
DNS resolver → Site's name servers (IP for example.com?). Finally the resolver asks the site's own name servers, which hold the actual record.
Site's name servers → DNS resolver (203.0.113.10). They answer with the IP address and how long it may be cached, say 5 minutes. (203.0.113.10 is an address set aside for examples.)
DNS resolver → Operating system (203.0.113.10). The resolver keeps the answer, so the next person who asks gets it straight away, and passes it back.
Operating system → Browser (203.0.113.10). Your computer and browser cache it too. This lookup needed four DNS servers; for the next few minutes it needs none.
Browser → CDN edge server (Hello (TCP + TLS)). The browser connects to that address, which belongs to a CDN server near you. TCP opens the connection, then TLS starts setting up encryption. 'Secure connection, step by step' shows each message.
CDN edge server → Browser (Certificate). The server proves it really is example.com with a certificate signed by an authority the browser trusts. Both sides now share keys nobody else has, and the lock icon appears.
Browser → CDN edge server (GET /). Over the encrypted connection, the browser asks for the page.
CDN edge server → Load balancer (GET /). This home page changes from visit to visit, so the CDN has no copy it can reuse. It passes the request on to the site's own servers.
Load balancer → App server (GET /). The load balancer picks an app server that isn't busy.
App server → Database (Latest posts?). The app server runs the site's code, which needs data from the database to fill in the page.
Database → App server (12 posts). The database returns the rows.
App server → Load balancer (200 OK + HTML). The app server fills in the page template and sends back the HTML. 200 means OK.
Load balancer → CDN edge server (200 OK + HTML). The load balancer passes the answer back through the CDN.
CDN edge server → Browser (200 OK + HTML). The page arrives. The browser reads the HTML, asks for the styles, scripts and images it mentions (mostly answered from the CDN's cache), and draws the page.

Flow: Secure connection, step by step

The handshakes behind the lock icon: TCP opens a connection, then TLS 1.3 checks the server's identity and agrees on keys, in two round trips before the first request.

Browser → CDN edge server (SYN). TCP first. The browser asks the server at 203.0.113.10 to open a connection.
CDN edge server → Browser (SYN-ACK). The server agrees and asks for confirmation.
Browser → CDN edge server (ACK + ClientHello). The browser confirms, completing TCP's three-way handshake, and starts TLS at once: the versions and ciphers it supports, the site name, and its half of a key exchange.
CDN edge server → Browser (ServerHello + cert). The server picks the settings, sends its half of the key exchange and its certificate, and proves it holds the certificate's private key. From here on, everything is encrypted.
Browser → CDN edge server (Finished + GET /). The browser checks the certificate: the right name, signed by an authority it trusts, not expired. It sends Finished and, in the same message, the request for the page.
CDN edge server → Browser (200 OK + HTML). The page comes back encrypted. Setting up took two round trips, one for TCP and one for TLS, which is why a nearby CDN server makes the first visit noticeably faster.

Flow: Open the page again

A visit a few minutes later: the address is still cached and the connection may still be open, so DNS and the handshakes are skipped.

Browser → CDN edge server (GET /). The browser still has the address from last time, and often the open connection too, so it sends the request straight away. No DNS servers are asked.
CDN edge server → Load balancer (GET /). The page may have changed since your last visit, so the CDN passes the request to the site's servers.
Load balancer → App server (GET /). The load balancer picks an app server.
App server → Database (Latest posts?). The app server asks the database for the data the page shows.
Database → App server (13 posts). Someone posted since your last visit.
App server → Load balancer (200 OK + HTML). The app server builds the page.
Load balancer → CDN edge server (200 OK + HTML). The answer passes back through the CDN.
CDN edge server → Browser (200 OK + HTML). The page arrives. Styles, scripts and images come from the browser's own cache this time, so it appears much faster.

Flow: Fetch images, styles and scripts

The extra files a page needs are the same for everyone, so the CDN answers them from its cache without bothering the site's servers.

Browser → CDN edge server (GET /style.css). While reading the HTML, the browser finds a stylesheet it needs before it can draw the page, and asks for it over the connection that's already open.
CDN edge server → Browser (style.css (cached)). The CDN server already has a copy, because other visitors asked for the same file, so it answers straight away. The site's own servers never see this request.

Sources

HowItScales is not affiliated with the companies shown. Components marked Assumption or Hypothetical are not confirmed by the company.