What Happens When You Type a URL in the Browser

Difficulty: Advanced

Question

What happens, end to end, when you type https://www.example.com into your browser and press Enter?

Answer

This is the grand finale of networking interviews because it touches almost everything: parsing, caching, DNS, TCP, TLS, HTTP, servers, rendering. The trick to a great answer is to structure it into phases, state the key protocol in each, and mention where caching short-circuits the work. Let's walk through it in order.

Phase one, the browser parses the input. It decides whether this is a URL or a search query, extracts the scheme (https), host (www.example.com), port (default 443) and path. It checks HSTS lists that force HTTPS, checks the browser cache and service workers, and if a fresh cached copy exists it may not need the network at all.

Phase two, DNS resolution. The browser needs an IP. It checks its own DNS cache, then the OS cache and the hosts file, then asks the configured recursive resolver (from DHCP or set manually, like 8.8.8.8). On a miss, the resolver walks root, .com TLD, and the authoritative server, and returns an A or AAAA record with a TTL. Typically 20 to 100 ms, or zero if cached.

Phase three, getting to the machine. The OS decides whether the destination is on the local subnet. It is not, so the frame is addressed to the default gateway, whose MAC is learned via ARP. Packets then hop router to router using longest prefix match, with the MAC rewritten at each hop; NAT on your home router rewrites your private source IP to the public one.

Phase four, TCP connection. The client sends SYN, the server replies SYN-ACK, the client sends ACK: one round trip. Both sides agree on sequence numbers and options. The server's edge may be an anycast address of a CDN, so you land on a nearby PoP.

Phase five, TLS handshake. Over the TCP connection, the client sends ClientHello with SNI (www.example.com) and ALPN (h2, http/1.1). The server sends its certificate chain and key share; the browser validates the chain against trusted roots, the hostname and dates. Keys are derived using ECDHE; with TLS 1.3 this takes one extra round trip, and session resumption may skip most of it. From here everything is encrypted with a symmetric key. If HTTP/3 is available, QUIC merges phases four and five into a single handshake.

Phase six, the HTTP request and response. The browser sends GET / with headers such as Host, User-Agent, Accept, Accept-Encoding and any cookies. The request may pass through a CDN, a WAF and a load balancer (TLS terminated, forwarded to an app server), the application may query a cache and database, and returns a response like 200 OK with Content-Type text/html, Content-Encoding gzip or br, and Cache-Control. The response can also be a 301 redirect to another URL, in which case the process repeats. TCP flow control and congestion control govern how fast the bytes arrive, starting with slow start.

Phase seven, rendering. The browser parses HTML into the DOM incrementally, and discovers CSS, JavaScript, images and fonts, each requiring more requests (reusing the connection with HTTP/2 multiplexing, and possibly other hostnames requiring new DNS and TLS). It builds the CSSOM, combines them into a render tree, performs layout (positions and sizes), paints layers, and composites them on the GPU. Scripts can block parsing unless marked async or defer. JavaScript frameworks may then fetch data from APIs and update the DOM. Load events fire and the connection stays open under keep-alive for reuse.

Good answers add the edge cases: what if DNS fails (NXDOMAIN or timeout), the certificate is invalid (a warning page), the server sends 503, or a proxy or VPN is configured. A strong closer is to say where you would measure: browser DevTools Network tab shows DNS, connect, SSL, TTFB and download times per request, which lets you pinpoint which phase is slow.

Code examples

Timing each phase with curl

$ curl -o /dev/null -s -w 'dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://www.example.com
dns:0.018 tcp:0.041 tls:0.089 ttfb:0.132 total:0.141

Values are cumulative seconds. DNS took 18 ms, TCP finished at 41 ms, TLS at 89 ms, first byte at 132 ms.

Key points

• Order: parse, cache, DNS, ARP and routing, TCP, TLS, HTTP, render.
• Caches can skip DNS, the connection or the whole request.
• HTTP/3 with QUIC merges TCP and TLS setup.
• DevTools and curl timing expose which phase is slow.

Concepts covered

DNS, TCP, TLS, HTTP, Browser Rendering