How the Web Works

Every time you visit a web page, a small but precise choreography takes place between your browser, several servers, and the global networking infrastructure. Understanding this sequence is foundational — it explains caching, HTTPS, latency, and dozens of other concepts you will encounter constantly as a web developer.

The Client-Server Model

The web is built on a simple split of responsibilities. A client (usually a browser) initiates requests; a server listens for those requests and sends back responses. Neither side can exist without the other. Clients never push unsolicited data to each other directly — all communication flows through servers.

DNS: Translating Names to Addresses

Computers on the internet are addressed by IP addresses like 142.250.80.46. Humans use domain names like example.com. The Domain Name System (DNS) is the distributed phonebook that translates one to the other.

When you type https://example.com:

Your browser checks its own DNS cache.
If not found, it asks your operating system, which checks its cache.
If still not found, a query goes to a recursive resolver (usually provided by your ISP or a service like 1.1.1.1).
The resolver asks the root nameservers, which point it to the .com top-level-domain servers.
Those point to example.com’s authoritative nameserver, which returns the IP.

This whole process typically takes 10–50 ms and the result is cached aggressively to avoid repeating it.

TCP/IP: Reliable Packet Delivery

Once the browser has an IP address it opens a TCP connection. TCP (Transmission Control Protocol) breaks data into packets, sends them over IP (Internet Protocol), and guarantees they arrive in order with no data lost. Before any data is exchanged, a three-way handshake occurs: SYN → SYN-ACK → ACK. HTTPS adds a TLS handshake on top to establish encryption.

HTTP: The Application Protocol

With a connection open, the browser sends an HTTP request — a plain-text (or, in HTTP/2, binary-framed) message specifying a method, a path, headers, and an optional body. The server processes it and returns an HTTP response with a status code, headers, and a body.

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234

<!doctype html>...

Browser Rendering

Once the HTML arrives the browser parses it into the DOM (Document Object Model), fetches linked CSS and JavaScript files, builds the CSSOM, combines them into a render tree, performs layout (computing positions and sizes), and finally paints pixels to the screen. JavaScript can block this pipeline, which is why <script> tags are often placed at the end of <body> or marked defer.

sequenceDiagram
    participant B as Browser
    participant D as DNS Resolver
    participant S as Web Server

    B->>D: Resolve example.com
    D-->>B: 93.184.216.34
    B->>S: TCP SYN
    S-->>B: TCP SYN-ACK
    B->>S: TCP ACK + TLS Handshake
    S-->>B: TLS Complete
    B->>S: GET /index.html HTTP/1.1
    S-->>B: 200 OK (HTML body)
    B->>S: GET /style.css
    S-->>B: 200 OK (CSS body)
    B->>S: GET /app.js
    S-->>B: 200 OK (JS body)
    Note over B: Parse HTML → DOM<br/>Parse CSS → CSSOM<br/>Execute JS<br/>Render page

TIP

Open your browser’s DevTools Network tab and reload any page. You can watch every single step above happen in real time: DNS lookup, TCP connect, TLS, TTFB (time to first byte), and asset downloads are all shown with timing breakdowns.

NOTE

HTTP/2 and HTTP/3 improve on HTTP/1.1 by multiplexing many requests over a single connection (HTTP/2) or using UDP instead of TCP (HTTP/3 via QUIC), but the request/response concept and status codes remain the same.

Further Learning

Search these terms to go deeper:

“HTTP/1.1 vs HTTP/2 vs HTTP/3” — how each version improved on the last and what QUIC is
“TLS handshake explained” — how HTTPS establishes a secure, encrypted channel
“Critical rendering path browser” — the detailed sequence from HTML bytes to painted pixels
“DNS TTL caching” — how long DNS responses are cached and why it matters for deployments
“TCP three-way handshake” — the exact SYN/SYN-ACK/ACK sequence and why TCP needs it

How the Web Works

Think of visiting a web page like ordering food at a restaurant. You (the browser) ask for something, a kitchen (the server) makes it, and it comes back to your table. Let’s walk through what actually happens — step by step, in plain language.

Who talks to who: the client and the server

There are two roles on the web:

The client is the thing that asks — usually your browser (Chrome, Safari, etc.).
The server is the computer that answers, sending back the page.

The client always asks first. The server just waits and replies. Two browsers never talk to each other directly — everything goes through a server in the middle, like customers ordering through the kitchen rather than cooking for each other.

Step 1 — Finding the address (DNS)

You type a name like example.com, but computers actually find each other using numbers called IP addresses (like a phone number for a computer). Something needs to turn the name into the number.

That job belongs to DNS, which works like the internet’s contacts app: you give it a name, it gives you back the number. Your browser asks, “What’s the address for example.com?” and DNS answers with something like 142.250.80.46. This usually takes a fraction of a second, and the answer is remembered for a while so it doesn’t have to be looked up every time.

Step 2 — Making a connection (TCP/IP)

Now that your browser knows the address, it needs to open a reliable line to that server — like dialing the number and waiting for someone to pick up.

TCP/IP is the system that carries your data across the internet. It chops the data into small pieces, sends them, and makes sure they all arrive in the right order with nothing missing. If the site uses HTTPS (the secure padlock version), an extra step sets up encryption so nobody in between can read what’s sent.

Step 3 — Asking for the page (HTTP)

With the line open, your browser sends a request: basically a polite note saying “please give me this page.” The server reads it and sends back a response: the page itself, plus a little status label saying whether it worked.

You’ll often see status numbers: 200 means “OK, here you go,” and 404 means “I couldn’t find that.”

Step 4 — Drawing the page (rendering)

The server sends back HTML — the text and structure of the page. Your browser reads it and builds an internal map of the page called the DOM. It also downloads the CSS (which controls colors and layout) and any JavaScript (which adds interactivity), then paints everything onto your screen.

sequenceDiagram
    participant B as Browser (you)
    participant D as DNS (contacts app)
    participant S as Server (kitchen)

    B->>D: What's the address for example.com?
    D-->>B: It's 142.250.80.46
    B->>S: Please send me the page
    S-->>B: Here it is (HTML)
    Note over B: Build the page and draw it on screen

TIP

Want to see it happen? Open your browser’s DevTools (right-click → Inspect → “Network” tab) and reload a page. You’ll watch each step above happen in real time.

In one sentence

You ask for a page by name, DNS turns the name into an address, your browser opens a secure line to that address, asks for the page with HTTP, and then draws what comes back. That’s the whole web in a nutshell.

Want to go deeper?

When you’re ready, switch to Expert mode above to read the full technical version with the exact protocols and handshakes.