Evolution of Static Resource Infrastructure and CDN Practices at Ctrip

1. Origin of Static Resources

Static resources have been a core part of the Web since its inception, but their delivery architecture changed little for decades, evolving from simple HTML pages to complex static assets served alongside dynamic content.

2. Defining Static Resources

From a client perspective, a static resource typically (1) has a fixed URL, (2) is fetched with safe HTTP methods (GET/HEAD/OPTIONS), (3) carries a specific Content‑Type (e.g., image/*, text/*), and (4) is context‑independent, though real‑world exceptions such as polyfills exist.

3. The Necessity of CDN

CDN (Content Delivery Network) reduces latency by caching content at edge nodes close to users. Originating from Akamai’s edge‑caching model, CDNs have become essential for improving QoE, especially for static assets.

4. Migration from Legacy Infrastructure

Earlier Ctrip static services used Windows/IIS/ASP. A simple ASP example demonstrated the ease of creating a dynamic page:

<%Response.write "Hello world!" %>

Later migrations replaced Windows with CentOS, IIS with Nginx, and introduced Ansible for configuration management.

5. URL Case‑Sensitivity Issues

Linux’s case‑sensitive file system caused 404 errors for mixed‑case URLs. The workaround duplicated files in a lower‑case fallback directory and used Nginx internal redirects to serve the correct file.

6. Online Resource Concatenation (res‑concat)

To reduce request overhead, an online concatenation service ( /res/concat ) merges existing static files on the fly without requiring build‑time bundling, leveraging Nginx modules and Protocol Buffers for communication.

7. Impact of HTTP/2

HTTP/2’s multiplexing and header compression (HPACK) diminish the need for manual concatenation, as multiple resources can be fetched concurrently over a single connection.

8. Cache Invalidation Challenges

Cache‑busting strategies such as versioned filenames, fingerprinting, and CDN purge APIs are discussed, along with the limitations of full‑directory updates and the importance of avoiding stale assets.

9. Cloud Storage Integration

Ctrip adopted Ceph (private cloud) and later added Aliyun OSS and AWS S3, exposing SDKs (ceph, ceph‑sync, ceph‑cli, ceph‑agent) to store and synchronize billions of static files.

10. Internationalization and Multi‑CDN Strategy

To serve a global user base, Ctrip deployed edge‑origin nodes in multiple regions (AWS Frankfurt, Montreal, Singapore) and implemented a dynamic URL‑generation API that selects the optimal CDN based on client IP, mitigating DNS‑based CDN mis‑routing.

11. Future Outlook

While HTTP/2/3 and 5G will further improve transport efficiency, the article questions whether static‑resource‑centric architectures will remain relevant as bandwidth grows and edge computing evolves.

12. ARES Naming

Internally, the static‑resource platform is codenamed ARES (an acronym for “A‑class Web Resource Solution”).