LinkedIn Hook

You type https://github.com and press Enter.

247 milliseconds later, a page appears.

Most developers treat that as magic. Senior engineers can narrate every millisecond.

What actually happens involves at least 8 distinct steps, 4 different protocols, and every layer of the OSI model — all before a single byte of HTML reaches your browser.

Lesson 8.1 of my Networking Interview Prep series walks through the complete journey: DNS resolution, TCP handshake, TLS negotiation, HTTP round trip, and browser rendering — tied back to the exact OSI layers each step lives on.

This is the question that ends every networking interview. Read the full lesson → [link]

#Networking #WebDevelopment #InterviewPrep #SoftwareEngineering #BackendDevelopment

How a Web Request Actually Works thumbnail

What You'll Learn

Every step between pressing Enter and pixels appearing on screen
How DNS, TCP, TLS, and HTTP interlock in the correct sequence
Which OSI layer each step belongs to — and why that framing matters
Where latency hides in the request lifecycle and how to reduce it
What browser caches, OS caches, and CDN caches intercept before a real network call
How to answer "walk me through what happens when you type a URL" in any interview

The Postal Service Analogy

Before a single packet leaves your machine, you have to find out where to send it. Then you have to establish a secure line. Then you can actually talk.

Think of it like mailing a sensitive letter internationally:

You look up the recipient's address in a directory (DNS)
You call them to confirm they're ready to receive (TCP handshake)
You agree on a secret code so nobody can read the letter in transit (TLS handshake)
You write the letter and mail it; they write back (HTTP request/response)
You read what they sent back (browser rendering)

Each step depends on the one before it. Skip any and the whole thing breaks.

The Complete Journey — Step by Step

Let's trace https://github.com from the Enter key to the rendered page.

Step 0 — Browser Cache Check (Layer 7)

Before touching the network at all, the browser checks its own cache:

DNS cache — did it already resolve github.com to an IP recently?
HTTP cache — does it have a cached response for this URL that is still fresh?
Preload / Service Worker — is a service worker intercepting this?

If any cache hits, the browser can skip steps 1–4 entirely and render from local storage. Cache misses proceed to Step 1.

Step 1 — DNS Resolution (Layers 3, 7)

The browser knows github.com but not its IP address. It needs to resolve the name.

Browser → OS DNS cache
               |
          (cache miss)
               ↓
         Recursive Resolver (your ISP or 8.8.8.8)
               |
          (cache miss)
               ↓
         Root Server → "ask .com TLD server"
               ↓
         .com TLD Server → "ask github.com nameserver"
               ↓
         github.com Authoritative Nameserver
               ↓
         Returns: github.com → 140.82.121.4

The full resolution takes multiple round trips but typically completes in 20–120 ms for a cold lookup. Most requests hit the recursive resolver's cache and take under 5 ms.

The result is stored in:

Browser DNS cache (for a few minutes)
OS DNS cache (/etc/hosts + resolver cache)
Recursive resolver cache (for the TTL period defined in the DNS record)

DNS uses UDP port 53 for queries (Layer 4: UDP). The IP lookup is Layer 3. The domain name system is an application-layer (Layer 7) protocol.

Step 2 — TCP Handshake (Layer 4)

Now the browser knows the IP: 140.82.121.4. It needs a reliable connection before sending any data. TCP requires a 3-way handshake to establish this.

Browser (client)          GitHub (server)
      |                         |
      |--- SYN ---------------→ |   "I want to connect"
      |                         |
      |← SYN-ACK -------------- |   "OK, I'm ready"
      |                         |
      |--- ACK ---------------→ |   "Great, let's go"
      |                         |
      [ Connection established ]

Cost: 1 Round Trip Time (RTT)

For a server 50ms away, this step takes 50ms of wall-clock time. This is why geographic distance still matters even with fast servers — physics imposes a minimum RTT.

The browser opens a TCP connection to port 443 (HTTPS). For plain HTTP it would be port 80.

After the handshake the connection enters the ESTABLISHED state and is ready for data.

Step 3 — TLS Handshake (Layer 6 / Layer 4)

Since this is HTTPS, the browser needs to negotiate encryption before sending any HTTP data. TLS 1.3 (the current standard) does this in 1 RTT (down from 2 RTT in TLS 1.2).

Browser                          GitHub
   |                                |
   |--- ClientHello --------------→ |
   |    (TLS version, cipher suites, random nonce)
   |                                |
   |← ServerHello + Certificate --- |
   |    (chosen cipher, cert, key exchange)
   |                                |
   |--- (key derivation happens locally on both sides)
   |                                |
   |--- Finished ------------------→|
   |← Finished -------------------- |
   |                                |
   [ Encrypted tunnel established ]

Cost: 1 RTT (TLS 1.3) or 2 RTT (TLS 1.2)

During the handshake:

The browser verifies GitHub's certificate was signed by a trusted Certificate Authority
Both sides derive a shared symmetric key without ever transmitting it directly (Diffie-Hellman key exchange)
All subsequent data in this TCP connection is encrypted

Running total so far: DNS lookup + TCP handshake + TLS handshake = roughly 3–4 RTTs before a single byte of HTTP travels.

This is why HTTP/3 (QUIC) is valuable — it merges the TCP and TLS handshakes into a single round trip.

Step 4 — HTTP Request (Layer 7)

The encrypted tunnel is ready. The browser sends an HTTP GET request:

GET / HTTP/2
Host: github.com
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
User-Agent: Mozilla/5.0 (...)
Cookie: _gh_sess=...
Cache-Control: max-age=0

This is sent encrypted through the TLS tunnel over the established TCP connection.

Key headers the server cares about:

Host — which virtual host to route to (one server IP can host many domains)
Accept-Encoding — browser supports gzip/brotli compression
Cookie — session ID so GitHub knows who you are
Cache-Control: max-age=0 — "don't serve me a stale cached version"

Step 5 — Server Processing (Layer 7, Application)

This step happens entirely on the server. The OS receives the TCP segments, reconstructs them, decrypts via TLS, and hands the HTTP request to the web server (typically Nginx or a similar reverse proxy).

Network interface card
         ↓
    OS TCP/IP stack
         ↓
    TLS decryption
         ↓
    Nginx / reverse proxy
         ↓
    Application server (Node.js, Rails, Go, etc.)
         ↓
    Business logic (auth check, database query, cache lookup)
         ↓
    Response assembled (HTML / JSON)
         ↓
    (path reversed back to the client)

For github.com, the server checks your session cookie, queries its database for your repositories and notifications, assembles the dashboard HTML, and sends it back.

Step 6 — HTTP Response (Layer 7)

The server sends back a response through the same TLS tunnel:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Cache-Control: no-cache, private
X-Content-Type-Options: nosniff
X-Frame-Options: deny
Strict-Transport-Security: max-age=31536000; includeSubdomains

[compressed HTML body — several KB to hundreds of KB]

Key response headers:

Content-Encoding: gzip — body is compressed; browser decompresses automatically
Cache-Control: no-cache, private — dynamic dashboard, never cache this
Strict-Transport-Security — HSTS: "always use HTTPS for this domain for 1 year"
X-Frame-Options: deny — prevents this page from being embedded in an iframe (clickjacking protection)

The response is broken into TCP segments, wrapped in IP packets, and transmitted back to your machine.

Step 7 — TCP Teardown (Layer 4)

Once the response is fully sent (or if connection reuse is not configured), the TCP connection is gracefully closed with a 4-way FIN exchange:

Client        Server
  |--- FIN →    |
  |← ACK ---    |
  |← FIN ---    |
  |--- ACK →    |
  [ Connection closed ]

In practice, HTTP/1.1 with keep-alive and HTTP/2 reuse the same TCP connection for many requests, avoiding this overhead per request.

Step 8 — Browser Rendering (Application Layer)

The browser receives the HTML and begins rendering:

HTML received
      ↓
Parse HTML → build DOM tree
      ↓
Encounter <link rel="stylesheet"> → fetch CSS (new HTTP request!)
      ↓
Parse CSS → build CSSOM
      ↓
Encounter <script> → fetch JS (may block rendering)
      ↓
Combine DOM + CSSOM → Render Tree
      ↓
Layout (calculate positions/sizes)
      ↓
Paint (draw pixels to screen)
      ↓
Composite layers → display

Every external resource (CSS, JS, fonts, images) triggers its own trip through steps 1–7 — though DNS is cached, and HTTP/2 multiplexes multiple fetches over the same TCP connection simultaneously.

The Complete Timeline

 0ms   User presses Enter
       |
 0ms   Browser checks local caches (DNS cache, HTTP cache)
       |
 5ms   DNS resolution starts (or completes from cache)
       |
 25ms  DNS resolved → IP in hand
       |
 25ms  TCP SYN sent
       |
 75ms  TCP SYN-ACK received (50ms RTT to server)
       |
 75ms  TCP ACK sent → connection established
       |
 75ms  TLS ClientHello sent
       |
125ms  TLS handshake complete → encrypted tunnel up
       |
125ms  HTTP GET request sent
       |
175ms  HTTP response first byte received (TTFB)
       |
247ms  Full response received and browser renders

TTFB (Time To First Byte) is the metric measuring step 4→response start. A good TTFB is under 200ms. Above 500ms signals a server-side problem.

Where Latency Hides

Step	Typical Duration	How to Reduce
DNS resolution	20–120ms (cold)	DNS caching, low-TTL awareness, DNS prefetch
TCP handshake	1 × RTT	CDN edge nodes closer to user
TLS handshake	1–2 × RTT	TLS 1.3, HTTP/3 (QUIC), TLS session resumption
Server processing	10–500ms+	Database indexing, caching (Redis), faster code
Data transfer	depends on size	Compression (gzip/brotli), HTTP/2 multiplexing
Browser rendering	50–200ms	Reduce render-blocking resources, code splitting

How a Web Request Actually Works visual 1

Common Mistakes

Forgetting TLS in the sequence. Many candidates describe DNS → TCP → HTTP and skip TLS entirely. For any HTTPS URL, TLS is non-negotiable and adds 1–2 RTTs before the first HTTP byte. Interviewers specifically watch for this omission.
Treating DNS as instantaneous. DNS can be the most expensive step for a cold first visit, especially if the recursive resolver does not have the record cached. A misconfigured DNS TTL of 30 seconds means every new user waits for a full recursive lookup. Awareness of DNS caching layers is what separates a thorough answer from a surface-level one.
Confusing TCP handshake and TLS handshake. These are two separate handshakes in sequence. TCP establishes the transport connection. TLS negotiates encryption on top of it. They cannot be swapped or merged (except in HTTP/3, where QUIC merges them by design).

Interview Questions

Q: Walk me through what happens when you type https://example.com in a browser.

Browser checks DNS cache, HTTP cache, and service worker intercepts. Cache miss proceeds to step 2.

DNS resolution: browser → OS cache → recursive resolver → root → TLD → authoritative server. Returns IP address.

TCP 3-way handshake (SYN/SYN-ACK/ACK) to port 443. Cost: 1 RTT.

TLS handshake: ClientHello, ServerHello + certificate, key exchange, Finished. Cost: 1 RTT (TLS 1.3). Browser verifies certificate against trusted CAs.

HTTP GET request sent through encrypted TLS tunnel.

Server processes request (auth, database, business logic), sends HTTP 200 response.

TCP teardown or connection reuse for subsequent requests.

Browser parses HTML → builds DOM → fetches CSS/JS (sub-requests) → builds render tree → lays out → paints → displays.

Q: What is TTFB and what causes a high TTFB?

TTFB (Time To First Byte) is the time from the client sending the HTTP request to receiving the first byte of the HTTP response. It measures server-side processing time plus the network round trip. A high TTFB (>500ms) typically indicates: slow database queries, missing cache layer (results not in Redis/Memcached), server under load, or geographic distance from the server. A CDN can reduce TTFB for static content by serving from a nearby edge node, but dynamic content TTFB depends on the origin server.

Q: Why does HTTPS add latency and how does HTTP/3 reduce it?

HTTPS requires a TLS handshake after the TCP handshake — two separate round trips (1 RTT for TCP + 1-2 RTT for TLS) before any HTTP data flows. HTTP/3 uses QUIC over UDP, which merges the transport and cryptographic handshakes into a single 1 RTT exchange (or 0-RTT for returning clients). This eliminates the dedicated TCP SYN/SYN-ACK step, reducing connection setup from 2-3 RTTs to 1 RTT.

Q: How does a browser know which TCP connection to reuse for a second request to the same server?

The browser maintains a connection pool keyed by host:port. When a second request targets the same origin, the browser checks for an idle established connection in the pool before opening a new one. HTTP/1.1 with Connection: keep-alive allows sequential reuse of one connection. HTTP/2 goes further — it multiplexes many requests as concurrent streams over the same connection, so 10 parallel requests share one TCP connection rather than requiring 10 separate ones.

Quick Reference — Cheat Sheet

The 8-Step Web Request

ENTER KEY PRESSED
        |
[0] Browser Caches → DNS cache, HTTP cache, service worker
        |
[1] DNS Resolution (UDP port 53, Layer 3+7)
        browser → OS → recursive resolver → root → TLD → authoritative
        Result: hostname → IP address
        |
[2] TCP Handshake (Layer 4, port 443)
        SYN → SYN-ACK → ACK
        Cost: 1 RTT
        |
[3] TLS Handshake (Layer 6)
        ClientHello → ServerHello + Cert → Key Exchange → Finished
        Cost: 1 RTT (TLS 1.3), 2 RTT (TLS 1.2)
        |
[4] HTTP Request (Layer 7)
        GET / HTTP/2  +  headers  →  server
        |
[5] Server Processing (Application)
        Nginx → app server → DB → cache → response assembled
        |
[6] HTTP Response (Layer 7)
        200 OK + headers + compressed body  ←  server
        |
[7] TCP Teardown or connection reuse
        |
[8] Browser Rendering
        DOM → CSSOM → Render Tree → Layout → Paint → Composite

Latency Budget (Typical)

Step	Budget
DNS (cached)	< 5 ms
DNS (cold lookup)	20–120 ms
TCP handshake	1 × RTT
TLS 1.3 handshake	1 × RTT
Server processing	10–500 ms
Data transfer	varies
Rendering	50–200 ms

OSI Layer Reference

Step	OSI Layer
DNS query/response	Layer 7 (Application) + Layer 3 (Network)
TCP handshake	Layer 4 (Transport)
TLS handshake	Layer 6 (Presentation)
HTTP request/response	Layer 7 (Application)
IP routing (packets)	Layer 3 (Network)
Ethernet frames	Layer 2 (Data Link)
Electrical/optical signals	Layer 1 (Physical)

Previous: Lesson 7.3 → Next: Lesson 8.2 →

This is Lesson 8.1 of the Networking Interview Prep Course — 8 chapters, 32 lessons.

How a Web Request Actually Works