Beginner System Architecture

How a Web Request Works

When you type a URL and press Enter, a lot happens in under a second. Understanding each step helps you debug slow pages, design APIs, and reason about security. Let’s follow a request from the browser to the server and back.

The big picture

Browser  ->  DNS  ->  TCP  ->  TLS  ->  HTTP request  ->  Server
   ^                                                         |
   |------------------- HTTP response ------------------------
   |
 Render (HTML, CSS, JS)

Step 1: DNS lookup

The browser needs the server’s IP address. The domain name (like example.com) is human-friendly, but routers speak numbers. DNS (Domain Name System) translates the name into an IP such as 93.184.216.34. Results are cached in the browser, the OS, and resolvers to avoid repeating the lookup.

Step 2: TCP connection

With an IP in hand, the browser opens a TCP connection. TCP guarantees ordered, reliable delivery. It starts with a three-way handshake:

Client  --- SYN --->     Server
Client  <-- SYN/ACK ---  Server
Client  --- ACK --->     Server

After the handshake, both sides can exchange bytes.

Step 3: TLS handshake (HTTPS)

For https://, a TLS handshake runs on top of TCP. The client and server agree on encryption keys and the server proves its identity with a certificate. From here, all traffic is encrypted, so no one in the middle can read it.

Step 4: HTTP request and response

Now the browser sends an HTTP request.

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

The server answers with a status line, headers, and a body.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!DOCTYPE html><html>...</html>

Step 5: Browser render

The browser parses the HTML into a DOM tree, applies CSS, then runs JavaScript. It often makes more requests for images, stylesheets, and scripts. Finally pixels appear on screen.

Why it matters

  • Each step adds latency; caching and reused connections cut it down.
  • Failures at any layer (DNS, TCP, TLS, HTTP) produce different errors.
  • Security lives mainly in the TLS layer.

Knowing this pipeline turns vague “the site is slow” into a concrete question: which step is slow?