캐싱 개요

캐시 가능한 응답은 Cloud CDN이 저장하고 빠르게 검색할 수 있으므로 로드 시간을 더 빠르게 할 수 있는 HTTP 응답입니다. 모든 HTTP 응답을 캐시할 수 있는 것은 아닙니다.

캐시 모드

캐시 모드를 사용하면 Cloud CDN이 콘텐츠를 캐시하는지 여부를 결정하는 요소를 제어할 수 있습니다.

캐시 모드의 베타 출시 버전을 통해 백엔드(원본)에서 Cloud CDN을 사용 설정하면 Google Cloud는 no-store, private 또는 no-cache 지시문이 없는 정적 콘텐츠를 자동으로 캐시합니다.

원하는 경우 private, no-store 또는 no-cache 지시문에 관계없이 원본이 항상 모든 콘텐츠를 캐시하도록 설정할 수 있습니다.

Cloud CDN을 이미 사용 설정한 기존 원본의 경우 동작은 변경되지 않습니다. 즉, 유효한 캐시 지시문과 유효한 캐싱 헤더가 있는 경우에만 콘텐츠가 캐시됩니다.

설정 안내는 캐시 모드 설정을 참조하세요.

정적 콘텐츠

정적 콘텐츠는 다른 사용자가 액세스하더라도 항상 동일한 콘텐츠입니다. 사이트 스타일을 지정하는 데 사용하는 CSS, 대화형 작업, 동영상, 이미지 콘텐츠를 제공하는 자바스크립트는 일반적으로 지정된 URL의 각 사용자에 변경되지 않습니다(캐시 키). 따라서 Cloud CDN의 전역 에지 네트워크에서 캐시함으로써 이점을 얻을 수 있습니다.

모든 정적 콘텐츠를 캐시하도록 캐시 모드를 설정하면 Cloud CDN은 다음에 대한 응답을 자동으로 캐시합니다.

  • CSS(text/css), 자바스크립트(application/javascript) 및 WOFF2(font/woff2)가 포함된 모든 웹 글꼴을 포함한 웹 애셋
  • JPEG(image/jpg) 및 PNG(image/png)를 포함한 이미지
  • H.264, H.265, MP4(video/mp4)를 포함한 비디오 파일 + MP3(image/mpeg) 및 MP4(audio/mp4)를 포함한 오디오 파일
  • PDF(application/pdf)를 포함한 서식이 지정된 문서

다음 표는 요약 정보입니다.

카테고리 MIME 유형
웹 애셋 text/css text/ecmascript text/javascript application/javascript
글꼴 font/*와 일치하는 모든 Content-Type
이미지 image/*와 일치하는 모든 Content-Type
동영상 video/*와 일치하는 모든 Content-Type
오디오 audio/*와 일치하는 모든 Content-Type
서식이 지정된 문서 유형 application/pdf, application/postscript

Cloud CDN은 제공되는 콘텐츠의 MIME 유형을 반영하는 Content-Type HTTP 응답 헤더를 검사합니다.

다음에 유의하세요.

  • 원본의 웹 서버 소프트웨어는 응답마다 Content-Type을 설정해야 합니다. 많은 웹 서버가 NGINX, Varnish, Apache를 포함한 Content-Type 헤더를 자동으로 설정합니다.

  • Cloud Storage는 Cloud Console이나 gsutil 도구를 사용하여 콘텐츠를 업로드하면 Content-Type 헤더를 자동으로 업로드하도록 설정합니다.

  • MIME 유형에 따라 응답을 캐시할 수 있지만 private, no-store 또는 no-cache 헤더의 Cache-Control 응답 헤더나 Set-Cookie 헤더가 있으면(전체 규칙 목록 참조) 응답이 캐시되지 않습니다.

캐시할 수 있는 유효한 많은 응답에서 URL을 반영하지 않으므로 Cloud CDN은 파일 확장자를 사용하여 응답에서 캐시할 수 있는지 여부를 확인하지 않습니다.

text/htmlapplication/json 콘텐츠 유형을 캐시하려면 응답에 명시적 Cache-Control 헤더를 설정해야 합니다. 그러면 사용자 데이터 하나를 실수로 캐시하여 모든 사용자에게 제공되지 않도록 주의합니다.

캐시 가능한 콘텐츠

Cloud CDN은 이 섹션의 모든 요구 사항을 충족하는 응답만을 캐시합니다. 이러한 요구 사항 중 일부는 RFC 7234에 명시되어 있으며, 다른 일부는 Cloud CDN에만 해당합니다.

다음 사항에 모두 해당되는 경우에만 Cloud CDN 캐시에 응답을 저장할 수 있습니다.

속성 요구사항
제공 백엔드 서비스, 백엔드 버킷, Cloud CDN이 사용 설정된 커스텀 원본
다음에 대한 응답 GET 요청
상태 코드 200, 203, 206, 300, 301, 302, 307, 410
캐시 지시문 use-origin-headers를 사용하면 응답에 public 지시문이 있는 Cache-Control 헤더가 있어야 합니다.

cache-all-static 캐시 모드를 사용하면 응답에는 public 지시문이 있는 Cache-Control 헤더나 정적 콘텐츠 유형 하나가 있어야 합니다.

force-cache-all 캐시 모드를 사용하면 응답은 항상 캐시할 수 있습니다.
최신 정보 use-origin-headers 캐시 모드를 사용하면 max-age 또는 s-maxage 지시문이 있는 Cache-Control 헤더나 향후에 타임스탬프가 있는 Expires 헤더가 있습니다.

cache-all-static 캐싱 모드를 사용하면 정적 콘텐츠를 전달하는 모든 백엔드 응답은 새롭거나 비정적 콘텐츠로 간주됩니다. 최신 여부는 원본 헤더를 기준으로 합니다.

force-cache-all 캐시 모드를 사용하면 모든 백엔드 응답이 새로운 응답으로 간주됩니다.
콘텐츠

유효한 Content-Length, Content-Range 또는 Transfer-Encoding 헤더가 포함되어 있음

예를 들어 Content-Length 헤더는 응답 크기와 정확하게 일치함

크기 최대 크기 이하

Cloud Storage 백엔드 버킷의 경우 다음과 같은 여러가지 방법으로 이러한 요구사항을 충족할 수 있습니다.

기본적으로 전체 버킷이 공개되어 있거나 개별 객체가 공개되고 개별 객체가 Cache-Control 메타데이터를 지정하지 않으면 Cloud Storage는 객체를 Cache-Control: public, max-age=3600 헤더 하나에 할당합니다. Cache-Control 메타데이터를 사용하여 다른 값을 설정할 수 있습니다.

백엔드 버킷으로 외부 HTTP(S) 부하 분산기를 구성하는 방법에 대한 예시는 백엔드 버킷으로 Cloud CDN 설정을 참조하세요.

최대 크기

Cloud CDN은 각 응답에 최대 크기를 적용합니다. 최대 크기보다 큰 본문에 대한 응답은 캐시되지 않지만 여전히 클라이언트에게 전송됩니다.

최대 크기는 원본 서버의 바이트 범위 요청 지원 여부에 따라 달라집니다.

원본 서버가 바이트 범위 요청을 지원함 원본 서버가 바이트 범위 요청을 지원하지 않음
5TB(5,497,558,138,880바이트) 10MB(10,485,760바이트)

거의 모든 최신 웹 서버(NGINX, Apache, Varnish 포함)는 바이트 범위 요청을 지원합니다.

원본 헤더를 기준으로 캐시할 수 없는 콘텐츠

응답의 캐싱을 차단하는 검사가 있습니다.

응답이 캐시 가능 콘텐츠의 요구사항을 충족하지 않거나 다음 중 하나에 해당하는 경우 캐시되지 않습니다.

속성 요구사항
제공 Cloud CDN이 사용 설정되지 않은 커스텀 원본이나 백엔드 서비스, 백엔드 버킷
쿠키 Set-Cookie 헤더가 있음
Vary 헤더 Accept, Accept-Encoding 또는 Origin 이외의 값
응답 지시문 응답에 no-store, no-cache 또는 private 지시문이 있는 Cache-Control 헤더가 있습니다. 이 경우 force-cache-all Cache 모드를 사용하지 않으면 cache-control 헤더는 무시됩니다.
요청 지시문 요청에 Cache-Control: no-store 헤더가 있음
크기 최대 크기보다 큼

이러한 요구 사항은 추후에 보다 완화되어 Cloud CDN에서 추가 응답을 캐시할 수 있게 될 수 있습니다.

Cache-Control: no-store, no-cache 또는 private가 있지만 콘텐츠가 여전히 캐시되고 있으면 다음 중 하나가 원인일 수 있습니다.

  • URL 서명이 구성되었습니다.
  • Cloud CDN 캐시 모드는 모든 응답을 강제 캐시하도록 설정됩니다.

캐싱 방지

개인 정보가 Cloud CDN 캐시에 캐시되지 않도록 방지하려면 다음 단계를 따릅니다.

  1. Cloud CDN 캐시 모드가 모든 응답을 무조건 캐시하는 force-cache-all 모드로 설정되어 있지 않은지 확인합니다.
  2. Cloud CDN 캐시에 저장하지 않아야 할 응답에는 Cache-Control: private 헤더를 포함하고, 웹 브라우저의 캐시를 포함한 모든 캐시에 저장하지 않아야 할 응답에는 Cache-Control: no-store 헤더를 포함합니다.
  3. 개인 정보에 대한 액세스를 제공하는 URL에 서명하지 않습니다. 서명된 URL을 사용하여 콘텐츠에 액세스하는 경우 응답의 Cache-Control 지시문에 관계없이 잠재적으로 캐시할 수 있습니다.

커스텀 응답 헤더 추가

커스텀 응답 헤더를 사용하면 외부 HTTP(S) 부하 분산기가 프록시 응답에 추가하는 헤더를 지정할 수 있습니다. 커스텀 응답 헤더를 사용하면 클라이언트, 클라이언트 지리 데이터, 고유한 정적 응답 헤더에 캐시 상태를 반영할 수 있습니다.

헤더 목록은 '커스텀 헤더 만들기' 페이지의 헤더 값에 표시될 수 있는 변수를 참조하세요.

자세한 내용은 커스텀 응답 헤더 작업을 참조하세요.

캐시 키

Cloud CDN 캐시의 각 캐시 항목은 캐시 키로 식별됩니다. 캐시에 요청이 들어오면 캐시가 요청의 URI를 캐시 키로 변환한 후 캐시된 항목의 키와 비교합니다. 일치하는 키가 발견되면 캐시는 해당 키와 연관된 객체를 반환합니다.

백엔드 서비스의 경우 Cloud CDN은 기본적으로 전체 요청 URI를 캐시 키로 사용합니다. 예를 들어 https://example.com/images/cat.jpgcat.jpg 객체의 특정 요청에 대한 전체 URI입니다. 이 문자열은 기본 캐시 키로 사용됩니다. 정확히 이 문자열이 있는 요청만 일치합니다. http://example.com/images/cat.jpg 또는 https://example.com/images/cat.jpg?user=user1에 대한 요청은 일치하지 않습니다.

캐시 키에서 사용되는 URI 부분을 변경할 수 있습니다. 파일 이름과 경로는 항상 키의 일부여야 하지만 캐시 키 맞춤설정 시 프로토콜, 호스트, 쿼리 문자열의 조합을 포함하거나 생략할 수 있습니다. 캐시 키 사용에서는 캐시 키를 맞춤설정하는 방법을 설명합니다.

URI 부분 맞춤설정 캐시 키가 동일한 URL의 예시
프로토콜 캐시 키에서 프로토콜을 생략합니다.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
호스트 캐시 키에서 호스트를 생략합니다.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
쿼리 문자열

캐시 키에서 쿼리 문자열을 생략합니다.

쿼리 문자열의 일부를 선택적으로 생략하거나 포함합니다.

  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

전체 쿼리 문자열을 포함하거나 제외하는 것 외에 포함 목록 및 제외 목록을 사용하여 쿼리 문자열 일부를 사용할 수 있습니다.

백엔드 버킷의 경우 캐시 키는 프로토콜, 호스트, 쿼리 문자열이 없는 URI로 구성됩니다.

따라서 특정 백엔드 버킷의 경우 다음 URI가 동일한 캐시된 객체로 확인됩니다.

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

쿼리 문자열 포함 목록

Cloud CDN이 캐시 키에 포함되는 쿼리 문자열 매개변수를 선택적으로 제어할 수 있습니다. 예를 들어 user의 포함 목록을 만들면 https://example.com/images/cat.jpg?user=user1&color=bluehttps://example.com/images/cat.jpg?user=user1&color=red와 일치하는 https://example.com/images/cat.jpg?user=user1 캐시 키를 만듭니다.

이 옵션을 사용하려면 쿼리 문자열을 포함하고 비어 있지 않은 포함 목록을 지정하고 제외 목록을 지정하면 안 됩니다.

쿼리 문자열 제외 목록

제외 목록을 사용하여 Cloud CDN이 무시하는 쿼리 문자열 매개변수를 선택적으로 제어할 수 있습니다. 예를 들어 user 제외 목록을 만들면 user제외한 모든 쿼리 문자열 매개변수가 캐시 키에 사용됩니다.

제외 목록이 구성되고 입력이 https://example.com/images/cat.jpg?user=user1&color=blue이면 Cloud CDN은 https://example.com/images/cat.jpg?user=user2&color=blue와 일치하지만 https://example.com/images/cat.jpg?user=user1&color=red와는 일치하지 않는 https://example.com/images/cat.jpg?color=blue의 캐시 키를 만듭니다.

이 옵션을 사용하려면 쿼리 문자열을 포함하고 비어 있지 않은 제외 목록을 지정해야 하며 포함 목록을 지정하면 안 됩니다.

Vary 헤더

Vary 헤더는 클라이언트 요청 헤더에 따라 응답이 달라짐을 나타냅니다. 요청 URI 이외에도 Cloud CDN은 원본 서버가 응답에 포함하는 Vary 헤더를 고려합니다. 예를 들어 응답에서 Vary: Accept를 지정하면 Cloud CDN은 Accept: image/webp,image/*,*/*;q=0.8을 지정하는 캐시 요청에 캐시 항목 하나를 사용하고 Accept: */*를 지정하는 요청에 다른 하나를 사용합니다.

캐시할 수 없는 콘텐츠 섹션의 표에는 콘텐츠가 캐시할 수 있는 Vary 헤더가 나와 있습니다. 다른 Vary 헤더 값은 콘텐츠가 캐시되지 않도록 합니다.

Vary 헤더는 간혹 압축된 콘텐츠를 제공하는 경우에 사용됩니다. Cloud CDN은 응답 자체를 압축하거나 압축 해제하지 않지만 원본 서버가 압축한 응답을 제공할 수 있습니다. 원본 서버가 압축 또는 압축되지 않은 콘텐츠를 제공할지 여부를 Accept-Encoding 요청 헤더의 값에 따라 선택하는 경우 응답이 Vary: Accept-Encoding을 지정하는지 확인합니다.

만료 시간 및 유효성 검사 요청

use-origin-headers 캐시 모드를 사용하면 Cloud CDN 캐시의 각 캐시 항목에는 RFC 7234에 따라 Cache-Control: s-maxage, Cache-Control: max-age 또는 Expires 헤더에서 정의된 만료 시간이 있습니다. 만료 시간이 두 개 이상 있으면 Cache-Control: s-maxageCache-Control: max-age보다 우선시되고 Cache-Control: max-ageExpires보다 우선시됩니다.

cache-all-static 캐싱 모드를 사용하면 정적 콘텐츠를 전달하는 모든 백엔드 응답은 새롭거나 비정적 콘텐츠로 간주됩니다. 최신 여부는 원본 헤더를 기준으로 합니다

force-cache-all 캐시 모드를 사용하면 모든 백엔드 응답이 새 응답으로 간주됩니다.

Cloud CDN이 요청을 받으면 해당 캐시 항목을 조회하고 저장 기간을 확인합니다. 캐시 항목이 존재하고 새 항목이면 캐시에서 응답을 제공할 수 있습니다. 그러나 만료 시간이 경과하면 Cloud CDN은 백엔드 중 하나에 먼저 연락하지 않고 응답을 제공할 수 없습니다.

Cloud CDN은 30일이 지난 캐시된 객체의 유효성을 다시 확인합니다. 이렇게 하면 사용자가 생성한 비활성 캐시 콘텐츠를 자동으로 무효화하고 제거할 수 있습니다. max-age 또는 s-maxage 값이 30일(2,592,000초)을 초과하면 Cloud CDN은 해당 값을 2,592,000초로 보고 처리합니다. 30일을 초과하더라도 다운스트림 클라이언트는 여전히 max-ages- maxage의 정확한 값을 볼 수 있습니다.

이전에 캐시된 응답에 Last-Modified 또는 ETag 헤더가 있으면 Cloud CDN은 헤더의 정보를 사용하여 백엔드의 캐시 항목을 확인하려고 할 수 있습니다. Cloud CDN은 응답이 바이트 범위 요청을 사용하여 캐시되었는지 여부에 따라 이 유효성 검사를 약간 다르게 수행합니다.

  • 응답이 바이트 범위 요청을 사용하여 캐시된 경우 Cloud CDN은 If-Modified-Since 또는 If-None-Match 헤더를 포함하는 별도의 유효성 검사 요청을 시작합니다.
  • 그렇지 않으면 Cloud CDN에서 If-Modified-Since 또는 If-None-Match 헤더를 클라이언트 요청에 추가하고 수정된 요청을 백엔드로 전달합니다.

캐시된 사본이 여전히 최신 상태인 경우 백엔드는 304 Not Modified 응답을 전송하여 기존 캐시 항목의 유효성을 검사할 수 있습니다. 이 경우, 백엔드는 응답 헤더만 전송하고 응답 본문을 전송하지 않습니다. Cloud CDN은 새 응답 헤더를 캐시에 삽입하고 만료 시간을 업데이트하고 새 응답 헤더와 캐시된 응답 본문을 클라이언트에 제공합니다.

이전에 캐시된 응답에 Last-Modified 또는 ETag 헤더가 없으면 Cloud CDN은 만료된 캐시 항목을 무시하고 수정되지 않은 클라이언트 요청을 백엔드로 전달합니다.

캐시 항목의 만료 시간은 캐시 항목이 유효한 기간의 상한입니다. 캐시 항목이 만료될 때까지 캐시에 남아 있다는 보장은 없습니다. 인기가 없는 콘텐츠의 캐시 항목은 새 콘텐츠를 위한 공간 확보를 위해 삭제될 수 있습니다. 지정된 만료 시간과 관계없이 30일 동안 액세스되지 않은 캐시 항목은 자동으로 삭제됩니다.

자세한 내용은 제거 및 만료를 참조하세요.

TTL 설정 및 재정의

Cloud CDN이 콘텐츠를 재검증하기 전에 기다리는 시간과 관련된 Cloud CDN 동작을 미세 조정할 수 있습니다.

자세한 내용은 TTL 설정 및 재정의 사용을 참조하세요.

바이트 범위 요청 지원

다음 기준을 충족하는 응답은 원본 서버가 바이트 범위 요청을 지원함을 나타냅니다.

  • 상태 코드: 200 OK 또는 206 Partial Content
  • 헤더: Accept-Ranges: bytes
  • 헤더: Content-Length 또는 Content-Range
  • 헤더: 강력한 유효성 검사 도구가 있는 ETag
  • 헤더: Last-Modified

Cloud Storage는 대부분의 객체에 대해 바이트 범위 요청을 지원합니다. 그러나 클라이언트 요청에 Accept- Encoding: gzip 헤더가 포함되어 있지 않으면 Cloud Storage는 Content-Encoding: gzip 메타데이터가 있는 객체의 바이트 범위 요청을 지원하지 않습니다. 10MB보다 큰 Cloud Storage 객체가 있는 경우 객체에 Content-Encoding: gzip 메타데이터가 없는지 확인합니다. 객체 메타데이터를 수정하는 방법에 대한 자세한 내용은 객체 메타데이터 보기 및 수정을 참조하세요.

또한 널리 사용되는 웹 서버 소프트웨어도 바이트 범위 요청을 지원합니다. 이 지원을 사용 설정하는 방법에 대해서는 해당 웹 서버 소프트웨어 문서를 참조하세요. 바이트 범위 요청에 대한 자세한 내용은 HTTP 사양을 참조하세요.

원본 서버가 바이트 범위 요청을 지원하면 Cloud CDN 캐시는 다음 이유 중 하나로 처음 요청되었을 때 캐시 가능한 응답 저장을 거부할 수 있습니다.

  • 클라이언트가 콘텐츠의 일부만 요청했으므로, 응답 본문이 완전하지 않은 경우
  • 응답 본문이 1MB(1,048,576바이트)보다 큰 경우

이러한 경우와 응답이 정상적인 캐시 저장 가능성 요구사항을 충족하면 캐시는 원본 서버가 해당 캐시 키의 바이트 범위 요청을 지원하고 원본 서버의 응답을 클라이언트에 전달하는 것을 기록합니다.

캐시 부적중의 경우 캐시는 원본 서버가 바이트 범위 요청을 지원하는 것으로 알려져 있는지 확인합니다. 바이트 범위 요청가 캐시 키를 지원하는 것으로 알려진 경우 캐시는 클라이언트 요청을 외부 HTTP(S) 부하 분산기로 전달하지 않습니다. 대신 누락된 콘텐츠 부분에 대해 자체 바이트 범위 캐시 채움 요청을 시작합니다. 원본 서버가 요청된 바이트 범위를 206 Partial Content 응답으로 반환하면 캐시는 이후 요청을 위해 해당 범위를 저장할 수 있습니다.

캐시가 시작한 바이트 범위 요청에 대한 응답으로 캐시가 수신된 경우에만 캐시는 206 Partial Content 응답을 저장합니다. 캐시는 이전에 원본 서버가 해당 캐시 키의 바이트 범위 요청을 지원한다는 점을 기록한 경우 외에는 바이트 범위 요청을 시작하지 않으므로 두 번째로 콘텐츠에 액세스할 때까지 1MB보다 큰 콘텐츠를 저장하지 않습니다.

Cloud CDN에서 시작된 요청

원본 서버가 바이트 범위 요청을 지원하는 경우 Cloud CDN은 단일 클라이언트 요청에 대한 응답으로 여러 요청을 원본 서버에 보낼 수 있습니다. Cloud CDN은 유효성 검사 요청과 바이트 범위 요청, 두 가지 유형의 요청을 시작할 수 있습니다.

원본 서버가 특정 캐시 키의 바이트 범위 요청을 지원한다는 점을 알려주는 응답이 만료된 경우, Cloud CDN은 유효성 검사 요청을 시작하여 콘텐츠가 변경되지 않았고 원본 서버가 콘텐츠의 범위 요청을 여전히 지원하는지 확인합니다. 원본 서버가 304 Not Modified 응답으로 응답하면 Cloud CDN은 바이트 범위를 사용하여 콘텐츠를 제공합니다. 그렇지 않으면 Cloud CDN은 원본 서버의 응답을 클라이언트에 전달합니다. 사용자는 캐시 관리 및 만료 응답 헤더를 사용하여 만료 시간을 제어합니다.

캐시 부적중의 경우 Cloud CDN은 클라이언트 요청과 겹치는 바이트 범위 조합의 캐시 채움 요청을 시작합니다. 클라이언트가 요청한 콘텐츠의 일부 범위가 캐시에 있는 경우, Cloud CDN은 캐시에서 가능한 모든 콘텐츠를 제공하고 누락된 범위의 바이트 범위 요청만 원본 서버로 보냅니다.

Cloud CDN에서 시작된 각 바이트 범위 요청은 2,097,136바이트의 배수인 오프셋에서 시작되는 범위를 지정합니다. 최종 범위를 제외하고 각 범위 크기는 2,097,136바이트입니다. 콘텐츠가 해당 크기의 배수가 아니면 최종 범위는 더 작아집니다. 향후에 바이트 범위 요청에 사용되는 크기와 오프셋을 변경할 수 있습니다.

예를 들어 캐시에 없는 콘텐츠의 바이트 1,000,000에서 3,999,999까지에 대한 클라이언트 요청이 있다고 가정합니다. 이 예시에서 Cloud CDN은 GET 요청 두 개를 시작할 수 있습니다. 하나는 콘텐츠의 처음 2,097,136바이트에 대한 요청이고, 다른 하나는 두 번째 2,097,136바이트에 대한 요청입니다. 이에 따라 클라이언트가 3,000,000바이트만 요청한 경우에도 4,194,272바이트의 캐시 채움이 수행됩니다.

Cloud Storage 버킷을 원본으로 사용하는 경우 각 GET 요청은 별도의 클래스 B 작업으로 청구됩니다. Cloud CDN에서 시작된 모든 요청을 포함하여 Cloud Storage에서 처리된 모든 GET 요청에 대해 요금이 청구됩니다. 응답이 Cloud CDN 캐시에서만 제공되는 경우 GET 요청은 Cloud Storage로 전송되지 않고 Cloud Storage 작업에 대한 요금이 청구되지 않습니다.

Cloud CDN은 유효성 검사 요청 또는 바이트 범위 요청을 시작할 때 Cookie 또는 User-Agent 같은 클라이언트 관련 헤더를 포함하지 않습니다.

다음 단계

  • 캐시 모드를 설정하려면 [캐시 모드 사용]((/cdn/docs/using-cache-modes)을 참조하세요.
  • HTTP(S) 부하 분산 인스턴스와 스토리지 버킷에 Cloud CDN을 사용 설정하려면 Cloud CDN 사용을 참조하세요.
  • 캐시 무효화에 대한 자세한 내용은 캐시 무효화 개요를 참조하세요.
  • GFE 접속 지점을 찾으려면 캐시 위치를 참조하세요.