Putting It Together: A Complete Web Request

This chapter synthesises everything we've covered. You type https://www.example.com/index.html into a browser and press Enter. Here is what happens — at every layer — from keystroke to rendered page. This is one of the most commonly asked technical interview questions in networking, and understanding it deeply means you genuinely understand how the internet works.

Starting conditions (assumed)

• Your laptop: IP 192.168.1.50, subnet /24, default gateway 192.168.1.1, DNS server 8.8.8.8.
• All ARP caches are empty, all DNS caches are empty.
• www.example.com resolves to 203.0.113.10 — an illustrative address from RFC 5737 TEST-NET-3 (documentation range, not a real server).

Step 0: Bootstrapping and host configuration (DHCP)

Before your browser can execute any DNS lookup or open a TCP socket, your computer must first acquire an identity on the local network. In technical discussions, engineers often assume that the client already has an IP address, default gateway, and DNS server. Here is what happens in the seconds prior when you connect an Ethernet cable or associate with a Wi-Fi network:

1. Link-layer establishment: The physical link activates (Ethernet pulses detect carrier, or the Wi-Fi radio completes 802.11 association and the 4-way WPA2/WPA3 handshake). The network interface enters the UP state, but has no IP address assigned (0.0.0.0).
2. DHCPDISCOVER (Broadcast): The operating system's DHCP client broadcasts a request looking for any available DHCP server:
   • Transport: UDP datagram with source port 68 (bootpc) → destination port 67 (bootps).
   • Network: IPv4 packet with source IP 0.0.0.0 → limited broadcast destination 255.255.255.255.
   • Link: Ethernet frame with source MAC = laptop MAC → broadcast destination FF:FF:FF:FF:FF:FF.
3. DHCPOFFER: The DHCP server (running on the local home router at 192.168.1.1) receives the broadcast and selects an available IP from its pool:
   • Offered IP: 192.168.1.50
   • Subnet mask: 255.255.255.0 (/24)
   • Default gateway (Router): 192.168.1.1
   • DNS resolver: 8.8.8.8
   • Lease duration: 86,400 seconds (24 hours)
4. DHCPREQUEST (Broadcast): The laptop broadcasts acceptance: "I accept the offer from server 192.168.1.1 for IP 192.168.1.50." This is broadcast so that any other DHCP servers on the subnet know their tentative offers were declined and can release reserved IPs.
5. DHCPACK (Unicast/Broadcast): The router confirms the lease and registers the client's hostname and MAC address.
6. Duplicate Address Detection (DAD) via Gratuitous ARP: Before binding the address, the laptop broadcasts a Gratuitous ARP request asking "Who has 192.168.1.50?". If no station replies within a short timeout, the IP is guaranteed unique on the local link.

The operating system binds 192.168.1.50/24 to the interface, installs a default route 0.0.0.0/0 via 192.168.1.1 in its kernel routing table, and writes nameserver 8.8.8.8 to /etc/resolv.conf. The laptop is now completely bootstrapped and ready to resolve names.

Step 1: DNS resolution

The browser needs an IP address for www.example.com.

1. Browser checks its DNS cache: empty.
2. OS checks its DNS cache and /etc/hosts: empty.
3. OS sends a DNS query (UDP, source port ~54000, destination 8.8.8.8:53) via the IP stack.
4. IP layer decision: 8.8.8.8 is not on the local /24 → route to default gateway 192.168.1.1.
5. ARP lookup: no ARP entry for 192.168.1.1 → broadcast ARP request on the LAN. The gateway replies with its MAC, e.g. aa:bb:cc:11:22:33.
6. Link layer: DNS query is wrapped: UDP segment → IP packet (src:192.168.1.50, dst:8.8.8.8) → Ethernet frame (src: laptop MAC, dst: gateway MAC). Sent to switch → switch forwards to gateway port → gateway forwards toward 8.8.8.8.
7. 8.8.8.8 performs recursive resolution (root → .com TLD → example.com authoritative) and returns: A record 203.0.113.10 (illustrative), TTL 3600.
8. DNS response arrives, OS caches it, browser caches it.

Time taken: typically 10–50 ms for a cold DNS lookup; <1 ms if cached.

Step 2: TCP connection to port 443

With 203.0.113.10 (our illustrative server IP) known, the browser opens a TCP connection to port 443:

1. IP routing decision: 203.0.113.10 is not on the local /24 → send to default gateway 192.168.1.1.
2. ARP: gateway's MAC is already in cache from step 1 — no new ARP needed.
3. SYN: browser sends TCP SYN, src port ~54321 (ephemeral), dst port 443. The IP packet has src 192.168.1.50 and dst 203.0.113.10.
4. NAT at the gateway: home router translates 192.168.1.50:54321 → public IP (e.g. 1.2.3.4):40001. Enters this mapping in its NAT table.
5. Internet routing: packets traverse multiple ISP routers; routing tables determine the path; each router decrements TTL and forwards based on longest prefix match. MACs change at every hop; IP addresses stay constant.
6. SYN-ACK: server responds. NAT router translates dst 1.2.3.4:40001 back to 192.168.1.50:54321. Browser receives SYN-ACK.
7. ACK: browser sends ACK. TCP connection ESTABLISHED.

Time taken: one RTT for the handshake. London→New York ≈ 80 ms RTT.

Step 3: TLS 1.3 handshake

Because the URL is HTTPS, the browser now negotiates TLS over the established TCP connection:

1. ClientHello: browser sends supported cipher suites, TLS version 1.3, client random, ECDH key share (X25519 public key).
2. ServerHello + {Certificate + CertificateVerify + Finished}: server selects cipher suite, sends its certificate chain and its ECDH public key. Both sides independently compute the shared secret and derive the same session keys (HKDF).
3. Browser verifies the certificate: checks it was signed by a trusted CA (from the OS/browser trust store), checks the hostname matches, checks it's not expired or revoked (OCSP stapling or CRL).
4. Client Finished: browser confirms. Encrypted channel is open.

Time taken: 1 RTT (TLS 1.3). Total so far: DNS + TCP handshake + TLS handshake = roughly 3 RTTs from a cold start.

Step 4: HTTP/2 request

:method: GET
:path: /index.html
:scheme: https
:authority: www.example.com
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.5
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) …

This HTTP/2 HEADERS frame is encrypted inside the TLS record, which is a TCP segment, which is an IP packet, which is an Ethernet frame — four layers of encapsulation over the wire.

Step 5: Server response and page rendering

1. Server decrypts the TLS record, parses the HTTP/2 HEADERS frame, reads the request.
2. Server reads /index.html from disk or cache.
3. Server sends back HTTP/2 HEADERS (status 200, content-type: text/html, content-encoding: br) + DATA frames with brotli-compressed HTML body.
4. Browser decompresses, parses HTML, builds the DOM.
5. HTML references CSS, JavaScript, images. Browser fires additional requests — each resource may be a new HTTP/2 stream on the same TLS+TCP connection (or a new QUIC stream on HTTP/3). Some resources may come from other origins (CDN, fonts, analytics), requiring new DNS+TCP+TLS for each distinct hostname.
6. As JavaScript loads, it may fire XHR or fetch() calls for API data — more HTTP requests over the same or new connections.
7. Eventually the Critical Rendering Path completes: DOM + CSSOM → Render Tree → Layout → Paint. Page appears.

Layer summary: one GET request end-to-end

Complete packet trace: Exact MAC, IP, and Port headers at every stage

Consider the journey of a client retrieving https://www.example.com. The client is a Laptop (IP: 192.168.1.50, MAC: MAC_L) connected to a Home Router (LAN IP: 192.168.1.1, LAN MAC: MAC_R_LAN; Public WAN IP: 198.51.100.1, WAN MAC: MAC_R_WAN). The ISP next-hop router has MAC MAC_ISP, the recursive DNS server is 8.8.8.8, and the web server is 203.0.113.10:

Common things that can go wrong