Taicheng's Profile

Cloud CDN

Cloud CDN is Google Cloud’s web acceleration Content Delivery Network platform that helps you cache regularly accessed static content closer to your users. Cloud CDN is optimized for serving a mix of static and dynamic latency-sensitive web assets, such as CSS, JavaScript, HTML, and image files.

Media CDN is Google Cloud’s media delivery CDN platform that complements Cloud CDN. Media CDN is optimized for high-throughput egress workloads such as streaming video and large file downloads.

Using Cloud CDN and Media CDN can improve performance for your users, lower your origin infrastructure resource usage, and reduce your network delivery costs.

The two products support a similar set of features, but each product is optimized for certain use cases. Comparing Cloud CDN to Media CDN is similar to comparing Cloud SQL to BigQuery. Cloud CDN and Cloud SQL are for small queries at scale. Media CDN and BigQuery are designed for throughput and extreme scale. Using Media CDN for serving JavaScript or CSS (web workloads) is similar to trying to use BigQuery for 5-GB tables with a few thousand rows. It works, but it’s not optimized for that use case.

Let’s consider an example to understand how Cloud CDN works:

  • When a user makes a request to your website or app, the request is routed to the closest Google edge node (we have over 120 of these!) for fast and reliable traffic flow. From there the request gets routed to the global HTTPS Load Balancer to the backend or origin.
  • With Cloud CDN enabled, the content gets directly served from the cache — a group of servers that store and manage cacheable content so that future requests for that content can be served faster.
  • The cached content is a copy of cacheable web assets (JavaScript, CSS), images, video, and other content that is stored on your origin servers.
  • Cloud CDN automatically caches this content when you use the recommended “cache mode” to cache all static content. If you need more control, you can direct Cloud CDN by setting HTTP headers on your responses. You can also force all content to be cached; just know that this ignores the “private,” “no-store,” or “no-cache” directives in Cache-Control response headers.
  • When the request is received by Cloud CDN, it looks for the cached content using a cache key. This is typically the URI, but you can customize the cache key to remove protocol, hosts, or query strings.
  • If a cached response is found in the Cloud CDN cache, the response is retrieved from the cache and sent to the user. This is called a cache hit. When a cache hit occurs, Cloud CDN looks up the content by its cache key and responds directly to the user, shortening the round-trip time and reducing the load on the origin server.
  • The first time that a piece of content is requested, Cloud CDN can’t fulfill the request from the cache because it does not have it in cache. This is called a cache miss. When a cache miss occurs, Cloud CDN might attempt to get the content from a nearby cache. If the nearby cache has the content, it sends it to the first cache by using cache-to-cache fill. Otherwise, it just sends the request to the origin server.
  • The maximum lifetime of the object in a cache is defined by the TTLs, or time-to-live values, set by the cache directives for each HTTP response or cache mode. When the TTL expires, the content is evicted from cache.

By default, Cloud CDN will cache static content – including web assets and video files – that are not explicitly marked as private for the configured default time to live (TTL), without requiring any changes at your origin.

If you decide to use the Cache-Control headers, Cloud CDN will only cache responses with valid cache directives contained in the HTTP response header.

Invalidating a pattern before the TTL expiration:

Use the gsutil setmeta command to apply Cache-Control headers to a specific object.

gsutil setmeta -h "Cache-Control: private, no-cache" gs://your-bucket-name/your-object-name

➜  stuff curl -I http://34.117.35.80/cdn.png

HTTP/1.1 200 OK
date: Sat, 23 Nov 2024 01:42:59 GMT
cache-control: private, no-cache
expires: Sun, 23 Nov 2025 01:42:59 GMT
last-modified: Sat, 23 Nov 2024 00:51:38 GMT
etag: "f798c12ac77d1be173e6d13ffb4fa3a8"
x-goog-generation: 1732323098687904
x-goog-metageneration: 5
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 307676
content-type: image/png
x-goog-hash: crc32c=eit3hQ==
x-goog-hash: md5=95jBKsd9G+Fz5tE/+0+jqA==
x-goog-storage-class: STANDARD
accept-ranges: bytes
Content-Length: 307676
x-guploader-uploadid: AFiumC75bXg036ErLq2O7hbdm-Rx_QHKo9byXxOlVuAasD4p7bvNtSueZULTF2Mvawj1kcFQKWgB0n8VyQ
server: UploadServer
via: 1.1 google

gsutil defstorageclass set <storage-class> -h "Cache-Control: private, no-cache" gs://your-bucket-name

Preventing caching

To prevent private information from being cached in Cloud CDN caches, do the following:

  1. Make sure that Cloud CDN cache mode isn’t set to the FORCE_CACHE_ALL mode, which unconditionally caches all successful responses.
  2. Include a Cache-Control: private header in responses that shouldn’t be stored in Cloud CDN caches, or a Cache-Control: no-store header in responses that shouldn’t be stored in any cache, even a web browser’s cache.
  3. Don’t sign URLs that provide access to private information. When content is accessed by using a signed URL, it is potentially eligible for caching regardless of any Cache-Control directives in the response.
  4. For origin (cache fill) requests that include the Authorization request header, Cloud CDN only caches responses that include the public, must-revalidate, or s-maxage cache control directives when the cache mode is set to USE_ORIGIN_HEADERS or CACHE_ALL_STATIC. This prevents accidentally caching per-user content and content that requires authentication. The FORCE_CACHE_ALL cache mode does not have this restriction.

If Cache-Control: no-store or private is present, but the content is still being cached, this is due to one of the following:

  • URL signing is configured.
  • The Cloud CDN cache mode is set to force caching of all responses.

By default, when an object is public and doesn’t specify Cache-Control metadata, Cloud Storage assigns a Cache-Control: public, max-age=3600 header to the object. You can set different values by using Cache-Control metadata.

Taicheng