What Happens When You Type a URL (The Full Journey)

Step 1: The Browser Checks Its Cache

Before anything hits the network, your browser checks whether it already knows the answer. Browsers maintain several caches:

• DNS cache: Has the browser recently resolved this domain? If so, it already has the IP address.
• HTTP cache: Has the browser recently fetched this exact resource? If the server sent caching headers (like Cache-Control: max-age=3600), the browser might serve the page from its local cache without making a request at all.
• HSTS cache: Has this domain told the browser to always use HTTPS? If it’s in the HSTS list, the browser will upgrade the request to HTTPS before sending it, even if you typed http://.

If everything is cached and fresh, the page loads instantly from local storage. You’d see this as a “(from disk cache)” or “(from memory cache)” entry in your browser’s developer tools network tab. No network request at all.

Most of the time, though, at least the DNS lookup or the page itself needs fetching. So we continue.

Step 2: DNS Resolution

The browser needs to turn readthemanual.co.uk into an IP address. We covered this in detail in Part 2 of this series, so here’s the summary:

The browser asks the operating system, which checks /etc/hosts, then its own DNS cache, then sends a query to the configured DNS resolver (your ISP, or something like Cloudflare’s 1.1.1.1). The resolver walks the DNS hierarchy — root server, TLD server, authoritative server — and returns the IP address. This typically takes 10-50ms, or 0ms if it’s cached.

You can see exactly how long DNS takes for any request:

# Show DNS resolution time
dig readthemanual.co.uk | grep "Query time"

# Or use curl's detailed timing
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" https://readthemanual.co.uk

That curl command is one of the most useful troubleshooting tools you’ll ever learn. It breaks down exactly where time is being spent. If DNS takes 500ms but connect takes 20ms, you’ve got a DNS resolver problem, not a server problem.

Step 3: TCP Handshake — Establishing the Connection

With the IP address in hand, the browser needs to establish a connection to the server. The internet uses TCP (Transmission Control Protocol) for web traffic, and TCP requires a three-way handshake before any data can be exchanged.

The handshake exists because TCP is a reliable protocol — it guarantees that data arrives intact and in order. But to do that, both sides need to agree that they’re ready to communicate. The three-way handshake is that agreement:

1. SYN: Your computer sends a SYN (synchronise) packet to the server. “I want to talk to you. Here’s my starting sequence number.”

2. SYN-ACK: The server responds with a SYN-ACK. “I hear you. Here’s my starting sequence number, and I acknowledge yours.”

3. ACK: Your computer sends an ACK. “Acknowledged. We’re connected.”

This takes one round trip — your packet to the server and back. If the server is 10ms away, the handshake takes ~10ms. If it’s across the Atlantic (70ms), the handshake takes ~70ms. This is why server proximity matters and why CDNs exist — every round trip adds latency.

When the handshake fails — when you get a “connection refused” or “connection timed out” — the problem is at this layer. Either the server isn’t listening on the expected port, a firewall is blocking the connection, or the server is unreachable. telnet or nc (netcat) tests this directly:

# Test if a TCP connection can be established
nc -zv readthemanual.co.uk 443

# Or using telnet
telnet readthemanual.co.uk 443

Step 4: TLS Handshake — The Secret Handshake

Almost all web traffic today uses HTTPS, which means a TLS (Transport Layer Security) handshake happens on top of the TCP connection. This is where encryption is negotiated.

Think of it as a secret handshake before you start talking. Both sides need to agree on how to encrypt the conversation, and the server needs to prove it is who it claims to be.

1. Client Hello: Your browser sends a list of supported cipher suites (encryption algorithms) and a random number.

2. Server Hello: The server picks a cipher suite from the list, sends its SSL certificate (which contains its public key), and its own random number.

3. Certificate Verification: Your browser checks the certificate. Is it signed by a trusted Certificate Authority? Has it expired? Does the domain on the certificate match the domain you’re connecting to? If any check fails, you get the “Your connection is not private” warning.

4. Key Exchange: Using the server’s public key, your browser and the server negotiate a shared session key. From this point on, all communication is encrypted with this session key.

5. Finished: Both sides confirm the handshake succeeded. Encrypted communication begins.

This adds another round trip or two of latency. TLS 1.3 (the current version) optimised this to a single round trip, and supports “0-RTT resumption” for repeat connections — if you’ve connected to this server recently, the handshake can be skipped almost entirely.

You can examine the full TLS handshake with:

# Show the full TLS handshake and certificate chain
openssl s_client -connect readthemanual.co.uk:443 -showcerts

# Show just the certificate details
echo | openssl s_client -connect readthemanual.co.uk:443 2>/dev/null | openssl x509 -noout -text

Step 5: The HTTP Request

With a secure connection established, your browser sends the actual HTTP request. This is the first point where application-level data is exchanged. The request includes:

The request line: The method (GET, POST, etc.), the path (/from-arpanet-to-your-router), and the HTTP version.

Headers: Metadata about the request. These include:

• Host: readthemanual.co.uk — Which website you want (a single server might host hundreds of sites)
• User-Agent — What browser/OS you’re using
• Accept — What content types you can handle (HTML, JSON, images)
• Cookie — Any cookies previously set by this domain (session tokens, preferences)
• Accept-Encoding: gzip, br — Compression algorithms you support

Body: For GET requests, there’s typically no body. For POST requests (form submissions, API calls), the body contains the data being sent.

You can see the exact request your computer sends:

# Show the full HTTP request and response headers
curl -v https://readthemanual.co.uk/from-arpanet-to-your-router 2>&1 | head -30

# Lines starting with > are what you sent
# Lines starting with < are what the server returned

Step 6: The Journey Through the Internet

Your HTTP request, now encrypted inside TLS, inside TCP, inside IP, is sent as packets across the internet. We covered routing in Part 1 — each packet hops between routers, each router consulting its BGP-informed routing table to decide the next hop.

For a UK user accessing a Cloudflare-proxied site, the journey is typically short — Cloudflare has edge servers in London, Manchester, and other UK cities. Your packets might only traverse 3-5 hops within the UK before reaching a Cloudflare edge server. For a site hosted in the US without a CDN, you're looking at 15-20 hops and 70-100ms of latency as packets cross the Atlantic.

Use traceroute to see the actual path:

traceroute readthemanual.co.uk

# Or with more detail on Windows
tracert readthemanual.co.uk

# MTR combines traceroute with continuous ping for live diagnosis
mtr readthemanual.co.uk

Step 7: Load Balancer / Reverse Proxy

Your request rarely hits the application server directly. In most modern setups, it first arrives at a reverse proxy or load balancer. This is the front door — it receives all incoming requests and decides where to send them.

A reverse proxy does several things:

• SSL termination: It handles the TLS encryption so backend servers don't have to. The traffic between the proxy and the backend is often unencrypted (within a trusted private network).
• Request routing: Based on the Host header, the URL path, or other criteria, it routes the request to the correct backend service. One proxy can serve dozens of different applications.
• Load balancing: If multiple backend servers can handle the request, it distributes traffic across them — round robin, least connections, or more sophisticated algorithms.
• Caching: It might serve a cached copy of the response without even contacting the backend.
• Security: Rate limiting, WAF (Web Application Firewall) rules, DDoS mitigation — all handled here.

If you've followed our Nginx Proxy Manager guide, you've already built one of these. The same concept scales from a Raspberry Pi running Nginx to Cloudflare handling millions of requests per second. The principles are identical — the scale is different.

For ReadTheManual, Cloudflare acts as the reverse proxy. Your request hits Cloudflare's edge in the UK. If the page is in Cloudflare's cache, it returns it immediately — the origin server never sees the request. If not, Cloudflare forwards the request to the origin server, caches the response, and returns it to you.

Step 8: Server Processing

The request finally reaches the web server — Apache, Nginx, IIS, or whatever is running. The web server examines the request and does one of two things:

Static content: If the requested resource is a static file (an HTML page, an image, a CSS file), the web server reads it from disk and returns it. Fast and simple.

Dynamic content: If the request needs to be processed — a WordPress page, an API endpoint, a search query — the web server passes it to the application layer. PHP processes the WordPress template, queries the MySQL database for the post content, assembles the HTML, and hands it back to the web server to return.

This is where server performance matters. A database query that takes 500ms, a PHP process that consumes too much memory, an application that makes external API calls before responding — all of these show up as slow page loads. And when you're troubleshooting a slow site, you need to know which layer is slow. Is it DNS (Step 2)? Network latency (Step 6)? Or server processing (Step 8)?

The curl timing command from Step 2 separates these neatly. If time_namelookup and time_connect are fast but time_total is slow, the delay is server-side.

Step 9: The HTTP Response

The server sends back an HTTP response containing:

Status code: A three-digit number indicating what happened. The ones you'll see most:

Response headers: Caching directives (Cache-Control), content type (Content-Type: text/html), security headers (X-Frame-Options, Content-Security-Policy), cookies to set.

Response body: The actual content — the HTML of the page, the JSON of the API response, the bytes of the image.

Step 10: Browser Rendering

The browser receives the HTML and begins rendering. This is its own complex process:

1. Parse HTML: The browser reads the HTML and builds the DOM (Document Object Model) — a tree structure representing every element on the page.

2. Fetch external resources: As it encounters <link> tags (CSS), <script> tags (JavaScript), and <img> tags (images), it fires off additional HTTP requests for each one. Each follows the same journey: DNS, TCP, TLS, HTTP request, response. A typical webpage might trigger 30-100 additional requests.

3. Parse CSS: Stylesheets are parsed into the CSSOM (CSS Object Model), which defines how every element should look.

4. Execute JavaScript: Scripts are executed, which may modify the DOM, fetch additional data via AJAX/fetch calls, or change styling.

5. Layout: The browser combines the DOM and CSSOM to calculate the exact position and size of every element on the page.

6. Paint: Pixels are drawn to the screen. The page is visible.

The developer tools in your browser (F12) show all of this. The Network tab shows every request, its timing, and its status code. The Performance tab shows the rendering pipeline. When a page feels slow, these tools tell you whether the bottleneck is network (too many requests, slow responses) or rendering (heavy JavaScript, layout thrashing).

Common Failure Points at Every Layer

Each step in the chain is a potential failure point. Knowing which layer is failing is half the troubleshooting: