Globally distributed applications operate with the expectation of sub-second response times, regardless of where the request originates. Meeting that expectation across a worldwide user base is constrained by physics; the round-trip time between a user in São Paulo and an origin in Frankfurt is bounded by the speed of light through fibre, and by the operational realities of internet routing, last-mile congestion, TLS handshake overhead, and origin server capacity.
The delivery problem can be decomposed into two distinct workloads. Static assets: images, scripts, stylesheets, and video segments are cacheable and can be served from infrastructure physically close to the user. Dynamic content API responses, personalised pages, and real-time data cannot be cached because each request requires evaluation at the origin, but the round trip to that origin can still be optimised through routing, protocol, and connection-layer engineering. A complete delivery architecture addresses both workloads with the technique appropriate to each rather than forcing one approach onto incompatible content types.
Alibaba Cloud provides two services that correspond to these workloads. CDN handles cache-based acceleration for static and streaming content. DCDN extends the same edge platform with route, connection, and compute optimisations designed for dynamic and mixed workloads. The sections below document how each service is structured, the configuration parameters that shape its behaviour, and the operational factors that govern reliability at production scale.
Figure 1. Reference architecture for static and dynamic content delivery on Alibaba Cloud.
Alibaba Cloud CDN works through a global network of edge nodes traversing mainland China, the wider Asia-Pacific region, Europe, the Middle East, the Americas, and Africa. Client requests are headed to the nearest performant node through a combination of DNS-based geolocation and anycast routing, with health and load metrics factored into the selection rather than physical distance alone.
Content is served from a three-tier cache hierarchy. L1 edge nodes terminate the client connection and serve cached objects directly. On a cache miss, the request escalates to an L2 parent node, which aggregates demand from multiple edges and absorbs the bulk of upstream traffic. Persistent misses fall through to the origin, optionally fronted by a shield node that consolidates all origin-bound traffic for a given resource. This hierarchy allows a single popular asset to be retrieved from the origin once and served to many edges, rather than each edge fetching independently.
Transport runs on HTTP and HTTPS ports 80 and 443, with HTTP/2 enabled by default on TLS connections and HTTP/3 over QUIC available on UDP 443 for clients that negotiate it. TLS 1.2 and TLS 1.3 are supported, with session resumption and OCSP stapling reducing handshake overhead on repeat visits. Brotli and gzip compression are applied at the edge based on the Accept-Encoding header. Under default quality settings, Brotli typically produces 15–25% smaller payloads than gzip on text-based content.
Cache behaviour is governed by the cache key, the TTL configuration, and the origin response headers. A cache key built from the host, path, and a curated allowlist of query parameters produces a higher hit ratio than one that includes every query string by default; over-broad cache keys are a frequent cause of low cache efficiency on URL-parameterised endpoints. TTL rules can be set per file extension, per directory, or per response code, allowing short-lived HTML to coexist with long-lived static assets in the same distribution. The Refresh and Prefetch APIs allow operators to invalidate stale paths or warm caches ahead of an expected traffic event without waiting for natural expiry.
Where CDN optimises delivery by caching, DCDN optimises delivery by shortening and stabilising the path between the edge and the origin for content that cannot be cached. The service extends the same edge node footprint with three additional capabilities: dynamic route optimisation, connection-layer enhancements, and edge compute.
Dynamic Route Optimisation continuously measures latency, loss, and jitter across multiple network paths between edge nodes and the origin, then selects the best-performing route for each request rather than relying on default BGP. By routing around congested or lossy paths that default routing would not avoid, DRO is designed to improve P95 latency on long-haul transcontinental routes; the magnitude of improvement is workload-dependent and is best measured against the specific origin and user populations of the deployment.
Connection-layer optimisations apply at the TCP and TLS levels. Long-lived, multiplexed connections are maintained between edge nodes and the origin, eliminating the per-request three-way handshake and TLS negotiation that would otherwise dominate latency for short API responses. TCP Fast Open is supported where the origin permits it, and BBR congestion control is used on edge-to-origin links to maintain throughput on lossy paths where traditional loss-based algorithms underperform. WebSocket and gRPC traffic are accelerated through the same connection plane, making DCDN applicable to real-time and bidirectional workloads in addition to conventional request-response APIs.
EdgeRoutine extends DCDN with programmable compute at the edge. JavaScript functions running on a V8 runtime execute per request, enabling rewrites, authentication checks, A/B routing, personalisation, and request aggregation to be handled without a round trip to the origin. Function execution typically completes within single-digit milliseconds and is suited to lightweight, stateless logic; heavier or stateful processing remains at the origin or is delegated to a dedicated compute service.
CDN and DCDN function as the edge enforcement point between the public internet and the origin. Anti-DDoS Basic protection is available at the edge and absorbs volumetric attacks at the network layer before they reach the origin infrastructure. Anti-DDoS Premium and Web Application Firewall integrate with the same distributions, providing layer 7 inspection, rule-based filtering, and rate limiting against application-layer attacks.
Origin protection is enforced through a combination of mechanisms. Hotlink protection restricts which Referer headers, IP ranges, or User-Agent strings are allowed to fetch content from the distribution. Signed URLs add a time-bound token to sensitive resources, computed using an HMAC signature over the path, expiry timestamp, and a shared secret. A typical signed URL takes the form:
https:.//cdn.example.com/file.zip?auth_key=---
The edge node recomputes the hash on request and serves the resource only if the signature matches and the timestamp has not expired. This pattern is applicable to paid content, software downloads, and pre-signed upload flows. Private origin authentication ensures the origin only accepts traffic from CDN or DCDN nodes, blocking direct access by IP or hostname.
HTTPS enforcement is configured at the distribution level, with automatic HTTP-to-HTTPS redirect, HSTS header injection, and certificate provisioning managed through SSL Certificate Service. Certificates issued by SSL Certificate Service are deployed to edge nodes without manual file handling, and renewal can be automated through certificate binding.
Four operational factors determine whether a CDN or DCDN deployment performs reliably under production load.
Static and dynamic content require different acceleration techniques, and a complete global delivery architecture applies each technique to the workload it suits. Alibaba Cloud CDN provides cache-based delivery for static and streaming assets through a tiered edge architecture, modern transport protocols, and configurable cache behaviour. DCDN extends the same edge footprint with dynamic route optimisation, connection multiplexing, and programmable edge compute for content that cannot be cached. Both services integrate with the same security, certificate, logging, and identity infrastructure, allowing a single delivery layer to handle mixed workloads under unified operational tooling.
Engineers extending a delivery architecture should evaluate three patterns based on their workload. CDN alone covers workloads where the majority of traffic is cacheable static and streaming content. DCDN suits workloads where API responses, personalised content, or real-time channels dominate the traffic profile. A combined deployment CDN for static asset domains and DCDN for the application and API domains matches the two-workload structure typical of full-stack web applications.
Disclaimer: The views expressed herein are for reference only and don’t necessarily represent the official views of Alibaba Cloud.
Event-Driven Architecture on Alibaba Cloud with EventBridge and Function Compute
91 posts | 2 followers
FollowAlibaba Clouder - April 20, 2021
JDP - November 19, 2021
Alibaba Clouder - June 23, 2020
Alibaba Clouder - March 30, 2021
Alibaba Clouder - July 16, 2021
Alibaba Clouder - January 18, 2021
91 posts | 2 followers
Follow
Link IoT Edge
Link IoT Edge allows for the management of millions of edge nodes by extending the capabilities of the cloud, thus providing users with services at the nearest location.
Learn More
Edge Node Service
An all-in-one service that provides elastic, stable, and widely distributed computing, network, and storage resources to help you deploy businesses on the edge nodes of Internet Service Providers (ISPs).
Learn More
CDN(Alibaba Cloud CDN)
A scalable and high-performance content delivery service for accelerated distribution of content to users across the globe
Learn More
Edge Security Acceleration (Original DCDN)
Edge Security Acceleration (ESA) provides capabilities for edge acceleration, edge security, and edge computing. ESA adopts an easy-to-use interactive design and accelerates and protects websites, applications, and APIs to improve the performance and experience of access to web applications.
Learn MoreMore Posts by PM - C2C_Yuan
