Deep Dive 01 — What Happens When You Type a URL

Shreyesh kolhe
July 10, 2026

Deep Dive 01 — What Happens When You Type a URL

Hey everyone! Welcome to the Deep Dives! 🙏

This is the ultimate networking interview question — "What happens when you type google.com and press Enter?" It's beloved because a great answer weaves together every single topic in this series: DNS, TCP, TLS, HTTP, and rendering. Let's trace the complete journey, end to end, so you can narrate it confidently.

What we will cover:

  • The full journey, step by step
  • Each step mapped to its chapter
  • The one-diagram summary
  • How to tell this story in an interview
  • Interview Questions

1. The Full Journey — Step by Step

   You type "https://www.google.com" and hit Enter. Here we go:

┌─────────────────────────────────────────────────────────────┐
│  STEP 1 — URL PARSING                                        │
│  Browser breaks the URL into parts: scheme (https), host    │
│  (www.google.com), path (/), port (443 default for https).  │
├─────────────────────────────────────────────────────────────┤
│  STEP 2 — DNS LOOKUP  (Chapter 06)                          │
│  "www.google.com" → IP address. Check caches (browser, OS,  │
│  resolver); if missed, walk root → .com → google's server → │
│  get e.g. 142.250.72.14.                                    │
├─────────────────────────────────────────────────────────────┤
│  STEP 3 — TCP HANDSHAKE  (Chapter 05)                       │
│  Browser opens a TCP connection to 142.250.72.14:443 via    │
│  the 3-way handshake: SYN → SYN-ACK → ACK.                  │
├─────────────────────────────────────────────────────────────┤
│  STEP 4 — TLS HANDSHAKE  (Chapter 08)                       │
│  Since it's HTTPS, negotiate encryption: verify the server's │
│  certificate, agree on a symmetric session key. 🔒          │
├─────────────────────────────────────────────────────────────┤
│  STEP 5 — HTTP REQUEST  (Chapter 07)                        │
│  Browser sends: GET / HTTP/1.1, Host: www.google.com,       │
│  plus headers (cookies, accept, user-agent), all encrypted. │
├─────────────────────────────────────────────────────────────┤
│  STEP 6 — SERVER PROCESSES & RESPONDS                       │
│  Server (possibly behind a load balancer + cache + CDN)     │
│  builds the response: 200 OK + HTML. Packets routed back.   │
├─────────────────────────────────────────────────────────────┤
│  STEP 7 — BROWSER RENDERS                                   │
│  Browser parses HTML → sees it needs CSS, JS, images → fires │
│  MORE requests (each may reuse the connection / hit a CDN) → │
│  builds the page → you see Google. ✅                       │
└─────────────────────────────────────────────────────────────┘

2. The One-Diagram Summary

   TYPE URL
      │
      ▼
   [Parse URL] → [DNS: name→IP] → [TCP handshake] → [TLS handshake]
      │                                                     │
      ▼                                                     ▼
   [HTTP GET request] ──▶ [ Server / LB / CDN ] ──▶ [HTTP 200 + HTML]
                                                            │
                                                            ▼
                                            [Browser parses & renders]
                                            [fetches CSS/JS/images...]
                                                            │
                                                            ▼
                                                    PAGE APPEARS 🎉

3. Extra Details That Impress

   • The browser first checks its own CACHE — maybe it doesn't
     need the network at all (304 Not Modified / cached page).
   • ARP/MAC: locally, IP is resolved to a MAC address to reach
     the router (data link layer, Chapter 02).
   • The request likely hits a CDN edge server near you, not
     google's origin — faster (recall the System Design CDN chapter).
   • HTTP/2 or /3 lets many resources download in parallel over
     one connection (Chapter 10).
   • Keep-alive reuses the TCP connection for multiple requests
     instead of re-handshaking each time.

4. How to Tell This Story in an Interview

   Narrate it as a JOURNEY, naming each protocol and its layer:
   "First the browser parses the URL. Then DNS resolves the name
   to an IP. It opens a TCP connection with the three-way
   handshake, and since it's HTTPS, does a TLS handshake to set up
   encryption. Then it sends an HTTP GET request. The server —
   often behind a load balancer and CDN — responds with HTML. The
   browser parses it, fetches additional resources like CSS and
   JS, and renders the page."

   → Hitting DNS → TCP → TLS → HTTP → render IN ORDER shows you
     understand how all the pieces fit. That's the whole point.

Interview Questions — Quick Fire!

Q: What happens when you type a URL and press Enter?

"The browser parses the URL into its scheme, host, port, and path. It resolves the hostname to an IP via DNS, checking caches first. It opens a TCP connection to that IP using the three-way handshake, and for HTTPS performs a TLS handshake to establish encryption. It then sends an HTTP GET request; the server, often behind a load balancer and CDN, returns an HTTP response with HTML. The browser parses the HTML, fetches additional resources like CSS, JavaScript, and images, and renders the page."

Q: Where does DNS fit in that process?

"Right after URL parsing. The browser needs the server's IP address to connect, but the URL only has a hostname, so DNS translates the hostname to an IP. It checks the browser, OS, and resolver caches first, and if it's a miss, the resolver walks the DNS hierarchy — root, then the TLD, then the domain's authoritative server — to get the IP."

Q: Why is there both a TCP handshake and a TLS handshake?

"They serve different purposes. The TCP handshake establishes a reliable transport connection between the two machines. The TLS handshake, which happens on top of the established TCP connection for HTTPS, sets up encryption — verifying the server's certificate and agreeing on a session key. So TCP gives you a reliable channel, and TLS makes that channel private and authenticated."

Q: After the HTML arrives, what does the browser do?

"It parses the HTML and discovers references to other resources — stylesheets, scripts, images, fonts — and issues additional requests to fetch them, often in parallel and frequently from a CDN. As resources arrive, it builds the page's structure and styling and executes scripts, progressively rendering until the full page is displayed."

Key Points to Remember

StepWhat happens
1. Parse URLExtract scheme, host, port, path.
2. DNSHostname → IP (cache first, else walk the hierarchy).
3. TCP3-way handshake sets up a reliable connection.
4. TLSFor HTTPS: verify cert, agree session key (encryption).
5. HTTPSend GET request with headers.
6. ResponseServer (LB/CDN) returns 200 + HTML.
7. RenderParse HTML, fetch CSS/JS/images, display page.

What's Next?

Deep Dive 02 zooms into one step of that journey — the TCP connection — and traces its full lifecycle from handshake to teardown, packet by packet.

Keep learning, keep connecting! See you in the next one!