What Happens When You Type a URL

"What happens when you type https://www.example.com into a browser and press Enter?" is probably the most commonly asked networking interview question. It is popular because there is no single right answer: it is an open invitation to show how much of the stack you understand, from the keyboard to DNS, TCP, TLS, HTTP, load balancers, servers, and the browser's rendering engine.

A weak answer lists "DNS, then TCP, then HTTP" and stops. A strong answer tells a coherent story in order, explains why each step happens, mentions the caches and shortcuts that skip steps, and lets the interviewer pull on any thread to go deeper. This lesson walks through the whole journey in depth, ties each step back to the earlier lessons in this track, gives a full timeline, and ends with how to compress the answer into two minutes or expand it to fifteen.

We will follow a concrete example throughout: you type example.com/products?id=7 into Chrome on a laptop connected to home Wi-Fi, and the site is behind a CDN and a load balancer.

The big picture first

Before diving in, here is the whole journey on one page. Each numbered stage gets its own section.

 1. Keypress, URL parsing, omnibox decides "URL or search?"
 2. HSTS check: upgrade http to https?
 3. Caches: service worker? HTTP cache? existing connection?
 4. DNS: browser -> OS -> resolver -> root -> TLD -> authoritative
 5. ARP: find the MAC address of the default gateway
 6. TCP three-way handshake with the server (or CDN edge)
 7. TLS handshake: certificate check, key agreement
 8. HTTP request sent (HTTP/2 or HTTP/3)
 9. CDN edge / load balancer / reverse proxy route the request
10. Application server: auth, business logic, database, cache
11. HTTP response travels back
12. Browser parses HTML -> DOM, CSS -> CSSOM, runs JS
13. Render tree -> layout -> paint -> composite: pixels on screen
14. Sub-resources (CSS, JS, images) fetched, connections reused

Stage 1: the keypress and URL parsing

Even before networking starts, a lot happens:

1. The keyboard sends key events to the operating system, which delivers them to the focused browser window.
2. As you type, the browser's address bar (Chrome calls it the omnibox) suggests completions from history, bookmarks and, if enabled, a search provider. It may even preconnect or prefetch a likely destination before you press Enter.
3. When you press Enter, the browser decides: is this a URL or a search query? example.com/products?id=7 has a dot and a valid-looking host, so it is a URL. how does dns work has spaces and no host, so it becomes a search on the default engine.
4. The browser normalises the input into a full URL. With no scheme typed, modern browsers try https:// first (Chrome has done this by default since version 90; older behaviour was to try http://).

The URL is then split into parts:

https://example.com:443/products?id=7
\___/   \_________/ \_/\_______/ \__/
scheme     host     port  path   query

The port is implicit: 443 for https, 80 for http. Non-ASCII host names are converted to Punycode (for example bücher.example becomes xn--bcher-kva.example), and unsafe characters in the path are percent-encoded. Browsers display some Punycode names in their raw form to protect against homograph attacks, where a look-alike character (Cyrillic "а" for Latin "a") imitates a real domain.

Stage 2: HSTS

If the URL is http://, or the user typed a bare host, the browser checks its HSTS (HTTP Strict Transport Security) list. This list contains:

• Sites that previously sent a Strict-Transport-Security header, remembered for their max-age.
• The HSTS preload list compiled into the browser.

If the host is on the list, the browser rewrites the URL to https:// internally (Chrome shows this as a "307 Internal Redirect" in DevTools) without ever sending a plain-HTTP request. This defeats SSL-stripping attacks, as explained in the TLS and network security lesson.

If the host is not on any list and the user explicitly typed http://, the browser sends a plain request, and the server typically answers 301 Moved Permanently to the HTTPS URL, costing an extra round trip.

Stage 3: checking caches before touching the network

The fastest network request is the one you never make. The browser checks, in roughly this order:

1. Service worker. If the site registered a service worker (a script that acts as a programmable proxy inside the browser), it gets the first chance to answer the request, perhaps from its own offline cache.
2. HTTP cache (memory cache, then disk cache). If a fresh copy of /products?id=7 exists (within its Cache-Control: max-age), it is used immediately with no network at all. If it is stale but has an ETag, the browser will send a conditional request later. (Details in the HTTP lesson.)
3. Existing connections. If the browser already has an open, idle connection to example.com (from a tab opened earlier), it can skip DNS, TCP and TLS entirely and jump to stage 8.

For a main HTML page, most sites send Cache-Control: no-cache or a short max-age, so the browser usually goes to the network for the document, while CSS, JS and images are often served from cache.

For the rest of this lesson, assume nothing is cached and there is no open connection: the slowest, most complete path.

Stage 4: DNS resolution

The browser has a host name but needs an IP address. The full mechanism is in the DNS lesson; here is the chain as it applies to this request.

1. Browser DNS cache. Chrome keeps its own short-lived host cache.
2. Operating system. The browser asks the OS resolver (getaddrinfo on Linux and macOS). The OS checks its cache and the hosts file (/etc/hosts).
3. Recursive resolver. On a miss, the OS's stub resolver sends a query over UDP port 53 to the resolver configured by DHCP, usually the home router (which forwards to the ISP) or a public resolver such as 1.1.1.1. If the browser has DNS over HTTPS enabled, it may instead send the query encrypted to a DoH resolver.
4. Iterative resolution. If the resolver has nothing cached, it asks a root server (referral to .com), a .com TLD server (referral to example.com's authoritative name servers), then the authoritative server.
5. Answer. For a site behind a CDN, the authoritative answer is often a CNAME to the CDN's host name (example.com.cdn-provider.net), which the CDN's own DNS resolves to the IP of an edge server near you, chosen by your resolver's location or anycast.

The browser typically asks for both A (IPv4) and AAAA (IPv6) records in parallel and, with Happy Eyeballs, races connections over both, preferring IPv6 slightly.

Every layer caches the answer for its TTL, so the next visit skips most of this. A cold lookup might take 20 to 100 ms or more; a cached one takes under a millisecond.

Stage 5: ARP and getting the first packet out

Now the browser knows the server's IP, say 203.0.113.10. Your laptop is at 192.168.1.23 on the home network 192.168.1.0/24.

The OS checks its routing table: is 203.0.113.10 on my local subnet? No. So the packet must go to the default gateway, the home router at 192.168.1.1. (Routing tables and subnet checks are covered in the IP addressing and routing lessons.)

To put a frame on the Wi-Fi or Ethernet link, the laptop needs the router's MAC address (the hardware address used by the data link layer). It checks its ARP cache. If empty:

Laptop -> broadcast (ff:ff:ff:ff:ff:ff):
   "Who has 192.168.1.1? Tell 192.168.1.23"
Router -> laptop (unicast):
   "192.168.1.1 is at 3c:84:6a:12:34:56"

The laptop caches this mapping for a few minutes. Note the key point: the IP destination of every packet is the server (203.0.113.10), but the MAC destination of the frame is the router. At each hop, the IP header stays the same (apart from TTL decrement and checksum) while the link-layer header is rewritten. ARP details are in the data link layer lesson.

Along the way:

• The home router performs NAT (network address translation): it rewrites the private source address 192.168.1.23:52144 to its public address, say 49.36.12.8:61002, and remembers the mapping so replies can be sent back to the laptop.
• The packet travels through the ISP's network and across the Internet. Routers forward it hop by hop using their routing tables, and between networks (autonomous systems) the paths are chosen by BGP.

Stage 6: the TCP three-way handshake

HTTP/1.1 and HTTP/2 run over TCP, so the browser opens a TCP connection to 203.0.113.10:443. (If the browser already knows the site supports HTTP/3, it may try QUIC over UDP instead; see the end of this section.)

Laptop (client)                         Server / CDN edge
    |--- SYN, seq=x ------------------------->|   "I want to connect"
    |<-- SYN-ACK, seq=y, ack=x+1 -------------|   "OK, me too"
    |--- ACK, ack=y+1 ----------------------->|   "Confirmed"
    |        connection ESTABLISHED           |

1. The client picks a random initial sequence number and sends a SYN segment. The OS chooses an ephemeral source port (like 52144).
2. The server replies SYN-ACK with its own initial sequence number, acknowledging the client's.
3. The client sends ACK. The connection is established.

During the handshake, both sides also exchange options: MSS (maximum segment size), window scaling and SACK support. This costs one round trip (RTT). The connection then starts in slow start, sending a small initial congestion window (commonly 10 segments, about 14 KB) and growing it as acknowledgements arrive. That is why the first bytes of a page matter so much for speed. See the transport layer and congestion control lessons.

If the browser uses HTTP/3, there is no TCP: QUIC over UDP combines the transport and TLS handshakes into a single round trip.

Stage 7: the TLS handshake

On top of TCP, the browser and server run a TLS 1.3 handshake (detailed in the TLS lesson):

1. ClientHello: supported cipher suites, a key share (ephemeral elliptic-curve DH public value), the SNI extension naming example.com (so a server or CDN hosting thousands of sites knows which certificate to present), and ALPN listing h2 and http/1.1.
2. ServerHello with the server's key share. Both sides derive session keys.
3. The server sends, encrypted: its certificate chain, a CertificateVerify signature proving it holds the private key, and Finished. ALPN result: h2.
4. The browser validates the certificate: chain to a trusted root, host name matches a Subject Alternative Name, dates valid, not revoked, Certificate Transparency proofs present. If anything fails, the user sees a full-page warning and nothing else happens.
5. The browser sends Finished.

TLS 1.3 costs one RTT (TLS 1.2 costs two). With a CDN, this handshake is with the edge server a few milliseconds away, not with the origin data centre, which is a big part of why CDNs speed up even uncacheable pages.

Running total for a new connection with TLS 1.3 over TCP: DNS + 1 RTT (TCP) + 1 RTT (TLS) before the request can be sent.

Stage 8: sending the HTTP request

Now the browser sends the request, encrypted inside TLS. Over HTTP/2 the request is binary frames with HPACK-compressed headers, but logically it is:

GET /products?id=7 HTTP/2
:authority: example.com
:scheme: https
user-agent: Mozilla/5.0 (...) Chrome/...
accept: text/html,application/xhtml+xml,...
accept-encoding: gzip, deflate, br, zstd
accept-language: en-IN,en;q=0.9
cookie: session_id=k8f2Lq9x; theme=dark
sec-fetch-mode: navigate

Things worth mentioning:

• Cookies for example.com are attached automatically, subject to their Domain, Path, Secure and SameSite attributes. That is how the server knows you are logged in.
• Accept-Encoding advertises compression the browser understands.
• :authority in HTTP/2 plays the role of the HTTP/1.1 Host header.
• If the browser had a stale cached copy, it would add If-None-Match with the ETag.

Stage 9: CDN, load balancer and reverse proxy

The request rarely lands directly on the application. A typical production path:

Browser
   |  (TLS terminated here)
   v
CDN edge (nearest city)  --- cache hit? ---> respond immediately
   |  miss / dynamic page
   v
Cloud load balancer (L7) at the origin region
   |  picks a healthy instance; adds X-Forwarded-For
   v
Reverse proxy (e.g. Nginx) on or near the app host
   |  compression, static files, timeouts, rate limits
   v
Application server (e.g. Java, Go, Node, Python)

• CDN edge. The edge terminates TLS, checks its cache for this URL, and serves cacheable content (images, scripts, sometimes whole HTML pages) directly. For a miss or a dynamic page, it forwards the request to the origin over a pre-warmed, persistent connection, which is faster than the user's own cold connection would be. The edge may also apply a WAF and DDoS filtering.
• Load balancer. Distributes requests across healthy application servers using an algorithm such as round robin or least connections, removing servers that fail health checks. An L7 load balancer can route by path (/api to one pool, /images to another). See the modern networking lesson and load balancing.
• Reverse proxy. Often Nginx or Envoy in front of the app process: buffering slow clients, serving static files, enforcing timeouts.

Each hop adds headers such as X-Forwarded-For (the original client IP) and X-Forwarded-Proto: https, so the application knows who really called it.

Stage 10: server-side processing

The application server receives GET /products?id=7:

1. Routing: the web framework matches the path to a handler.
2. Middleware: logging, request id, authentication (look up session_id in Redis, or verify a JWT), rate limiting.
3. Business logic: fetch product 7. Check an in-memory or Redis cache first; on a miss, query the database (SELECT ... FROM products WHERE id = 7), possibly a read replica, and populate the cache.
4. Calls to other services: price, inventory, recommendations, perhaps in parallel over internal HTTP or gRPC.
5. Render: produce HTML (server-side rendering with templates or a framework) or JSON for a client-side app.
6. Response headers: Content-Type, Cache-Control, Set-Cookie, security headers such as Content-Security-Policy and Strict-Transport-Security.

This step can range from a millisecond (cached) to seconds (slow queries), and in practice it is often the largest part of time to first byte (TTFB).

Stage 11: the response travels back

HTTP/2 200
content-type: text/html; charset=utf-8
content-encoding: br
cache-control: private, no-cache
etag: "p7-v42"
set-cookie: last_viewed=7; Path=/; Secure; HttpOnly; SameSite=Lax
strict-transport-security: max-age=31536000; includeSubDomains

<!doctype html><html>...

The response is compressed (Brotli here), split into TCP segments, encrypted into TLS records, and sent back along the reverse path: app, proxy, load balancer, CDN edge (which may cache it if allowed), the Internet, your router (which reverses the NAT mapping), and your laptop's network card. The OS reassembles the TCP stream, TLS decrypts it, and the browser's network stack hands HTTP data to the renderer.

The browser begins processing HTML as it streams in; it does not wait for the whole body.

Stage 12: parsing HTML, CSS and JavaScript

Modern browsers use separate processes: a browser process (UI, networking) and a sandboxed renderer process per site, for security and stability. The renderer turns bytes into pixels through the critical rendering path.

Building the DOM

1. Decode bytes to characters using the declared charset (UTF-8).
2. Tokenise: the HTML parser turns characters into tokens: start tags, end tags, text.
3. Build the DOM (Document Object Model): a tree of nodes representing the document. The HTML parser is very forgiving and fixes broken markup.

Document
 └─ html
     ├─ head
     │   ├─ link (stylesheet: /app.css)
     │   └─ script (/app.js, defer)
     └─ body
         ├─ h1 "Trail Running Shoes"
         ├─ img (/img/shoe7.webp)
         └─ div.price "Rs 4,999"

A preload scanner runs ahead of the main parser and starts downloading resources it sees (<link>, <script>, <img>) early, even while the parser is blocked.

Building the CSSOM

CSS is parsed into the CSSOM (CSS Object Model), a tree of style rules. CSS is render-blocking: the browser will not paint content until the stylesheets in <head> have loaded, to avoid a flash of unstyled content.

JavaScript

A plain <script src> is parser-blocking: the HTML parser stops, downloads and runs the script, then continues, because the script might modify the document. Two attributes change this:

JavaScript runs on the main thread, the same thread that does layout and paint. Long-running scripts delay rendering and make the page unresponsive to input.

Stage 13: render tree, layout, paint, composite

Once the DOM and CSSOM are ready:

 DOM  +  CSSOM
   \      /
    v    v
  Render tree   (only visible nodes, with computed styles;
      |          display:none elements are excluded)
      v
   Layout       (a.k.a. reflow: compute each box's exact
      |          position and size for this viewport)
      v
   Paint        (record drawing commands: text, colours,
      |          borders, images, into layers)
      v
  Composite     (GPU combines layers into the final frame;
                 transforms and opacity animate cheaply here)

1. Style calculation: match CSS rules to each element and compute final values.
2. Render tree: combine DOM and computed styles, keeping only visible elements.
3. Layout (reflow): compute geometry. Changing an element's width, or reading layout properties like offsetHeight after a style change, can force layout again.
4. Paint: turn boxes into drawing instructions, split into layers.
5. Composite: the compositor thread and GPU combine layers into the image on screen. Animations of transform and opacity can run here without repeating layout or paint, which is why they are smooth.

Key moments users and tools measure:

• First Contentful Paint (FCP): first text or image appears.
• Largest Contentful Paint (LCP): the main content (perhaps the product image) appears.
• DOMContentLoaded: HTML fully parsed and deferred scripts run.
• load: all sub-resources including images finished.

Stage 14: sub-resources and connection reuse

The HTML references other resources: app.css, app.js, images, fonts, perhaps API calls made by JavaScript. For each:

• Same origin (example.com): with HTTP/2 or HTTP/3, requests are multiplexed over the connection already open. No new DNS, TCP or TLS cost.
• Other origins (a font CDN, analytics, api.example.com): each new host needs its own DNS lookup and connection, unless the page hinted <link rel="preconnect"> to do these early. HTTP/2 can coalesce connections for different host names if they resolve to the same IP and share a certificate.
• Cached resources are reused without network, or revalidated with 304 responses.

After the page loads, the connection stays open (keep-alive) for a while so that clicks and API calls are fast. TLS session tickets let a later connection resume with fewer round trips, and the browser keeps its DNS and HTTP caches for the next visit.

The complete timeline

Assume a round-trip time (RTT) of 40 ms to the CDN edge, a cold DNS lookup, TLS 1.3 over TCP, and a dynamic page the edge must fetch from origin. The numbers are illustrative; only the ordering and the RTT counting are the point.

time (ms)  0    40   80   120  160  200  240  280  320  360
           |----|----|----|----|----|----|----|----|----|
URL parse  #
HSTS/cache #
DNS        ######                 (cold: ~60 ms, cached: ~0)
ARP         (gateway MAC usually already cached)
TCP              ########         1 RTT  (60 -> 100)
TLS 1.3                  ######## 1 RTT  (100 -> 140)
HTTP req                         >        sent at ~140
edge->origin->app                ######## (~80 ms, incl. DB)
first byte                               < TTFB ~260
HTML stream                              ####
parse/CSS/JS                               ######
first paint                                       * FCP ~330

The same story as a sequence:

Browser       Resolver     CDN edge        Origin/app      DB
   |--DNS q----->|              |               |            |
   |<--A record--|              |               |            |
   |--SYN----------------------->|              |            |
   |<--SYN-ACK-------------------|              |            |
   |--ACK + ClientHello--------->|              |            |
   |<--ServerHello, cert, Fin----|              |            |
   |--Finished + GET /products-->|              |            |
   |                             |--GET (warm)->|            |
   |                             |              |--SELECT--->|
   |                             |              |<--row------|
   |                             |<--200 HTML---|            |
   |<--200 HTML (streamed)-------|              |            |
   |--GET app.css, app.js, img (multiplexed)--->|            |
   |<--from edge cache----------|               |            |

Notice that the ACK of the TCP handshake and the ClientHello go in the same flight, so TCP plus TLS 1.3 costs two round trips in total before the GET is sent.

Counting round trips: worked example

Question: with RTT = 50 ms, DNS already cached, how long before the first byte of HTML arrives, assuming the server takes 30 ms to respond?

This table makes the case for CDNs (smaller RTT), TLS 1.3 and HTTP/3 (fewer round trips), and connection reuse (zero handshakes) in a few lines.

Tailoring the answer

The interviewer usually wants either a crisp overview or a deep dive into one area. Read the signal: if they say "briefly", give the short version; if they keep asking "and then?", expand.

The two-minute version

Say something like this, in order:

"The browser parses the URL and, since HSTS or the default prefers it, uses HTTPS. It checks its caches; assuming a miss, it resolves the host name through DNS: browser cache, OS cache, then a recursive resolver that walks root, TLD and authoritative servers and returns the IP, often a CDN edge. The OS sends packets via the default gateway, using ARP to find the router's MAC. The browser opens a TCP connection with a three-way handshake, then a TLS handshake where it validates the certificate and agrees on keys. It sends an HTTP GET with headers and cookies. The request passes through the CDN, a load balancer and a reverse proxy to an application server, which runs the logic, hits caches and the database, and returns HTML. The browser parses HTML into the DOM and CSS into the CSSOM, runs JavaScript, builds the render tree, lays it out, paints and composites it to the screen, and fetches sub-resources over the same connection."

That is about 150 words and touches every layer. End by offering: "I can go deeper into any of these steps."

The fifteen-minute version

Use the stages in this lesson, and in each one add one layer of "why" and one trade-off:

1. URL and HSTS (1 minute): omnibox decision, scheme defaulting, Punycode, HSTS and preload, SSL stripping.
2. Caches (1 minute): service worker, HTTP cache freshness versus revalidation, connection reuse.
3. DNS (2 to 3 minutes): recursive versus iterative, TTL and caching, CNAME to CDN, GeoDNS or anycast, DoH, UDP versus TCP.
4. Local network (1 to 2 minutes): routing table decision, ARP, NAT at the home router, BGP between networks.
5. TCP (2 minutes): handshake, sequence numbers, MSS, slow start and why the first 14 KB matters.
6. TLS (2 minutes): TLS 1.3 handshake, certificate chain validation, SNI and ALPN, forward secrecy.
7. HTTP (1 to 2 minutes): request anatomy, cookies, HTTP/2 multiplexing, HTTP/3 and QUIC.
8. Server side (2 minutes): CDN edge, L7 load balancer, reverse proxy, app, cache, database, response headers.
9. Rendering (2 to 3 minutes): DOM and CSSOM, render-blocking CSS, parser-blocking JS with async and defer, layout, paint, composite, FCP and LCP.
10. Afterwards (1 minute): sub-resources, keep-alive, session resumption, prefetching.

Tailor to the role: a backend interview should spend extra time on stages 9 and 10 (load balancing, caching, database, timeouts); a frontend interview on stages 12 to 14 (critical rendering path, Core Web Vitals); a networking or SRE interview on stages 4 to 7 (DNS, routing, TCP, TLS).

Likely follow-up questions

Interviewers often interrupt with one of these. Short answers:

• "What if the DNS lookup fails?" The resolver returns NXDOMAIN or SERVFAIL, or times out; the browser shows a "site can't be reached" error such as DNS_PROBE_FINISHED_NXDOMAIN.
• "What if the certificate is invalid?" The browser aborts before sending any HTTP and shows an interstitial warning; HSTS sites do not even allow clicking through.
• "How does the packet find its way across the Internet?" Hop-by-hop forwarding using routing tables; longest prefix match; BGP between autonomous systems; TTL prevents loops.
• "Where does the IP of your laptop come from?" DHCP from the router, which also provided the gateway and DNS server addresses.
• "Why is the second visit faster?" Cached DNS, cached static assets, possibly an open connection or TLS session resumption, warm server caches.
• "What does the CDN actually save?" Lower RTT for handshakes, cached static (and sometimes dynamic) content served from the edge, warm connections to origin, and absorbed traffic spikes.

Interview questions

Q1. What happens when you type a URL and press Enter? Give the short version.

The browser parses the URL, applies HSTS, checks caches, resolves the host via DNS, sends packets through the default gateway (found via ARP), opens a TCP connection and performs a TLS handshake, then sends the HTTP request. The request passes through a CDN, load balancer and reverse proxy to the application, which returns HTML. The browser builds the DOM and CSSOM, runs JavaScript, lays out, paints and composites the page, and fetches sub-resources over the same connection.

Q2. Why does the browser need ARP if it already has the server's IP address?

IP addresses are used end to end, but each link delivers frames using MAC addresses. The server is not on the local network, so the laptop must send the frame to its default gateway, and ARP finds the gateway's MAC address. Each router along the way repeats this for its next hop.

Q3. How many round trips does it take before the first HTTP request is sent?

With DNS cached and a new connection: TCP plus TLS 1.2 takes three round trips, TCP plus TLS 1.3 takes two, and HTTP/3 over QUIC takes one. A resumed QUIC connection with 0-RTT, or an already open connection, sends the request immediately.

Q4. What is HSTS and where does it fit in this flow?

HSTS is a policy telling the browser to use only HTTPS for a host. The browser checks it before any network activity and internally rewrites http:// to https://, preventing SSL-stripping attacks. Preloaded sites are protected even on the first visit.

Q5. Why does a CDN make even a non-cacheable page faster?

The TCP and TLS handshakes happen with a nearby edge, so they cost a few milliseconds instead of a long round trip to the origin. The edge forwards the request over an already-warm, persistent connection to the origin, avoiding a cold handshake and slow start on the long path.

Q6. What is the critical rendering path?

The sequence the browser follows to turn HTML, CSS and JavaScript into pixels: build the DOM and CSSOM, combine them into the render tree, compute layout, paint and composite. Optimising it means minimising render-blocking CSS and parser-blocking JavaScript and delivering critical content early.

Q7. What is the difference between async and defer on a script tag?

Both download the script in parallel with HTML parsing. async executes as soon as the download finishes, in any order, briefly pausing the parser. defer executes after parsing completes, in document order, before DOMContentLoaded.

Q8. What is the difference between layout and paint?

Layout (reflow) computes the position and size of every element. Paint turns those boxes into drawing commands for pixels. Changes to geometry trigger layout and paint; changes to colour only trigger paint; transforms and opacity can be handled by the compositor alone.

Q9. How does the server know who you are?

The browser automatically attaches cookies for the domain, such as a session id, or the frontend adds an Authorization header with a token. The server looks up the session or verifies the token's signature.

Q10. What changes on the second visit to the same site?

DNS answers are cached, static assets are served from the HTTP cache or revalidated with 304, the connection may still be open or TLS can resume, and HSTS is remembered. Server-side caches are also likely warm, so the page loads much faster.

Q11. Where does NAT happen in this flow, and why?

At the home router: the laptop's private IP and port are rewritten to the router's public IP and a port, and the mapping is stored so replies can be forwarded back. It exists because private addresses are not routable on the Internet and IPv4 addresses are scarce.

Q12. What happens if the server is slow to respond?

The browser waits, showing a loading state; proxies along the way have their own timeouts, and a load balancer may return 504 Gateway Timeout if the application does not respond in time. A good debugging step is to measure DNS, connect, TLS and TTFB separately with curl -w to locate the delay.

Key takeaways

• Tell the story in order: URL, HSTS, caches, DNS, ARP and routing, TCP, TLS, HTTP, edge and load balancer, server, response, rendering, sub-resources.
• Caches at every layer (DNS, HTTP, connections, TLS sessions) skip whole stages; mention them.
• ARP finds the gateway's MAC, not the server's. NAT at the router maps private to public addresses.
• New connection cost: TCP 1 RTT + TLS 1.3 1 RTT (TLS 1.2: 2 RTT); QUIC combines them into 1 RTT.
• CDNs cut RTT and serve cached content; load balancers and reverse proxies route to healthy app servers.
• Rendering: DOM + CSSOM, render tree, layout, paint, composite. CSS blocks rendering; plain scripts block parsing.
• Keep one concrete example, give the two-minute overview first, then expand where the interviewer leads, weighted to the role.

Next lesson

Continue with Application protocols.