How CDN Architecture Boosts Performance, Security, and Cost Efficiency

With the rapid growth of the Internet in China and the limitations caused by differing policies of telecom operators, users often experience poor performance on the last mile. Frequent hacker attacks such as penetration and DDoS further threaten website security. The fundamental solution for application service providers is to fully utilize a Content Delivery Network (CDN).

CDN Role

Cache Proxy

A cache proxy acts as a transparent mirror of the origin data center, storing content on edge servers. Intelligent DNS directs user requests to the nearest provincial backbone node, minimizing transmission distance and ensuring fast response regardless of location or ISP.

By placing node servers across the network, the source site’s topology remains unchanged while smart routing and proximity matching deliver stable, high‑speed content.

Routing Acceleration

CDN originally ensures rapid delivery of static content. For dynamic content, which requires long‑lived connections, CDN can pre‑configure optimal routes—such as provincial backbone networks and dual‑line data centers—to improve user experience, especially for online gaming in China.

Security Protection

When a CDN is properly used, attacks like penetration or DDoS are directed at the CDN layer, shielding the origin server. Because the CDN is distributed, it disperses attack traffic, greatly reducing the impact on the source. CDN can also provide pre‑emptive security functions such as blocking SQL injection, XSS, site defacement, and data tampering.

Cost Savings

CDN nodes can be deployed in single‑line carrier facilities or cities with cheaper bandwidth, lowering procurement costs. Offloading traffic to CDN reduces peak bandwidth demand on the origin, allowing smaller backend servers and reducing both hardware and operational expenses.

Thus, building a distributed CDN service is essential for delivering optimal experience to users across different regions and ISPs.

CDN Architecture

Storage Media vs. I/O

SSD uses electronic storage, eliminating mechanical bottlenecks and offering high read performance. When selecting SSDs, consider price, capacity (e.g., 120 GB, 160 GB, 300 GB) and whether they meet design requirements.

Author recommendation: If possible, use SSDs to trade space for performance.

Choose EXT4 with TRIM mode ( mount -o defaults,noatime,nodiratime,barrier=0,discard); avoid Btrfs for production.

For Samsung SSDs, consider the open‑source F2FS file system.

Use CFQ or Deadline I/O schedulers.

Kernel tweak:

echo 0 > /sys/block/sda/queue/rotational

Random vs. Sequential I/O

Mechanical disks excel at sequential reads but perform poorly on random I/O due to head movement latency. SSDs eliminate seek time, delivering sub‑millisecond latency for random reads, which is critical for small files and OLTP databases.

Large Files vs. Small Files

Traditional storage systems are optimized for large files; handling many small files incurs metadata overhead, fragmented reads, and reduced I/O efficiency.

Author notes:

Prefer EXT4 for both large and small files; avoid ReiserFS/Btrfs unless necessary.

EXT4 improves small‑file locality via inode pre‑allocation.

EXT4 uses extents and delayed allocation for large files, boosting throughput.

XFS performs well with large files.

SSD is ideal for random small‑file workloads.

Advanced users may adopt LevelDB or other KV stores as a custom file system.

Hardware Benefits vs. Software Design

Hardware upgrades have outpaced Moore's Law, offering multi‑core CPUs and large memory capacities at similar prices, making timely hardware refresh essential.

Legacy software like Squid suffers from single‑core limitations and lacks modern features, whereas newer solutions (e.g., Nginx, Varnish, HAProxy) better exploit multi‑core CPUs and memory.

System Optimization

Simplify system services.

Fine‑tune file‑system performance.

Improve disk I/O.

Optimize network parameters.

Refine routing strategies.

Database tuning.

CDN Open Source Solutions

Open‑source software can serve as reverse proxy and cache layers. Typical functional layers include:

Reverse proxy (routing acceleration, hide origin, load balancing).

Cache acceleration (static content push, reduce origin bandwidth).

Attack defense (fast parsing, malicious traffic filtering).

When selecting software, compare performance, features, and configurability:

Squid: multi‑core limitation, decent disk cache.

Varnish: strong performance, memory cache, multi‑core support.

Nginx: multi‑core, plugin extensibility, good performance.

Apache Traffic Server: strong performance, disk/memory cache.

HAProxy: multi‑core, no cache, excellent HTTP header parsing and DDoS handling.

Key observations:

HAProxy consumes only 10‑20% CPU for large‑scale CC attacks, while other software may exceed 90%.

Varnish offers the best pure forwarding performance; ATS and Nginx follow.

HAProxy, ATS, and Squid support external rule files and hot reload; Nginx lacks external regex loading but remains highly extensible.

Load Balancing – High Availability: LVS

LVS provides a heavyweight, efficient Layer‑4 forwarding solution that can be placed before Layer‑7 proxies, ensuring high availability when combined with Keepalived or Heartbeat.

-----The End-----