What actually happens when you type a URL and press Enter

Every backend and frontend interview eventually lands on this question. Here's the whole journey, in order, without hand-waving.

1. DNS — finding the address

Your browser needs an IP address for satyamx.in. It checks caches first (browser → OS → router), and only then asks a DNS resolver, which walks the hierarchy: root servers → .in TLD servers → the domain's nameservers.

You can watch this happen:

dig satyamx.in +trace

The answer comes back with a TTL — that's how long every cache along the way is allowed to keep it.

2. TCP — opening the connection

With an IP in hand, the browser opens a TCP connection to port 443. That's the three-way handshake:

client  →  SYN        →  server
client  ←  SYN-ACK    ←  server
client  →  ACK        →  server

One full round trip before a single byte of real data moves. This is why physical distance to the server still matters, and why CDNs put servers near users.

3. TLS — making it private

Next comes the TLS handshake: the server proves its identity with a certificate, and both sides agree on keys to encrypt everything that follows. TLS 1.3 got this down to one round trip.

4. HTTP — finally, the actual request

Only now does the browser send what you wanted all along:

GET / HTTP/2
Host: satyamx.in
Accept: text/html

The server responds with HTML. If there's a CDN in front (like Vercel's edge), a cached copy might come from a server 20km away instead of the origin.

5. Rendering — the browser's half of the story

The browser parses HTML top to bottom, discovers CSS and JS it needs, fetches those (more requests!), builds the DOM and CSSOM, and paints pixels. Modern frameworks then hydrate the page — attaching JavaScript behavior to the server-rendered HTML.

The takeaway

Before your code runs at all, there have been ~4 network round trips: DNS, TCP, TLS, HTTP. Every performance trick in the book — caching, CDNs, keep-alive connections, HTTP/2 multiplexing — exists to reduce or reuse one of these steps.