Anatomy of a CDN Request: From Browser to Edge to Origin

Every time a browser fetches a resource through a CDN, a precisely orchestrated sequence of network operations occurs in milliseconds. Understanding this request lifecycle is essential for diagnosing performance issues, configuring cache behavior, and optimizing delivery. A CDN request is not a single event but a chain of protocol-level handshakes, cache decisions, and header negotiations that determine whether content is served from the edge or fetched from origin. For a comprehensive overview, see our guide on CDN Architecture: Edge, Origin, and Everything Between — FlyFish NWA.

This guide traces the complete path of an HTTP request through a content delivery network, from the moment a user clicks a link to the final byte arriving in their browser. Each stage introduces latency, and each offers opportunities for optimization.

What Are the Stages of a CDN Request?

A CDN request follows six distinct stages. The total time from request initiation to first byte received (Time to First Byte, or TTFB) is the sum of all stages that execute. On a cache hit, the origin fetch stage is skipped entirely.

Browser Request Flow Through CDN
================================

[Browser] --DNS Query--> [Recursive Resolver] --Query--> [CDN Authoritative DNS]
    |                                                            |
    |  <-- Edge IP (nearest PoP) --------------------------------+
    |
    +--TCP SYN--> [CDN Edge Server]
    |  <--SYN-ACK--    |
    +--ACK-->          |
    |                  |
    +--TLS ClientHello-->
    |  <--ServerHello + Cert--
    +--Key Exchange-->
    |  <--Finished--
    |                  |
    +--HTTP GET------> [Cache Lookup]
    |                    |         |
    |                  [HIT]    [MISS]
    |                    |         |
    |                    |    [Origin Fetch]
    |                    |         |
    |  <--HTTP Response--+---------+
    |
[Browser renders content]

How Does DNS Resolution Work for CDN Requests?

The request lifecycle begins before any HTTP traffic flows. When a browser needs to load cdn.example.com/image.jpg, it must first resolve the hostname to an IP address. This DNS resolution phase is the foundation of CDN routing and directly impacts which edge server handles the request.

The domain typically has a CNAME record pointing to the CDN provider's domain (e.g., cdn.example.com CNAME d1234.cloudfront.net). The CDN's authoritative DNS server then returns the IP address of the edge server closest to the user's resolver. This proximity-based selection relies on techniques covered in detail in the DNS resolution guide.

DNS resolution adds 1-100 milliseconds to the first request. Subsequent requests to the same domain skip this step because the browser and operating system cache the DNS response according to its TTL value. The CDN provider sets TTL values strategically: short enough to reroute traffic during failovers (typically 30-60 seconds), but long enough to avoid excessive DNS lookups.

What Happens During TCP and TLS Handshakes?

After DNS resolution returns an edge server IP, the browser establishes a TCP connection through a three-way handshake (SYN, SYN-ACK, ACK). This requires one full round trip between the browser and the edge server. Because CDN edge servers are geographically close to users, this round trip is typically 5-30 milliseconds rather than the 50-200 milliseconds it might take to reach a distant origin server.

For HTTPS requests, a TLS handshake follows immediately. TLS 1.3 requires just one additional round trip (down from two in TLS 1.2). The edge server presents the SSL certificate for the domain, and the browser and server negotiate encryption parameters. CDN providers maintain optimized TLS configurations with session resumption tickets and OCSP stapling to minimize handshake overhead.

Connection Reuse and HTTP/2 Multiplexing

Modern browsers maintain persistent connections (HTTP keep-alive) to CDN edge servers. After the initial TCP and TLS handshakes, subsequent requests to the same edge reuse the existing connection, eliminating handshake latency entirely. With HTTP/2 and HTTP/3, multiple requests multiplex over a single connection, further reducing overhead for pages that load dozens of resources from the same CDN domain.

How Does the CDN Edge Decide to Serve from Cache?

Once the HTTP request arrives at the edge server, the CDN performs a cache lookup. This is the critical decision point that determines whether the response comes from local storage (cache hit) or requires an origin fetch (cache miss). The edge server constructs a cache key from the request attributes and searches its local store.

The Cache Decision Tree

The edge server evaluates requests through a structured decision process:

1. Is the request method cacheable? GET and HEAD requests are cacheable. POST, PUT, DELETE, and PATCH bypass cache.
2. Does a cache entry exist for this key? The cache key typically combines the URL path, query string, host header, and any Vary header fields. No entry means a cache miss.
3. Has the cached entry expired? The edge checks the max-age or s-maxage directive from Cache-Control. If the Age exceeds the TTL, the entry is stale.
4. Is stale serving allowed? If stale-while-revalidate is set, the edge may serve the stale response while asynchronously revalidating with the origin. See the stale-while-revalidate guide.
5. Does the request have bypass conditions? Certain cookies, authorization headers, or CDN-specific rules may force a cache bypass regardless of cached content availability.

Cache Hit: The Fast Path

On a cache hit, the edge server reads the cached response from its local SSD or memory store and sends it directly to the client. No origin communication occurs. The response includes headers indicating the cache status:

HTTP/2 200 OK
Content-Type: image/webp
Cache-Control: public, max-age=86400
Age: 3742
X-Cache: HIT
Via: 1.1 edge-server-lax-01
CF-Cache-Status: HIT
X-Served-By: cache-lax-01

Cache Miss: The Origin Fetch Path

On a cache miss, the edge server must retrieve the resource from the origin. This involves a separate TCP/TLS connection between the edge and the origin server (or a mid-tier cache layer if configured). The edge acts as a reverse proxy, forwarding the client request to the origin with additional headers:

GET /image.jpg HTTP/1.1
Host: origin.example.com
X-Forwarded-For: 203.0.113.50
X-Forwarded-Proto: https
CDN-Loop: cloudflare

The CDN-Loop header prevents infinite loops in multi-CDN configurations. The X-Forwarded-For header preserves the original client IP for origin logging and access control.

What Role Do Conditional Requests Play?

When a cached response expires, the edge server does not necessarily discard it and fetch a full new copy. Instead, it sends a conditional request to the origin, asking whether the content has actually changed. This mechanism can save significant bandwidth when content rarely changes despite short TTLs.

ETag-Based Validation

If the original response included an ETag header (a unique identifier for the content version), the edge sends:

GET /styles.css HTTP/1.1
Host: origin.example.com
If-None-Match: "a1b2c3d4e5f6"

If the content has not changed, the origin responds with 304 Not Modified and no body. The edge refreshes the TTL on its cached copy and serves it to the client. This exchange is far cheaper than transferring the full resource.

Last-Modified Validation

Alternatively, if the original response included a Last-Modified header, the edge sends:

GET /styles.css HTTP/1.1
Host: origin.example.com
If-Modified-Since: Tue, 10 Mar 2026 08:00:00 GMT

The origin compares the modification timestamp and returns either a 304 Not Modified or a full 200 OK with the updated content. ETag validation is generally preferred because it handles byte-level changes more precisely, while Last-Modified has only one-second granularity.

What Headers Does the CDN Add to Responses?

CDN edge servers inject diagnostic headers into responses that are invaluable for debugging delivery issues and verifying cache behavior. Understanding these headers is critical for anyone operating a CDN-delivered application.

The Age header is particularly important: it tells the browser how long the response has been sitting in CDN cache. The browser subtracts Age from max-age to determine remaining freshness, which means content cached at the edge for 3,742 seconds with a max-age of 86,400 will be treated as having 82,658 seconds of freshness remaining by the browser.

How Can You Measure CDN Request Timing?

Each stage of the request contributes measurable latency. Understanding the timing breakdown helps identify bottlenecks and validate that CDN optimization is working. The table below shows typical latency ranges for each phase:

Browser developer tools (Network tab) show these phases broken down as DNS, Connection, TLS, Waiting (TTFB), and Content Download. The Resource Timing API provides programmatic access to the same data, enabling real-user monitoring (RUM) at scale. Review CDN performance metrics for comprehensive measurement strategies.

How Do Multi-Tier CDN Architectures Affect the Request Path?

Enterprise CDN configurations often include multiple cache tiers that add intermediate steps to the request path. In a typical multi-tier setup, a cache miss at the L1 edge does not go directly to origin. Instead, the request flows to an L2 regional cache or origin shield, which may have the content cached from requests by other L1 nodes in the same region.

This tiered approach reduces origin load significantly. If 50 edge nodes each miss on the same content, only one request reaches the origin instead of 50. The cache hierarchy guide covers L1, L2, and origin shield configurations in detail.

Within these tiers, load balancing algorithms distribute requests across multiple servers at each level. Consistent hashing ensures that requests for the same resource route to the same server within a tier, maximizing the probability of a cache hit. The health check system continuously monitors each tier and reroutes traffic if a server or entire PoP becomes unavailable.

What Are Common Request Flow Problems and How Do You Debug Them?

Understanding the request anatomy enables systematic debugging when delivery problems occur. Common issues include:

Unexpected cache misses: Check the Vary header for excessive variation (e.g., Vary: User-Agent creates thousands of cache key variants). Verify cache key configuration and query string handling. Examine whether cookies or authorization headers are preventing caching.

High TTFB on cache hits: This suggests edge server overload or network congestion between the user and the nearest PoP. Check geo-routing configuration to ensure users are reaching the closest edge. Verify that the edge is not performing expensive transformations (image resizing, compression) on cached content.

Origin timeout on cache miss: Verify the TCP connection between edge and origin. Check origin server health, connection limits, and whether the CDN is sending connection headers that the origin rejects. Ensure the origin is not rate-limiting CDN edge IPs.

Stale content after deployment: After updating content at the origin, cached versions persist at the edge until their TTL expires. Use cache invalidation (purge) to force edges to fetch fresh content. Consider implementing cache-busting via content-hashed filenames for static assets.

Every CDN request is a series of protocol negotiations and cache decisions executed in milliseconds. By understanding each stage, from DNS resolution through content routing to final response delivery, engineers can diagnose issues precisely, configure caching optimally, and ensure that the CDN delivers on its promise of fast, reliable content delivery at the edge.