How Internet Traffic Flows: From Click to Server

When you click a link in a browser, data travels through a chain of systems that spans continents in milliseconds. Most people experience this as instantaneous, with no awareness of the extraordinary sequence of events that produces a response. This guide traces that journey end to end — from the moment you press Enter to the moment the page appears on your screen.

The Setup: What Happens Before the Packet Leaves

Before a single byte of your HTTP request reaches a web server, several things must happen on your local machine.

1. DNS Resolution

Your browser needs the IP address for the domain you want to visit (e.g., www.example.com). Domain names are human-readable; the network only understands IP addresses.

Step 1 — Browser cache check: The browser keeps a short-lived DNS cache. If you visited this site recently and the TTL hasn't expired, you already have the IP.

Step 2 — OS resolver cache: If the browser cache misses, the OS's DNS resolver checks its own cache.

Step 3 — Query the recursive resolver: If still not cached, the OS sends a UDP query (port 53) to the recursive resolver — typically operated by your ISP, or a public resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). This resolver will do the heavy lifting.

Step 4 — Root servers: The recursive resolver queries a root name server: "Who handles .com?" The root returns the addresses of the .com TLD name servers (operated by Verisign).

Step 5 — TLD servers: The resolver queries the .com TLD servers: "Who handles example.com?" They return the authoritative name servers for that domain (e.g., ns1.example.com).

Step 6 — Authoritative name server: The resolver queries ns1.example.com: "What is the IP of www.example.com?" The authoritative server returns an A record (IPv4) or AAAA record (IPv6) with the IP address.

Step 7 — Response delivered: The recursive resolver returns the IP to your browser and caches it per the TTL.

This entire process typically takes 20–200 ms on a cold cache, but subsequent lookups are near-instant from cache. If DNSSEC is enabled, each step also validates cryptographic signatures.

2. TCP Connection (or QUIC)

With an IP address in hand, your browser opens a connection to the server. For HTTPS (which is essentially all modern web traffic), this involves:

TCP Three-Way Handshake:

Client → Server:  SYN
Server → Client:  SYN-ACK
Client → Server:  ACK

This round trip establishes the TCP connection. For a server on another continent, this already costs 100–300 ms.

TLS Handshake (for HTTPS):

Over the established TCP connection, the browser and server negotiate an encrypted channel:

1. Client sends ClientHello (supported TLS versions, cipher suites, random value)
2. Server sends ServerHello, its TLS certificate, and (in TLS 1.3) begins key exchange
3. Client validates the certificate against trusted root CAs
4. Both sides derive symmetric encryption keys
5. Connection is encrypted

TLS 1.3 (the current standard) requires only one round trip for the handshake, versus two for TLS 1.2. With TLS 1.3 0-RTT resumption, a returning client can send data immediately with no handshake round trips (though with some security tradeoffs).

QUIC / HTTP/3:

An alternative to TCP+TLS: QUIC is a UDP-based transport developed by Google that combines transport and TLS into a single handshake, eliminating the two-step TCP+TLS process. HTTP/3 runs over QUIC. Major websites and CDNs support HTTP/3, further reducing connection establishment time.

The Request Travels the Internet

Your HTTP GET request is encapsulated in a TCP segment, which is wrapped in an IP packet, which is encapsulated in an Ethernet or Wi-Fi frame for your local network segment.

Your Local Network (Last Mile)

The packet first traverses your local network:

1. Your device — Sends the frame to your default gateway (router).
2. Home router — Performs NAT (Network Address Translation): your private IP (e.g., 192.168.1.5) is replaced with your public IP. The router tracks the connection in a NAT table to route responses back to your device.
3. Modem / ONT — Converts the signal for your access technology (DSL, cable/DOCSIS, fiber/PON).
4. ISP access network — Your traffic enters your ISP's network.

BGP Routing Through Autonomous Systems

Once in the ISP's network, the packet is routed toward its destination IP address. The internet is divided into approximately 100,000+ Autonomous Systems (ASes) — independently operated networks, each with a unique AS number (ASN). Your ISP is one AS. Google is another. Amazon is another.

Routing between ASes is handled by BGP (Border Gateway Protocol). BGP is a path-vector protocol: each AS advertises which IP prefixes it can reach, along with the path of ASes that traffic must traverse. Routers use this information to choose the best path.

A packet from a user in Chicago to a server in Singapore might traverse:

User's ISP (AS 7922) → Transit provider (AS 3356, Lumen) →
  Singapore exchange (Singapore IXP) → Target network (AS 16509, Amazon)

At each AS boundary, a BGP border router makes a routing decision based on:

• AS path length — Prefer shorter paths (fewer AS hops)
• Local preference — Internal policy (prefer certain upstream providers)
• MED (Multi-Exit Discriminator) — Hint from the peer about preferred entry point
• Community attributes — Tags used to implement routing policy

The packet may cross 10–20 routers before reaching its destination.

Inside the Destination Network

When the packet arrives at Amazon's (for example) AS:

1. Edge routers accept the packet from the external network.
2. Internal routing (OSPF/IS-IS/iBGP) forwards it within Amazon's data center network.
3. Load balancer distributes the request across multiple application servers.
4. Application server processes the request (database queries, business logic, templating).
5. Response travels back the same way (though not necessarily the same physical path, since internet routing is often asymmetric).

CDN Interception: The Shorter Path

For most major websites, your request never reaches the "origin" server directly. Instead, DNS is configured to return an IP address belonging to a CDN (Cloudflare, Akamai, Fastly). Your request goes to the nearest CDN PoP (Point of Presence), which:

1. Checks its cache. On a hit, the response is returned immediately from the edge — no trip to the origin.
2. On a miss, the CDN fetches the content from the origin, caches it, and returns it to you.

For a user in Singapore accessing a US-hosted site via Cloudflare:

• Without CDN: Singapore → US → Singapore (300–400 ms RTT)
• With CDN (cached): Singapore → Singapore CDN PoP (5–20 ms RTT)

The Response Returns

The server's response follows a similar journey in reverse:

1. The application server returns an HTTP response (status code, headers, body).
2. The response is fragmented into TCP segments (typically 1,460 bytes each for standard Ethernet MTU).
3. TCP's congestion control governs how fast segments are sent — starting with a small congestion window and increasing it with each acknowledged segment (slow start).
4. Segments traverse the internet in reverse, with BGP routing determining the path (which may differ from the request path).
5. Your home router's NAT table maps the response back to your device.
6. TCP reassembles the segments into the complete HTTP response.
7. The browser parses HTML, makes additional requests for CSS, JS, and images (often multiplexed over HTTP/2 streams), and renders the page.

Timing: A Typical Breakdown

For a typical page load from a well-optimized global website:

Step	Time
DNS resolution (cold cache)	20–100 ms
TCP connection	1 RTT (30–200 ms depending on distance)
TLS 1.3 handshake	1 RTT (same as TCP RTT)
HTTP request + first byte	1 RTT + server processing (5–50 ms)
HTML download	Depends on size; ~1–10 ms for 30 KB
Sub-resources (JS, CSS, images)	Multiplexed; 1–3 additional RTTs
Total (nearby CDN)	100–400 ms
Total (no CDN, different continent)	500–2000 ms

Why Understanding This Matters

Every millisecond in this chain has business impact. Studies consistently show that page load time directly correlates with conversion rates and user satisfaction. Understanding the full journey — DNS, TCP, BGP, last mile, CDN — gives you the framework to diagnose bottlenecks, interpret performance metrics, and make informed infrastructure decisions. It also reveals why the internet's physical architecture (cables, exchange points, data centers) is not abstract background noise but a direct determinant of the user experience.