How a CDN Works: Request Flow Explained Step by Step

A Content Delivery Network (CDN) works by distributing copies of your content across a global network of edge servers and routing each user request to the closest available server. Instead of every visitor hitting your single origin server, the CDN intercepts the request at the DNS level, checks its local cache for the resource, and either serves a cached copy instantly or fetches fresh content from your origin. This process, from DNS resolution through edge lookup to final response, typically completes in under 50 milliseconds for cached content, compared to 200-800ms when serving directly from a distant origin. Understanding this request flow is essential for anyone who manages web infrastructure, optimizes site performance, or evaluates what a CDN actually does under the hood.

What Happens When a Browser Sends a Request?

Every CDN interaction begins with a seemingly simple action: a user types a URL or clicks a link. Behind the scenes, a carefully orchestrated sequence of network operations unfolds. The full request lifecycle involves DNS resolution, TCP connection establishment, TLS negotiation, edge cache lookup, potential origin fetching, and finally content delivery back to the browser.

Here is the complete request flow in sequential order:

1. DNS Resolution — The browser resolves the hostname to the IP of the nearest edge server
2. TCP Handshake — A three-way TCP handshake establishes the connection
3. TLS Negotiation — The client and edge server negotiate encryption parameters
4. HTTP Request — The browser sends the actual HTTP GET/POST request
5. Edge Cache Lookup — The edge server checks its local cache for the requested resource
6. Cache Hit or Miss — Content is either served from cache or fetched from upstream
7. Response Delivery — The edge server streams the response back to the browser

Each of these steps has been optimized by modern CDN providers to shave off milliseconds. Let us walk through each one in detail.

How Does DNS Resolution Route You to the Nearest Edge?

DNS resolution is the critical first step that determines which edge server handles your request. When you configure a CDN, you typically create a CNAME record pointing your domain to the CDN provider's domain. For example, cdn.example.com might CNAME to example.cdnprovider.net. The CDN's authoritative DNS servers then use intelligent routing to return the optimal edge server IP.

CDNs employ two primary DNS routing strategies:

Most enterprise CDNs today use the hybrid approach. The DNS TTL for CDN records is intentionally kept low, usually 30 to 60 seconds, so that routing decisions can adapt quickly to changing network conditions or server health. For a deeper comparison, see our guide on anycast versus unicast CDN routing.

After DNS resolution, the browser has the IP address of the optimal edge server, typically one located within the same city or region as the user, often just 10-30ms of network latency away.

How Do TCP and TLS Handshakes Work at the Edge?

With the edge server's IP resolved, the browser initiates a TCP connection through the standard three-way handshake: SYN, SYN-ACK, ACK. This adds one round-trip time (RTT) of latency. When connecting to a nearby edge server, this handshake might take 10-20ms. Without a CDN, the same handshake to a distant origin could take 100-200ms.

CDNs apply several TCP optimization techniques to accelerate this process:

• Increased Initial Congestion Window (initcwnd) — Standard TCP starts with a congestion window of 10 segments (about 14KB). CDN edge servers often use 30+ segments, allowing more data to flow in the first burst before slow-start ramps up.
• TCP Fast Open (TFO) — Allows data to be sent during the SYN handshake itself, eliminating one RTT for repeat connections.
• Connection Reuse — HTTP/2 multiplexing and keep-alive connections mean subsequent requests skip the handshake entirely.
• BBR Congestion Control — Many CDNs replace the default CUBIC algorithm with Google's BBR, which responds to actual bandwidth rather than packet loss, dramatically improving throughput on lossy links.

After TCP, the TLS handshake adds another layer. TLS 1.2 requires two additional round trips; TLS 1.3 reduces this to one. CDN edge servers support TLS session resumption and 0-RTT reconnection, meaning returning visitors can skip the TLS negotiation entirely. The edge server also handles OCSP stapling, bundling the certificate validity proof directly into the handshake to avoid the browser making a separate OCSP check.

The combined TCP + TLS setup to a nearby edge server typically takes 20-40ms. To a far-away origin without a CDN, the same negotiation might cost 300-600ms. This connection setup optimization alone accounts for a significant portion of the performance benefit a CDN provides.

What Happens During the Edge Cache Lookup?

Once the secure connection is established and the HTTP request arrives at the edge server, the CDN must decide whether it can serve the content from its local cache. This decision process is the heart of CDN caching.

The edge server constructs a cache key, typically a hash of the request URL, relevant headers (like Accept-Encoding), and sometimes query parameters or cookies. It then looks up this key in its local storage, which combines high-speed RAM (for the most popular objects) and NVMe SSDs (for the broader cache).

The lookup results in one of three outcomes:

The stale-while-revalidate pattern deserves special attention. When an edge server holds expired content and the origin has set Cache-Control: stale-while-revalidate=60, the edge serves the stale version immediately to the requesting user and simultaneously sends a background request to the origin for a fresh copy. The next user to request that resource will get the updated version. This approach prevents cache miss latency spikes on popular content that refreshes frequently. Learn more about optimizing your cache hit ratio.

How Does the Cache Hierarchy Handle a Miss?

When an edge server does not have the requested content, the request does not necessarily go straight to the origin. Modern CDNs implement a multi-tier cache hierarchy that significantly reduces the load on origin servers.

The typical hierarchy flows through these tiers:

+------------------+     Cache Miss      +------------------+     Cache Miss      +------------------+
|   Edge Server    | ------------------> |  Regional Shield  | ------------------> |   Origin Server  |
|   (L1 / PoP)     |                     |   (L2 / Mid-Tier) |                     |   (Your Server)  |
|                  | <-- Cache Hit --    |                   | <-- Cache Hit --    |                  |
|  RAM + SSD Cache |   serves content    | Large SSD Cache   |   serves content    | Source of Truth   |
+------------------+                     +------------------+                     +------------------+
     ~5ms RTT                                ~20ms RTT                               ~100ms+ RTT

Layer 1 (Edge / PoP): The server closest to the user. It holds the most popular content, determined by access frequency. Storage capacity is typically 1-10TB of NVMe SSD per server, with 64-256GB of RAM for hot objects. Each Point of Presence (PoP) contains multiple edge servers behind a load balancer.

Layer 2 (Regional Shield / Mid-Tier): A larger cache node that aggregates requests from multiple edge servers in a region. When an edge server has a cache miss, it queries the regional shield before going to the origin. Because the shield receives combined traffic from many edges, it maintains a much larger working set of cached content. This single layer can absorb 80-95% of cache misses, dramatically reducing origin traffic.

Origin Server: Your actual web server or storage backend. The CDN contacts the origin only when both the edge and shield miss. At scale, this can reduce origin requests by 95-99%, meaning your origin handles a tiny fraction of actual user traffic.

When the origin responds, the content flows back through the hierarchy. The shield caches a copy, and the edge caches a copy. Subsequent requests from any edge in the same region will hit the shield, and subsequent requests from the same edge will hit locally. This cascading cache fill ensures content propagates efficiently across the network. For full architecture details, see our CDN architecture overview.

What Role Do Cache-Control Headers Play?

The origin server controls CDN caching behavior through HTTP headers. These headers tell every cache in the hierarchy how long to store content, who may cache it, and under what conditions to revalidate. Getting headers right is fundamental to CDN performance.

The most important headers are:

• Cache-Control: public, max-age=86400 — Cache for 24 hours; any cache (edge, shield, browser) may store it.
• Cache-Control: private, no-cache — Do not cache on CDN edges; content is user-specific. The browser may still cache but must revalidate.
• Cache-Control: s-maxage=3600 — Shared cache (CDN) TTL of 1 hour, overriding max-age for CDN edges while letting browsers use a different TTL.
• Cache-Control: stale-while-revalidate=120 — Serve stale content for up to 120 seconds while fetching fresh content in the background.
• Cache-Control: stale-if-error=86400 — If the origin is unreachable, serve stale content for up to 24 hours rather than returning an error.
• Vary: Accept-Encoding — Cache separate versions for gzip, Brotli, and uncompressed responses.
• ETag / Last-Modified — Enable conditional requests (304 Not Modified) to validate content without re-downloading the full body.

A well-configured origin sends different headers for different content types. Static assets like images and CSS get long TTLs (30 days or more). HTML pages might use shorter TTLs with stale-while-revalidate. API responses may be uncacheable or cached for only seconds. This selective caching is the foundation of an effective CDN caching strategy.

How Does the Response Travel Back to the User?

After the content is located, either from cache or fetched from the origin, the edge server prepares and sends the response. Several optimizations happen during this final leg of the journey.

Compression: The edge server compresses the response body using Brotli (preferred for text) or Gzip (universal fallback). Brotli typically achieves 15-25% better compression than Gzip for HTML, CSS, and JavaScript. Many CDNs pre-compress popular assets at multiple quality levels and serve the best match based on the client's Accept-Encoding header.

Protocol Optimization: Over HTTP/2 and HTTP/3, the edge server multiplexes multiple responses over a single connection, prioritizes critical resources (like CSS and fonts over images), and uses header compression (HPACK for HTTP/2, QPACK for HTTP/3) to reduce overhead. HTTP/3 with QUIC is particularly impactful on mobile networks because it eliminates head-of-line blocking and recovers from packet loss without stalling the entire connection.

Edge Processing: Modern CDNs can modify the response at the edge before sending it. This includes injecting security headers, optimizing images on the fly (resizing, converting to WebP or AVIF), minifying HTML, and adding early hints (103 responses) to tell the browser about critical resources it should preload.

The complete round trip for a cache hit at the edge follows this flow:

User Browser          Edge Server (PoP)
     |                      |
     |--- DNS Query ------->|  (resolved via anycast/geo-DNS)
     |<-- Edge IP ----------|  ~5-20ms
     |                      |
     |--- TCP SYN --------->|
     |<-- SYN-ACK ---------|  ~10-20ms RTT
     |--- ACK ------------->|
     |                      |
     |--- TLS ClientHello ->|
     |<-- ServerHello+Cert -|  ~10-20ms (TLS 1.3 = 1 RTT)
     |--- Finished -------->|
     |                      |
     |--- GET /resource --->|
     |    (Cache Lookup)    |  ~1-5ms
     |<-- 200 OK + body ----|  Compressed, multiplexed
     |                      |
     Total: ~30-60ms (cache hit)

Compare this to a request that bypasses the CDN and goes directly to an origin server located 5,000 miles away, where each round trip takes 80-120ms. The same sequence would take 400-700ms. The CDN delivers content 5-10 times faster simply by reducing the distance each network round trip must travel.

How Does a CDN Handle Dynamic and Uncacheable Content?

Not all content can be cached. Personalized pages, API responses with user-specific data, and real-time feeds are inherently dynamic. However, a CDN still improves the delivery of dynamic content through several mechanisms.

Connection Pre-warming: The CDN maintains persistent, pre-established TCP and TLS connections between its edge servers and your origin. When a cache miss occurs, the edge does not need to open a new connection; it reuses an existing one, saving 100-200ms of handshake time per request.

Route Optimization: CDN backbone networks use optimized routing between PoPs and origins. Internet routing via BGP often takes suboptimal paths. CDN providers use their private backbone or negotiate direct peering at Internet Exchange Points to ensure traffic takes the fastest possible path from edge to origin. This can reduce round-trip latency by 30-50% compared to the public Internet route.

Request Collapsing: When multiple users request the same uncached resource simultaneously, the edge sends only one request to the origin and holds the other requests. Once the origin responds, the edge serves all waiting requests from the single fetched copy. This protects origins from cache stampedes during traffic spikes.

Even for fully dynamic content, these optimizations mean the CDN adds value beyond caching. The combination of proximity for TLS termination, persistent origin connections, and optimized routing typically shaves 100-300ms off every dynamic request. For a comprehensive look at infrastructure, explore our edge server deep dive.

What Are Common Performance Metrics to Monitor?

Understanding how your CDN performs requires tracking the right performance metrics. The most critical measurements include:

If your cache hit ratio is below 80%, review your origin's Cache-Control headers, cache key design, and whether query parameters or cookies are fragmenting your cache. If TTFB is high despite cache hits, investigate TLS configuration and whether your CDN supports the latest protocols. These metrics tell the story of how effectively your CDN request flow is performing in production.

What Misconceptions Do People Have About CDN Request Flow?

Several persistent myths cause confusion about how CDNs actually work:

Myth: CDNs only help with static files. While caching static assets is a CDN's most visible function, the TCP/TLS optimizations, route optimization, and connection pre-warming described above benefit every type of request, including dynamic API calls and server-rendered pages.

Myth: Content is pushed to all edge servers instantly. Most CDNs use a pull model. Content reaches an edge server only when a user requests it through that server. The first user in a region experiences a cache miss and slightly longer load time, while all subsequent users benefit from the cached copy. Push-based CDN distribution is available but primarily used for large files or pre-positioned content.

Myth: More PoPs always means better performance. A CDN with 300 PoPs is not necessarily faster than one with 50. What matters is PoP placement relative to your users, cache hit ratios at each PoP, and the quality of the backbone network connecting them. A smaller network with well-placed, high-capacity PoPs and excellent peering can outperform a larger network with thinly provisioned locations.

Myth: CDNs add latency. The DNS redirection adds 1-5ms of overhead, but this is more than offset by saving 100-600ms of round-trip time by serving from a closer location. The net effect is always positive for geographically distributed users.

How Does CDN Security Fit Into the Request Flow?

Security processing happens at several points in the request flow. Before the edge server even checks its cache, incoming requests pass through the CDN's security stack.

DDoS Absorption: The CDN's distributed architecture inherently absorbs volumetric attacks by spreading traffic across hundreds of PoPs. Anycast routing ensures attack traffic is distributed globally rather than concentrated on a single server. For application-layer attacks, the edge applies rate limiting, bot detection, and challenge pages before forwarding legitimate requests. Read our detailed guide on CDN DDoS protection.

Web Application Firewall (WAF): Request inspection rules run at the edge, blocking SQL injection, cross-site scripting, and other OWASP Top 10 attacks before they reach your origin. Processing security rules at the edge adds 1-3ms of latency but prevents malicious requests from consuming origin resources.

Origin Shielding: By hiding your origin server's IP address behind the CDN, attackers cannot directly target your infrastructure. The CDN acts as a reverse proxy, and all traffic must pass through its security stack to reach the origin.

These security layers integrate seamlessly into the request flow, running in parallel with cache lookup operations to avoid adding sequential latency.

Putting It All Together

The CDN request flow is a precisely engineered pipeline that transforms a simple URL request into a globally optimized content delivery operation. From intelligent DNS routing that selects the ideal edge server, through accelerated TCP and TLS handshakes, to multi-tier cache lookups that serve content in single-digit milliseconds, every stage has been refined over two decades of CDN evolution.

The key takeaway is that a CDN does far more than cache files. It fundamentally restructures how internet traffic flows, placing compute, storage, and security capabilities as close to the end user as possible. Whether you are serving static assets, dynamic API responses, or streaming video, understanding this request flow helps you configure your CDN for maximum performance, set appropriate caching policies, and diagnose issues when they arise.

For the architectural foundation behind these concepts, continue to our CDN architecture overview, or explore how latency optimization techniques push performance even further at the edge.

Regional CDN providers often publish detailed technical guides that complement the protocol-level understanding covered here. VNETWORK's comprehensive CDN guide covers the six core benefits of content delivery infrastructure from a deployment perspective, with practical insights specific to the Asia-Pacific market where cross-border routing complexity makes CDN architecture decisions particularly impactful.