CDN: How It Works, 5 Types, Security & 6 Best Practices

• Origin server: Stores the authoritative content and serves resources that cannot be fulfilled from the CDN cache.
• CDN edge servers: Process requests near users and return locally cached content when available.
• Points of presence (PoPs): Distribute groups of edge servers across geographic locations to provide capacity and redundancy.
• DNS routing: Directs requests toward an appropriate CDN edge location based on network and availability conditions.

• Content caching: Stores reusable resources at the edge according to TTLs, cache headers, and other caching rules.
• Cache hits and misses: Serves valid cached resources immediately or retrieves missing and stale content from the origin.
• Edge content delivery: Routes users to a nearby or best-performing edge location based on latency, congestion, capacity, and other network conditions.

• How Does a CDN Work?
• What Content Can a CDN Deliver?
• CDN Architecture and Key Components
• Types of CDNs
• Common CDN Use Cases
• CDN vs. Other Web Performance and Delivery Services

• Benefits of CDN
• Common CDN Challenges and Limitations
• CDN Security: How Does a CDN Protect Websites and Applications?
• CDN Best Practices
• Fast and Secure Content Delivery with Radware CDN

1. Origin Server

The origin server hosts the authoritative version of a website, application, or its content. It may store:

• HTML pages
• API responses
• Images
• Videos
• JavaScript
• Stylesheets
• Other resources

Without a CDN, users normally retrieve these resources directly from the origin. With a CDN, the origin handles requests that cannot be satisfied at the edge. It also provides updated content when cached copies expire or require revalidation. Reducing direct requests to the origin can lower bandwidth usage and help prevent the server from becoming a performance bottleneck during traffic spikes.

2. CDN Edge Servers

Edge servers are CDN servers positioned closer to users than the origin server. They receive incoming requests and check whether the requested resource is available in their local cache. When it is, the server can return the resource without contacting the origin. Edge servers can perform more than caching. Depending on the CDN, they may:

• Terminate TLS connections
• Compress responses
• Optimize images
• Execute edge code
• Filter malicious requests
• Apply access rules

Moving these operations to the edge can reduce both latency and processing work at the origin.

3. Points of Presence (PoPs)

A point of presence (PoP) is a physical location where a CDN operates network infrastructure. A PoP usually contains multiple edge servers and networking equipment. Providers distribute PoPs across:

• Cities
• Countries
• Regions

They place infrastructure near major groups of users and internet exchange points. Multiple servers within each PoP provide capacity and redundancy. If one server becomes unavailable or overloaded, requests can be handled by other infrastructure. CDN providers can also route traffic to another PoP when network conditions or outages make it a better choice.

4. DNS Routing

DNS helps direct requests to the CDN rather than directly to the origin server. A website operator typically configures DNS records so that a CDN-managed hostname or address is returned when users resolve the domain. The CDN can then direct traffic toward an appropriate edge location. Selection may consider:

• Latency
• Network topology
• Server capacity
• Availability
• Geographic location

Many large CDNs also use anycast, where multiple PoPs advertise the same IP address and internet routing generally sends traffic toward a nearby reachable location.

5. Content Caching

Caching stores copies of resources on CDN infrastructure so they do not need to be fetched from the origin for every request. Static resources are especially suitable because the same data is often requested repeatedly. These include:

• Images
• Fonts
• Stylesheets
• JavaScript files
• Videos
• Software downloads

Cache behavior is controlled through rules such as time to live (TTL), Cache-Control headers, and CDN-specific settings. These rules determine whether a response can be cached, how long it remains valid, and when the CDN must retrieve or validate a newer version. Cache keys can also distinguish content based on properties such as the URL, query parameters, or selected request headers.

6. Cache Hits and Cache Misses

A cache hit occurs when the CDN finds a valid cached response for a request. The edge server returns that response directly, avoiding a trip to the origin. Cache hits generally provide the largest latency reduction and decrease bandwidth and processing requirements at the origin.

A cache miss occurs when the requested resource is not cached or its cached copy is no longer valid. The CDN must fetch the resource from the origin or another cache layer. It can then return the response to the user and, when caching rules allow it, store a copy so later requests can become cache hits.

A CDN typically serves requests from an edge location that can provide a fast and reliable connection to the user. This is not always the geographically closest PoP. Routing decisions can account for:

• Network latency
• Congestion
• Peering relationships
• Server capacity
• Outages
• The availability of cached content

The selected edge server processes the request and returns cached content when possible. If the resource is unavailable or stale, the CDN retrieves it from the origin or another cache layer before delivering it to the user. CDN routing can change between requests as network conditions and infrastructure availability change.

Static Content

Static content consists of files that are usually delivered unchanged to many users. Common examples include:

• CSS files
• JavaScript
• Fonts
• Icons
• HTML files
• Documents

These resources are well suited to CDN caching because the same response can be reused across requests. A CDN stores copies of static files at edge locations according to configured cache rules. Subsequent requests can then be served from the cache instead of the origin. Versioned filenames and cache-control headers are commonly used to allow long cache lifetimes while ensuring updated files are delivered when an application changes.

Dynamic Content

Dynamic content is generated or customized in response to a request. Examples include:

• Account pages
• Search results
• Shopping carts
• Content based on user sessions

Because responses may differ between users, they often cannot be cached in the same way as static files. A CDN can still accelerate dynamic content by optimizing the connection between the edge and origin. Techniques can include persistent connections, optimized routing, TLS connection reuse, and selective caching of responses that are safe to share. Some CDNs can also execute application logic at the edge to avoid unnecessary origin requests.

Images and Video

Images and video often account for a large percentage of the data transferred by websites and applications. CDNs can cache these files near users, reducing origin bandwidth and improving load times. This is particularly useful for sites with large image libraries or audiences distributed across multiple regions.

CDNs may also transform media during delivery. Image services can resize, crop, compress, or convert files to formats supported by the client. Video CDNs can distribute streaming segments and support adaptive bitrate streaming, which changes video quality based on available bandwidth and playback conditions.

Software Downloads and Large Files

CDNs can distribute:

• Software installers
• Application updates
• Game assets
• Operating system images
• Archives
• Other large files

Serving these files from edge locations prevents every download from consuming bandwidth and connections at the origin. This approach is useful when many users download the same large file, such as after a software release. CDNs can handle high request volumes across distributed infrastructure and may support features such as HTTP range requests, allowing clients to request specific portions of a file or resume interrupted downloads.

CDNs can proxy API and application requests even when the responses cannot be cached. Requests enter the CDN at an edge location and are then forwarded to the appropriate backend service. The CDN can optimize network paths and maintain reusable connections to reduce communication overhead with the origin.

Cacheable API responses can also be stored at the edge when their data is safe to reuse. In addition, CDNs commonly apply TLS termination, rate limiting, web application firewall rules, bot filtering, and DDoS mitigation to application traffic before requests reach backend infrastructure.

• Origin servers: Store the authoritative version of website or application content. The CDN contacts the origin when requested content is unavailable or stale at the edge.
• Edge servers: Handle requests close to users. They serve cached content and may also perform compression, TLS termination, request filtering, and other processing.
• Points of presence (PoPs): Physical locations that contain groups of edge servers and networking equipment. PoPs distribute CDN capacity across different geographic regions.
• Caching systems: Store copies of frequently requested resources at the edge. Cache rules, TTL values, and HTTP headers determine what is stored and for how long.

• DNS and traffic-routing systems: Direct requests to suitable CDN locations. Routing decisions can account for network latency, availability, capacity, and topology.
• CDN backbone and network connections: Connect CDN locations to each other and to origin infrastructure. Some providers operate private backbone networks to reduce reliance on congested public internet routes.
• Control plane: Manages CDN configuration, including cache policies, routing rules, security settings, origin definitions, and content invalidation.
• Security services: Inspect and filter traffic before it reaches the origin. Common capabilities include DDoS mitigation, web application firewalls, bot management, rate limiting, and TLS certificate management.

Traditional Pull CDNs

Traditional pull CDNs retrieve content from the origin when it is first requested. If the requested resource is not already cached at the edge, the CDN fetches it from the origin, returns it to the user, and stores a copy according to its caching rules.

Why it’s useful: This model requires little manual content distribution because the CDN populates caches as traffic arrives. It works well for websites with many cacheable resources, although the first request for uncached or expired content still requires communication with the origin.

Push CDNs

Push CDNs store content on CDN infrastructure before users request it. Website operators upload or publish files to the CDN, which then distributes or makes them available from its delivery infrastructure without fetching them from the origin on demand.

Why it’s useful: Push delivery is useful for large files, software releases, media assets, and other content whose distribution can be planned in advance. It provides more control over when content reaches the CDN, but requires a process for uploading, updating, and removing files.

Private CDNs

A private CDN is infrastructure operated for a specific organization rather than shared among many CDN customers. The organization controls the servers, network configuration, caching policies, capacity planning, and geographic placement of the delivery infrastructure.

Why it’s useful: Private CDNs can be useful for organizations with very large traffic volumes, specialized security requirements, or predictable user locations. However, they require significant infrastructure and operational resources compared with using a commercial CDN provider.

Multi-CDN Architectures

A multi-CDN architecture uses two or more CDN providers to deliver the same application or content. Traffic can be distributed between providers based on factors such as availability, latency, geographic coverage, capacity, or cost.

Why it’s useful: Traffic management is commonly performed through DNS-based routing or other request-routing systems. Multi-CDN designs can reduce dependence on a single provider and improve resilience, but they also add complexity because caching, security policies, logging, invalidation, and configuration must remain consistent across providers.

Cloud CDN services are CDN capabilities integrated with public cloud platforms. They commonly connect directly to cloud storage, load balancers, virtual machines, serverless applications, and other services hosted within the same cloud environment.

Why it’s useful: These services simplify CDN deployment for applications already running in the provider's infrastructure. Configuration, monitoring, access controls, certificates, and billing can often use the same cloud management tools, although relying heavily on one platform can increase provider dependence.

Website Acceleration

CDNs accelerate websites by caching static resources such as images, stylesheets, JavaScript, and fonts at edge locations. Users can retrieve these resources from nearby servers instead of repeatedly connecting to the origin, reducing network latency and origin traffic.

CDNs can also improve delivery through compression, optimized routing, connection reuse, and modern HTTP protocols. These techniques are useful for websites serving users across multiple geographic regions or handling sudden increases in traffic.

eCommerce Websites

eCommerce websites use CDNs to deliver product images, scripts, stylesheets, and other shared resources quickly. Faster asset delivery can reduce page load times across product listings, search results, and checkout pages while limiting the workload placed on ecommerce infrastructure.

CDNs also provide security controls for internet-facing stores. DDoS mitigation, web application firewalls, bot management, and rate limiting can help protect storefronts and APIs from malicious or excessive traffic before it reaches backend systems.

Video Streaming

Video platforms use CDNs to distribute streaming content from edge locations close to viewers. Caching video segments reduces the distance data travels and prevents the origin infrastructure from serving every viewer directly, which is important when thousands or millions of users watch the same content.

CDNs also support adaptive bitrate streaming technologies such as HLS and MPEG-DASH. Players request video segments at different quality levels based on available bandwidth and playback conditions, helping reduce buffering when network performance changes.

Global Enterprise Applications

Organizations with users in multiple regions can use CDNs to accelerate access to web applications, APIs, portals, and downloadable resources. Edge locations shorten the network path for cacheable content, while optimized routing and persistent connections can improve communication with centralized application servers.

CDNs can also provide a common security layer across geographically distributed traffic. TLS termination, access controls, web application firewalls, and DDoS mitigation can be applied at the edge before requests are forwarded to enterprise infrastructure.

CDN vs. Load Balancer

A CDN distributes content across geographically dispersed edge servers and directs users toward suitable locations. Its main goals are to reduce latency, cache content closer to users, and reduce traffic reaching the origin.

A load balancer distributes requests across multiple backend servers or services. Its main purpose is to prevent individual backends from becoming overloaded and to maintain availability when servers fail. CDNs may include load-balancing features, but load balancing does not by itself provide geographically distributed caching.

CDN vs. Reverse Proxy

A reverse proxy receives client requests and forwards them to one or more backend servers. It can hide origin infrastructure and perform functions such as TLS termination, authentication, compression, caching, and request filtering.

A CDN typically operates as a distributed reverse proxy across many edge locations. The main difference is scope: a reverse proxy may run in one location or environment, while a CDN uses geographically distributed infrastructure to deliver content closer to users.

CDN vs. Edge Computing

A CDN primarily focuses on delivering and caching content at distributed edge locations. Traditional CDN processing includes functions such as cache lookup, compression, TLS termination, and request filtering.

Edge computing extends this model by executing application logic close to users. Developers can use edge functions or similar services for tasks such as authentication, request transformation, personalization, and API processing. Modern CDN platforms often include edge computing, so the two technologies can be part of the same service.

CDN vs. DNS

DNS translates domain names into information clients use to locate network services, typically IP addresses. It helps users find servers but does not normally cache and deliver website resources such as images, JavaScript, or video.

A CDN delivers those resources through distributed infrastructure after DNS resolution directs traffic toward it. CDNs commonly use DNS as part of their traffic-routing process, but DNS and CDN caching operate at different layers and serve different purposes.

• Lower latency: Serving content from an edge location closer to the user reduces network travel time and can make pages and applications respond faster.
• Faster page loads: Cached images, JavaScript, CSS, fonts, and other resources can be delivered without contacting the origin for every request.
• Reduced origin load: Cache hits decrease the number of requests processed by origin servers, leaving more computing capacity for dynamic or uncached requests.
• Lower bandwidth usage: Frequently requested files are transferred from CDN caches rather than repeatedly from the origin, which can reduce origin bandwidth consumption and associated costs.

• Better handling of traffic spikes: Distributed CDN infrastructure can spread large volumes of requests across many servers and PoPs, reducing the risk of overwhelming the origin.
• Higher availability: If a server or network path becomes unavailable, a CDN can often route requests through other healthy infrastructure. Cached content may remain accessible even during some origin disruptions.
• Improved global performance: Users in different regions can access content through nearby or better-connected edge locations instead of connecting to a distant central server.
• Scalable content delivery: CDNs make it easier to serve growing audiences, large downloads, streaming media, and high-traffic applications without scaling origin infrastructure at the same rate.

Cache Configuration Errors

Incorrect cache rules can cause a CDN to cache content that should remain private or dynamic, or prevent cacheable resources from being stored. Common causes include incorrect Cache-Control headers, unsuitable TTL values, and cache keys that omit important query parameters or request headers. These errors can result in low cache hit rates, unnecessary origin traffic, or users receiving incorrect responses.

How to overcome: Cache policies should define which responses are cacheable and ensure the cache key includes every request property that can change the response.

Stale Content

Cached content can remain at edge locations after the origin has been updated. This can occur when resources have long TTL values or when content changes without corresponding cache invalidation or version changes.

How to overcome: Applications can limit stale content by using appropriate TTLs, cache revalidation, purge APIs, and versioned URLs. Versioned filenames are particularly useful for static assets because a changed URL creates a new cache entry instead of relying on existing copies to expire.

Personalized pages, authenticated responses, and frequently changing data are often unsuitable for shared caching. These requests must reach the origin or another application backend, reducing the performance benefit normally provided by CDN edge caches.

How to overcome: CDNs can still improve dynamic delivery through optimized routing, persistent origin connections, TLS reuse, and edge processing. Applications can also separate cacheable and non-cacheable data so reusable content is served from the edge while only request-specific data reaches backend systems.

DDoS Protection

CDNs can absorb distributed denial-of-service (DDoS) attacks across a large network of edge locations. Instead of sending all incoming traffic to the origin, the CDN processes requests at the edge and filters traffic before forwarding legitimate requests.

Providers can:

• Detect abnormal traffic patterns
• Block known attack sources
• Apply mitigation rules during an attack

Distributed capacity is especially useful for volumetric attacks because malicious traffic can be handled across many PoPs rather than overwhelming a single origin network.

Web Application Firewall (WAF)

A web application firewall (WAF) inspects HTTP and HTTPS requests for malicious patterns before they reach an application. It can block attacks such as:

• SQL injection
• Cross-site scripting
• Path traversal
• Attempts to exploit known application vulnerabilities

CDN WAFs commonly support managed rules as well as custom policies. Rules can evaluate properties such as URLs, headers, request methods, IP addresses, and request bodies, allowing organizations to apply security controls across traffic handled by the CDN.

Bot Management

Bot management identifies and controls automated traffic. CDNs can analyze:

• Request patterns
• Client characteristics
• Reputation data
• Other signals

This helps to distinguish legitimate automation, such as search crawlers, from credential stuffing, scraping, inventory abuse, and other unwanted activity. Responses can vary based on the detected bot and its behavior. The CDN may allow the request, rate-limit it, present a challenge, or block it entirely, reducing unwanted traffic before it consumes application resources.

TLS/SSL Encryption

CDNs commonly terminate TLS connections at edge servers, creating an encrypted HTTPS connection between the user and the CDN. A separate encrypted connection can then protect traffic between the CDN and the origin server. CDN platforms can also manage TLS certificates and support current TLS versions and cipher configurations. Because TLS termination occurs near the user, connection establishment can require less network travel than terminating every client connection at a distant origin.

Rate Limiting

Rate limiting restricts how frequently a client can access a website, API, endpoint, or other resource. Limits can be based on factors such as:

• IP address
• Request path
• Authentication information
• A defined time interval

Applying rate limits at CDN edge locations prevents excessive requests from reaching backend infrastructure. This can reduce the impact of brute-force login attempts, abusive API clients, scraping, and application-layer denial-of-service attacks.

API Protection

CDNs can protect APIs by inspecting and filtering requests before forwarding them to backend services. Controls can include:

• WAF rules
• Rate limits
• Bot detection
• IP restrictions
• Request validation
• DDoS mitigation

Some CDN platforms can also validate authentication tokens, enforce API-specific policies, or identify abnormal request patterns at the edge. These controls reduce unnecessary backend traffic and provide a security layer in front of publicly accessible API endpoints.

1. Optimize Cache Keys

A cache key determines which requests can use the same cached response. Include only request properties that change the returned content, such as selected query parameters, headers, cookies, or language settings. Unnecessary variation creates separate cache entries for equivalent responses and lowers the cache hit ratio. Missing required properties can be more serious because the CDN may serve a response generated for one request to another request that should receive different content.

Key actions:

• Include only properties that change the response.
• Remove unnecessary query parameters, headers, and cookies from cache keys.
• Include required variations such as language when they affect content.
• Monitor cache hit ratios for signs of cache fragmentation.

2. Use Long TTLs for Versioned Static Assets

Static assets with versioned or content-hashed filenames can usually use long TTL values. Files such as app.a84f2.js can remain cached for months because an updated asset is published under a different URL. This approach reduces revalidation requests and increases cache hit rates without making deployments dependent on cache expiration. HTML and other resources that reference versioned assets can use shorter caching policies when they need to reflect releases quickly.

Key actions:

• Add version numbers or content hashes to static asset filenames.
• Set long TTLs for versioned JavaScript, CSS, images, and fonts.
• Publish changed assets under new URLs instead of waiting for caches to expire.
• Use shorter cache policies for HTML and frequently updated resources.

3. Protect the Origin from Direct Access

Attackers can bypass CDN security controls if they can send traffic directly to the origin. Where possible, configure firewalls or security groups so public origin endpoints accept application traffic only from the CDN's networks or authenticated CDN connections. Origin addresses should also be kept out of unnecessary public DNS records and other exposed configuration. Additional controls such as mutual TLS or authenticated origin requests can help verify that requests reaching the origin came through the CDN.

Key actions:

• Restrict origin traffic to CDN networks where possible.
• Avoid unnecessarily exposing origin addresses in public DNS.
• Use mutual TLS or authenticated origin requests where supported.
• Configure firewalls or security groups to block direct public access.

4. Enable HTTPS Across the Delivery Path

Use HTTPS both between clients and CDN edge servers and between the CDN and origin. Encrypting only the client-to-edge connection leaves the origin connection exposed to interception or modification. Configure valid origin certificates and certificate verification rather than disabling TLS checks. Current TLS versions, automatic certificate renewal, and HTTP-to-HTTPS redirects can further simplify secure operation.

Key actions:

• Encrypt both client-to-edge and edge-to-origin connections.
• Use valid certificates and enable origin certificate verification.
• Redirect HTTP requests to HTTPS.
• Use current TLS versions and automate certificate renewal.

5. Monitor Cache Hit Ratios and Latency

Track cache hit ratios to determine how effectively the CDN is serving reusable content from edge caches. A declining hit ratio can indicate cache-key fragmentation, short TTLs, frequent invalidations, or responses that are unexpectedly marked as non-cacheable. Monitor latency at both the edge and origin as well. Metrics such as time to first byte, origin response time, error rates, and performance by region can help distinguish CDN problems from slow backend services or network issues.

Key actions:

• Track cache hit ratios for reusable content.
• Monitor edge and origin latency separately.
• Measure time to first byte, origin response time, and error rates.
• Compare performance across regions to identify localized problems.

6. Combine CDN Delivery with WAF and DDoS Protection

Use CDN delivery together with web application firewall and DDoS controls so malicious traffic can be filtered before reaching application infrastructure. WAF rules can address application-layer attacks, while DDoS mitigation provides capacity and filtering for larger traffic floods. Security policies should be tuned for the application rather than enabled without monitoring. Review blocked requests, rate-limit events, and attack logs to identify false positives and adjust rules as application behavior changes.

Key actions:

• Enable WAF and DDoS controls at the CDN edge.
• Tune security policies to normal application traffic.
• Monitor blocked requests, attacks, and rate-limit events.
• Review false positives and adjust rules as application behavior changes.

• Unified management portal: Manages both security and delivery through a single integrated platform, simplifying operations for every application.
• Best-of-breed technology: Combines advanced WAF and API security, bot management, and DDoS protection with a high-capacity global CDN.
• Global reach: Offers 750+ points of presence (PoPs) across 50+ countries and 100+ cities, delivering content from locations closest to end users.
• Unified architecture: Serves cached content from the closest location while the AI-powered platform protects the origin server from malicious requests.

• Regional edge caches and PoPs: Uses regional edge caches (RECs) situated between applications' web servers and PoPs, with PoPs located within the AWS network and peering with ISP networks.
• Single SSL key: Simplifies deployment by using a single SSL key common to both CDN and protection services.
• Redundant infrastructure: Uses 400GbE parallel fibers to provide full redundancy.
• Managed services and support: Ensures security and availability through expert managed services and a 24/7 Emergency Response Team (ERT).