Gyaan

How the Web Works — Request Lifecycle

beginner http dns request-lifecycle client-server networking

“What happens when you type a URL and hit enter?” is the most classic interview warm-up there is. In simple language — a whole relay race of steps kicks off before a single byte of the page shows up.

Let’s walk through it end-to-end. Same thing happens whether it’s a browser loading a page or our mobile app calling an API.

The client-server model

The web runs on a simple deal. A client (browser, app, curl) asks for something. A server listens, does the work, and answers back. The client always starts the conversation — servers never call us out of the blue over plain HTTP.

Think of it like ordering at a restaurant. We (the client) ask the waiter for a dish. The kitchen (the server) cooks it and sends it out. We don’t walk into the kitchen ourselves.

The full journey of a request

Here’s the whole relay, top to bottom.

GET https://api.shop.com/orders
1DNS — turn api.shop.com into an IP like 93.184.x.x
↓
2TCP handshake — open a reliable connection to that IP:443
↓
3TLS handshake — verify the cert, agree on encryption keys
↓
4HTTP request — send the method, path, headers, body
↓
5Server processing — routing, auth, business logic, DB query
↓
6HTTP response — status code, headers, body (JSON/HTML)
↓
7Client renders — parse JSON / paint the page

Step 1 — DNS resolution

Computers talk in IP addresses, not names. DNS (Domain Name System) is the phone book that maps api.shop.com to an IP.

Our machine checks caches first (browser cache → OS cache → the router), and only if it misses does it ask a resolver which walks the DNS hierarchy (root → .com → shop.com). The answer comes back with a TTL — how long we’re allowed to cache it. This is why a DNS change can take a while to spread everywhere.

Step 2 — TCP handshake

Now we have an IP. Before sending any data, TCP does a 3-way handshake to open a reliable pipe: SYN → SYN-ACK → ACK. After those three packets, both sides agree the connection is live.

We cover TCP in depth in its own note. For now — this is the “are you there? yes I’m here. great, let’s talk” bit.

Step 3 — TLS handshake

Because it’s https://, we layer encryption on top. The client and server verify the server’s certificate, prove the server owns the domain, and agree on secret keys so nobody snooping the wire can read the traffic. Also its own note — just know it happens right after TCP and before any HTTP.

Step 4 — The HTTP request

Finally the actual ask. A plain-text request with a method, a path, headers, and maybe a body.

GET /orders HTTP/1.1
Host: api.shop.com
Authorization: Bearer eyJhbGc...
Accept: application/json

Step 5 — Where the backend sits

This is our world. The request lands, and the backend does the heavy lifting:

  • Routing — match /orders to a handler
  • Auth — is this token valid? is this user allowed?
  • Business logic — validate input, run the rules
  • Data layer — query the database or a cache, call other services
  • Serialize — turn the result into JSON

The backend is the brain between the network and the data. Everything in this whole collection is about doing steps here well.

Step 6 & 7 — Response and render

The server sends back a status code (200, 404, 500…), headers, and a body. The client reads the status, parses the body, and does its thing — a browser paints the page, our app updates state.

Often the first response is HTML that references more assets (CSS, JS, images), and each of those kicks off its own mini request lifecycle. A single page load can be dozens of these.

Practical takeaway

  • DNS → TCP → TLS → HTTP → server → response is the skeleton — memorize the order.
  • The client always starts the conversation; the server responds.
  • DNS is cached at every layer, gated by TTL.
  • TCP gives a reliable pipe, TLS wraps it in encryption — both happen before the first HTTP byte.
  • The backend is steps 5’s routing, auth, logic, and data access — that’s the job.

References