What Really Happens When You Load a Web Page? A Deep Dive into DNS, ARP, TCP, and HTTP

Overview

The article illustrates the end‑to‑end network flow that occurs when a user types maps.google.com into a web browser and presses Enter, covering DNS resolution, ARP address discovery, TCP connection establishment, HTTP request/response exchange, and final page rendering.

DNS Cache Lookup

Before issuing a DNS query, the resolver checks four possible caches in order:

Browser cache – DNS records stored by the browser itself.

Operating‑system cache – e.g., getHostName on Windows; on Linux a cache exists only if the nscd service is installed.

Router cache – the local router may retain recent DNS answers.

ISP cache – the recursive resolver operated by the ISP may already have the record.

If none of these caches contain the answer, a DNS query is sent.

Why DNS Uses Multiple Servers

DNS is a globally distributed database. A single server cannot store mappings for every host, and early centralized designs suffered from single‑point‑of‑failure, limited capacity, high latency, and high maintenance cost. Modern DNS uses a hierarchical, distributed architecture consisting of: Root DNS servers – over 400 servers worldwide that point to TLD servers. Top‑Level Domain (TLD) servers – serve zones such as .com, .org, country‑code TLDs, etc. Authoritative DNS servers – hold the actual records for a domain (e.g., google.com).

DNS Query Types

Recursive query : the resolver contacts other servers on behalf of the client until it obtains the final answer.

Iterative query : the server returns a referral to a lower‑level server; the client follows the chain.

Non‑recursive query : the server answers from its own cache or authoritative data without further lookups.

ARP Request

If the DNS server’s IP address resides on the same subnet as the host, the host sends an ARP request to discover the server’s MAC address; otherwise it ARPs the default gateway. ARP maps an IP address to a MAC address using a broadcast request and a unicast reply, and the result is stored in an ARP cache with a timeout.

TCP Three‑Way Handshake

After DNS and ARP have resolved the server’s IP and MAC, the browser establishes a TCP connection (port 80 for HTTP or 443 for HTTPS). The handshake proceeds as follows:

Server listens ( LISTEN) for incoming connections.

Client sends a SYN packet ( SYN‑SEND).

Server replies with SYN‑ACK and moves to SYN‑RECEIVED.

Client acknowledges with ACK and enters ESTABLISHED.

Server also enters ESTABLISHED, completing the connection.

HTTP Request

With the TCP connection open, the browser sends an HTTP request. The most common methods are: GET – retrieve a resource. POST – submit data to the server.

Typical request headers include: Host – target host name. Connection: close – request a non‑persistent connection. User-Agent: Mozilla/5.0 – identifies the client software. Accept-Language: fr – preferred language (if supported).

Server Response

The web server (e.g., Apache, Nginx) processes the request via a backend handler written in .NET, PHP, Ruby, etc., and returns an HTTP response containing:

Status code (e.g., 200 OK).

Headers such as Content-Encoding, Cache-Control, Set-Cookie, etc.

The HTML body of the requested page.

Browser Rendering

The browser parses the HTML, renders the initial skeleton, and then fetches additional resources (images, CSS, JavaScript) as needed, often from its cache. Once all resources are available, the complete page – in this example the Google Maps interface – is displayed.

Reference : https://github.com/skyline75489/what-happens-when-zh_CN#dns