캐싱 개요

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

캐시 모드

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

Cloud CDN은 응답이 캐시되는 방식, Cloud CDN이 원본에서 전송한 캐시 지시문을 준수하는지 여부, 캐시 TTL이 적용되는 방식을 정의하는 세 가지 캐시 모드를 제공합니다.

사용 가능한 캐시 모드는 다음 표에 나와 있습니다.

캐시 모드	동작
`CACHE_ALL_STATIC`	캐시 불가능이 될 수 없는 정적 콘텐츠가 있는 성공적인 응답을 자동으로 캐시합니다. 유효한 캐싱 지시문을 설정하는 원본 응답도 캐시됩니다. 이것은 Google Cloud CLI 또는 REST API를 사용하여 생성되는 Cloud CDN이 사용 설정된 백엔드의 기본 동작입니다.
`USE_ORIGIN_HEADERS`	유효한 캐시 지시어 및 캐싱 헤더를 설정하기 위해 성공적인 원본 응답을 요구합니다. 이 지시어가 없는 성공적인 응답은 원본에서 전달됩니다.
`FORCE_CACHE_ALL`	원본으로 설정된 캐시 지시문을 무효화하고 성공적인 응답을 무조건적으로 캐시합니다. 백엔드가 동적 HTML 또는 API 응답과 같은 사용자별 비공개 콘텐츠를 제공하는 경우에는 이 모드가 적절하지 않습니다.

유효한 캐시 지시어가 없어도 오류 응답이 캐시될 수 있습니다.

캐시 모드를 FORCE_CACHE_ALL로 설정하기 전에 다음 동작을 고려하세요.

서명된 URL 또는 서명된 쿠키의 경우 FORCE_CACHE_ALL이 Google Cloud 콘솔의 캐시 항목 최대 기간 설정이나 gcloud --signed-url-cache-max-age 옵션을 통해 지정된 최대 기간을 재정의합니다.
FORCE_CACHE_ALL은 이전에 캐시된 콘텐츠의 TTL(수명)을 변경합니다. 이 변경으로 인해 이전에 원본 헤더의 TTL이 더 길기 때문에 최신 상태로 간주되었던 일부 항목이 비활성으로 간주될 수 있으며, 이전에 비활성으로 간주되었던 일부 항목이 최신 상태로 간주될 수 있습니다.
FORCE_CACHE_ALL은 캐시 지시문(Cache-Control 및 Expires)을 재정의하지만 다른 원본 응답 헤더를 재정의하지는 않습니다. 특히 Vary 헤더가 계속 적용되며 FORCE_CACHE_ALL이 있더라도 캐싱을 억제할 수 있습니다. 자세한 내용은 Vary 헤더를 참조하세요.

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

정적 콘텐츠

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

캐시 모드를 CACHE_ALL_STATIC으로 설정했고 응답에 Cache-Control 또는 Expires 헤더의 명시적 캐싱 지시어가 포함되지 않은 경우 Cloud CDN이 다음에 대한 응답을 자동으로 캐시합니다.

CSS(text/css), 자바스크립트(application/javascript) 및 WOFF2(font/woff2)가 포함된 모든 웹 글꼴을 포함한 웹 애셋
JPEG(image/jpg) 및 PNG(image/png)를 포함한 이미지
H.264, H.265, MP4(video/mp4)를 포함한 동영상, MP3(audio/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는 Google Cloud 콘솔이나 gsutil 도구를 사용하여 콘텐츠를 업로드하면 Content-Type 헤더를 자동으로 업로드하도록 설정합니다.
MIME 유형에 따라 응답을 캐시할 수 있지만 private 또는 no-store의 Cache-Control 응답 헤더나 Set-Cookie 헤더가 있으면(전체 규칙 목록 참조) 응답이 캐시되지 않습니다.

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

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

캐시 가능한 콘텐츠

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

Cloud CDN은 콘텐츠를 캐시하는 정확한 조건 집합을 주기적으로 변경할 수 있습니다. Cloud CDN이 콘텐츠를 캐시하지 못하도록 명시적으로 방지하려면 RFC 7234의 가이드라인에 따라 캐시할 수 없는 응답을 지정하는 방법을 결정합니다. 원본 헤더를 기준으로 캐시할 수 없는 콘텐츠 섹션도 참조하세요.

Cloud CDN은 다음 사항이 모두 참인 경우 캐시에 응답을 저장합니다.

속성	요구사항
제공	Cloud CDN이 사용 설정된 백엔드 서비스, 백엔드 버킷 또는 외부 백엔드
다음에 대한 응답	`GET` 요청
상태 코드	`200`, `203`, `204`, `206`, `300`, `301`, `302`, `307`, `308`, `404`, `405`, `410`, `421`, `451`, `501`.
최신 정보	응답에 `max-age` 또는 `s-maxage` 지시문이 있는 `Cache-Control` 헤더가 있거나 이후 타임스탬프를 포함하는 `Expires` 헤더가 있습니다. 연령이 없는 캐시 가능한 응답의 경우(예: `no-cache` 사용) `public` 지시문을 명시적으로 제공해야 합니다. `CACHE_ALL_STATIC` 캐시 모드의 경우 최신 상태 지시문이 없으면 정적 콘텐츠 유형을 포함하는 성공한 응답이 계속 캐싱 대상으로 지정됩니다. `FORCE_CACHE_ALL` 캐시 모드의 경우 모든 성공한 응답이 캐싱 대상으로 지정됩니다. 이로 인해 사용자별 비공개(사용자 식별 가능) 콘텐츠를 캐시할 수 있습니다. Cloud Storage 버킷과 같이 비공개 또는 동적 콘텐츠를 제공하지 않는 백엔드에서만 `FORCE_CACHE_ALL`을 설정해야 합니다. 음성 캐싱이 사용 설정되고 상태 코드가 음성 캐싱에서 TTL을 지정하는 것과 일치하면 명시적인 최신 상태 지시문이 없어도 응답이 캐싱 대상으로 지정됩니다.
내용	HTTP/1 원본의 경우 응답에 유효한 `Content-Length`, `Content-Range` 또는 `Transfer-Encoding: chunked` 헤더가 포함되어야 합니다. 고급 HTTP 프로토콜 버전(HTTP/2 이상)을 사용하는 원본의 경우 응답에 이러한 헤더가 필요하지 않습니다.
크기	최대 크기 이하 크기가 10MB~100GB인 응답의 경우 바이트 범위 요청에 설명된 추가 캐시 저장 가능성 제약조건을 참조하세요.

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

버킷을 공개적으로 읽을 수 있도록 설정합니다. 이는 공개 콘텐츠에 권장되는 방법입니다. 이 설정을 사용하면 인터넷의 모든 사용자가 ACL을 제외한 객체와 메타데이터를 보고 나열할 수 있습니다. 권장되는 방법은 공개 객체에 특정 버킷을 전담하는 것입니다.
관리 폴더를 사용하여 버킷의 일부를 공개적으로 읽을 수 있도록 설정합니다.
개별 객체를 공개적으로 읽을 수 있도록 설정합니다. 이 방법은 기존의 Cloud Storage 관련 권한 시스템을 사용하므로 사용하지 않는 것이 좋습니다.

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

백엔드 버킷으로 외부 애플리케이션 부하 분산기를 구성하는 방법에 대한 예시는 백엔드 버킷으로 Cloud CDN 설정을 참조하세요.

최대 크기

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

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

원본 서버가 바이트 범위 요청을 지원함	원본 서버가 바이트 범위 요청을 지원하지 않음
100GB(107,374,182,400바이트)	10MB(10,485,760바이트)

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

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

응답의 캐싱을 차단하는 검사가 있습니다. Cloud CDN은 콘텐츠를 캐시하는 정확한 조건 집합을 주기적으로 변경할 수 있으므로, Cloud CDN이 콘텐츠를 캐시하지 못하도록 하려면 표준(RFC 7234)의 가이드라인에 따라 캐시할 수 없는 응답을 지정하는 방법을 결정합니다.

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

속성	요구사항
제공	Cloud CDN이 사용 설정되지 않은 백엔드 서비스 또는 외부 백엔드
쿠키	`Set-Cookie` 헤더가 있음
`Vary` 헤더	`Accept`, `Accept-Encoding`, `Access-Control-Request-Headers`, `Access-Control-Request-Method`, `Origin`, `Sec-Fetch-Dest`, `Sec-Fetch-Mode`, `Sec-Fetch-Site`, `X-Goog-Allowed-Resources`, `X-Origin` 이외의 값 또는 캐시 키 설정의 일부로 구성된 헤더 중 하나를 포함합니다.
응답 지시문	응답에 `no-store` 또는 `private` 지시문이 있는 `Cache-Control` 헤더가 있습니다. 이 경우 `FORCE_CACHE_ALL` 캐시 모드를 사용하지 않으면 `Cache-Control` 헤더는 무시됩니다.
요청 지시문	요청에 `Cache-Control: no-store` 지시문이 있음
승인 요청	Cache-Control 응답에 의해 재정의되지 않는 한 요청에 `Authorization` 헤더가 있습니다.
크기	최대 크기보다 큼

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

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

캐싱 방지

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

Cloud CDN 캐시 모드가 모든 성공적인 응답을 무조건 캐시하는 FORCE_CACHE_ALL 모드로 설정되어 있지 않은지 확인합니다.
Cloud CDN 캐시에 저장하지 않아야 할 응답에는 Cache-Control: private 헤더를 포함하고, 웹브라우저의 캐시를 포함한 모든 캐시에 저장하지 않아야 할 응답에는 Cache-Control: no-store 헤더를 포함합니다.
개인 정보에 대한 액세스를 제공하는 URL에 서명하지 않습니다. 서명된 URL을 사용하여 콘텐츠에 액세스하는 경우 응답의 Cache-Control 지시문에 관계없이 잠재적으로 캐시할 수 있습니다.
Authorization 요청 헤더가 포함된 원본(캐시 채움) 요청의 경우 Cloud CDN은 캐시 모드가 USE_ORIGIN_HEADERS또는 CACHE_ALL_STATIC으로 설정된 경우 public, must-revalidate 또는 s-maxage 캐시 제어 지시문이 포함된 응답만 캐시합니다. 이렇게 하면 사용자별 콘텐츠 또는 인증이 필요한 콘텐츠를 실수로 캐시하는 것을 방지할 수 있습니다. FORCE_CACHE_ALL 캐시 모드에는 이러한 제한이 없습니다.

커스텀 응답 헤더 추가

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

헤더 목록은 헤더 값에 표시될 수 있는 변수를 참조하세요.

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

커스텀 응답 헤더는 전역 외부 애플리케이션 부하 분산기에서 Cloud CDN 배포에 지원되지 않습니다.

캐시 키

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

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

백엔드 버킷의 경우 기본값은 캐시 키가 프로토콜이나 호스트 없이 URI로 구성되는 것입니다. 기본적으로 Cloud Storage에 알려진 쿼리 매개변수만 캐시 키의 일부로 포함됩니다(예: 'generation').

따라서 특정 백엔드 버킷의 경우 다음 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

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

URI 부분 맞춤설정 캐시 키가 동일한 URL의 예시

프로토콜

캐시 키에서 프로토콜을 생략합니다.

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`

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

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

쿼리 문자열 포함 목록

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

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

Cloud Storage 캐시 키의 쿼리 문자열 포함 목록

Cloud Storage 버킷의 캐시 키에 URL 쿼리 매개변수를 포함하면 캐시 무효화를 지원하는 데 도움이 됩니다. 캐시 무효화는 이전 버전이 TTL에서 아직 올바르게 캐시되어 있더라도 사용자가 업로드된 파일의 새 버전을 찾을 수 있게 해주는 프로세스입니다.

백엔드 버킷의 응답을 제공하는 데 사용되는 캐시 키에 특정 쿼리 매개변수 목록을 포함할 수 있습니다. Cloud Storage는 쿼리 매개변수를 기반으로 다른 콘텐츠 또는 경로를 제공하지 않지만 Cloud Storage 버킷에 저장된 정적 콘텐츠를 캐시 무효화할 수 있는 매개변수를 포함하도록 선택할 수 있습니다.

예를 들어 기본 콘텐츠를 기반으로 하는 ?version=VERSION 또는 ?hash=HASH 쿼리 매개변수를 추가할 수 있습니다. 이렇게 하면 콘텐츠를 사전에 무효화할 필요가 없으며 웹 프레임워크와 URL에서 비활성 객체를 제공하지 않도록 콘텐츠의 해시를 사용하는 최신 웹 개발 워크플로에 부합합니다.

캐시 키에 쿼리 매개변수를 포함하는 것은 선택이므로 Cloud CDN은 캐시 키에서 백엔드 버킷으로 쿼리 매개변수를 제외하는 것을 지원하지 않습니다.

쿼리 문자열 제외 목록

제외 목록을 사용하여 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의 캐시 키를 만듭니다.

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

쿼리 매개변수 순서

생성된 캐시 키는 쿼리 매개변수 순서에 의존하지 않습니다.

예를 들어 다음 쿼리 매개변수는 동일한 캐시 키를 생성합니다.

info=123&variant=13e&geography=US
geography=US&variant=13e&info=123

HTTP 헤더 및 HTTP 쿠키 캐시 키 설정

다음 캐시 키 구성 설정을 사용하여 캐시 적중률과 원본 오프로드를 향상시킬 수 있습니다.

백엔드 서비스 및 버킷의 경우: 이름이 지정된 헤더를 캐시 키 구성에 포함하여 HTTP 헤더를 캐시 키의 일부로 사용합니다.
백엔드 서비스만 해당: A/B(다변수) 테스트, 카나리아 및 유사한 시나리오와 같이 이름이 지정된 HTTP 쿠키를 캐시 키로 사용합니다.

요청에 추가 HTTP 헤더 또는 HTTP 쿠키가 포함된 캐시 요청은 해당 캐시 키의 캐시 위치에 있는 세 번째 요청에서 캐시됩니다. 이렇게 하면 캐시 제거율에 대해 높은 카디널리티 헤더/쿠키 값이 미치는 영향이 줄어듭니다. 일반적인 상황과 사용자 트래픽 조건에서는 눈에 띄지 않아야 하며 인기 콘텐츠가 캐시된 상태로 유지됩니다.

요청 헤더 포함

응답의 추가 변형을 캐시하려면 캐시 키에 추가 요청 헤더를 포함할 수 있습니다.

일부 헤더는 일반적으로 카디널리티가 매우 높으므로 캐시 키에서 허용되지 않습니다. 대부분의 경우 이러한 헤더의 값은 사용자별로 고유하거나(Cookie, Authorization) 값이 수천 개(Referer ,User-Agent ,Accept)일 수 가능성이 높습니다. 예를 들어 User-Agent 헤더에는 다양한 브라우저, 사용자 기기, 운영체제에 따라 5,000개가 넘는 고유 값이 있을 수 있습니다. 이러한 유형의 헤더는 캐시 적중률에 심각한 부정적인 영향을 미칩니다.

RFC 7230에 따라 유효한 HTTP 헤더 필드 이름만 허용됩니다. 헤더 필드 이름은 대소문자를 구분하지 않으며 중복될 경우 거부됩니다.

선택적으로 Vary 응답에 구성된 캐시 키 요청 헤더를 포함하도록 원본 서버를 구성할 수 있습니다. Cloud CDN에는 필요하지 않지만 다운스트림 캐시에 유용할 수 있습니다. 자세한 내용은 Vary 헤더를 참조하세요.

Cloud CDN은 헤더 목록에 다음 헤더를 포함하는 것을 허용하지 않습니다.

Accept
Accept-Encoding
Authority, 구성(cdnPolicy.includeHost)에 의해 제어되기 때문
Authorization, Bearer 토큰에서와 같이 보통 사용자별로
CDN-Loop
Connection
Content-MD5
Content-Type
Cookie
Date
Forwarded, 종종 클라이언트별 또는 프록시별
From
Host, 구성(cdnPolicy.includeHost)에 의해 제어되기 때문
If-Match, If-Modified-Since 또는 If-None-Match
Origin
Proxy-Authorization
Range
Referer(또는 Referrer)
User-Agent
Want-Digest
Django 및 Ruby on Rails에서 사용되는 X-CSRFToken 및 X-CSRF-Token
X-Forwarded-For, 종종 클라이언트별 또는 프록시별
X-User-IP
다음으로 시작하는 모든 헤더:
- Access-Control-Request-Headers 및 Access-Control-Request-Method와 같은 Access-Control-
- Sec-Fetch-
- Sec-GFE-
- Sec-Google-
- X-Amz-
- X-GFE-
- X-Goog-
- X-Google-

다른 값을 가진 동일한 헤더

사용자가 헤더 값이 서로 다른 동일한 이름의 헤더를 여러 개 보낸다고 가정해 보겠습니다.

My-Header: Value1
My-Header: Value2

이 경우 Cloud CDN은 일부 헤더에 여러 값이 포함되도록 허용하는 표준 규칙을 따라야 하는 것으로 가정하고 요청을 수정합니다. Cloud CDN은 이를 쉼표로 구분된 목록으로 축소하여 백엔드로 전송하므로 클라이언트가 다음을 전송한 것과 같습니다.

My-Header: Value1, Value2

이름이 지정된 쿠키 포함

HTTP 쿠키는 name=value 쌍이며 요청에는 동일한 줄에서 세미콜론으로 구분되거나 헤더당 하나의 쿠키가 있는 임의의 Cookie 요청 헤더로 여러 HTTP 쿠키가 포함될 수 있습니다.

최대 5개의 쿠키 이름 목록을 제공할 수 있습니다.

사용자 에이전트(예: 웹브라우저)는 도메인당 저장되는 쿠키 수를 4KB로 제한하는 경우가 많습니다. 사용자 에이전트가 요청에 모든 쿠키를 전송하지 않을 수 있으므로 너무 많은(또는 너무 큰) 쿠키를 전송하지 마세요. 이는 사용자가 캐시된 특정 응답을 수신하는지 여부에 영향을 줄 수 있습니다.

쿠키를 발행하는 다른 호스트 이름에서 정적 콘텐츠를 제공하는 경우 쿠키에서 Domain(및 Path) 속성의 쿠키 속성을 정적 콘텐츠에 대한 요청과 함께 보낼 수 있도록 허용해야 합니다.

요청에 동일한 쿠키 이름의 인스턴스가 여러 개 포함된 경우 첫 번째 인스턴스만 적용됩니다.

캐시 제어 지시문

HTTP 캐시 제어 지시문은 다음 표에 설명된 대로 Cloud CDN의 동작에 영향을 미칩니다.

해당 사항 없음은 요청이나 응답에 지시문을 적용할 수 없음을 나타냅니다.

지시문	요청	응답
`no-store`	요청에 있는 경우 Cloud CDN은 이를 받아들여 응답을 캐시에 저장하지 않습니다.	`no-store`가 포함된 응답은 캐시되지 않습니다. `FORCE_CACHE_ALL` 캐시 모드를 사용하여 백엔드별로 재정의할 수 있습니다.
`no-cache`	클라이언트가 원본에 재검증을 잠재적으로 시작하거나 강제하지 못하게 하기 위해 `no-cache` 요청 지시문은 무시됩니다.	`no-cache`인 응답은 캐시되지만 제공하기 전에 원본으로 재검증해야 합니다. `FORCE_CACHE_ALL` 캐시 모드를 사용하여 백엔드별로 재정의할 수 있습니다.
`public`	해당 사항 없음	캐시 가능성에는 이 지시문이 필요하지 않지만 프록시에서 캐시해야 하는 콘텐츠에 포함하는 것이 좋습니다.
`private`	해당 사항 없음	`private` 지시문이 있는 응답은 응답이 캐시 가능한 것으로 간주되는 경우에도 Cloud CDN에 의해 캐시되지 않습니다. 클라이언트(예: 브라우저)는 여전히 결과를 캐시할 수 있습니다. `FORCE_CACHE_ALL` 캐시 모드를 사용하여 백엔드별로 재정의할 수 있습니다. 모든 응답 캐싱을 방지하려면 `no-store`를 사용합니다.
`max-age=SECONDS`	`max-age` 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다.	`max-age` 지시문이 있는 응답은 정의된 `SECONDS`로 캐시됩니다.
`s-maxage=SECONDS`	해당 사항 없음	`s-maxage` 지시문이 있는 응답은 정의된 `SECONDS`로 캐시됩니다. `max-age`과 `s-maxage`이 모두 존재하는 경우 `s‑maxage`는 Cloud CDN에서 사용됩니다. 이 지시문이 있는 응답은 비활성 상태가 아닙니다. `s-max-age`(하이픈 2개)는 캐싱 목적에 유효하지 않습니다.
`min-fresh=SECONDS`	`min-fresh` 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다.	해당 사항 없음
`max-stale=SECONDS`	`max-stale` 요청 지시문은 클라이언트가 허용할 최대 비활성 상태를 초 단위로 나타냅니다. Cloud CDN은 이를 받아들여 응답의 비활성 상태가 `max-stale` 지시문보다 짧은 경우에만 오래된 캐시된 응답을 반환합니다. 그렇지 않으면 요청을 처리하기 전에 재검증합니다.	해당 사항 없음
`stale-while-revalidate=SECONDS`	해당 사항 없음	`stale-while-revalidate`가 있는 응답은 클라이언트에 최대 `SECONDS`까지 제공되고 재검증이 비동기식으로 발생합니다. 이 동작은 백엔드에서 `cdnPolicy.serveWhileStale`을 설정하여 모든 응답에 사용 설정할 수 있습니다.
`stale-if-error=SECONDS`	`stale-if-error` 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다.	이 응답 헤더는 효과가 없습니다.
`must-revalidate`	해당 사항 없음	`must-revalidate`가 있는 응답은 만료된 후 원본 서버에서 재검증합니다. 이 지시문이 있는 응답은 비활성 상태가 아닙니다.
`proxy-revalidate`		`proxy-revalidate`가 있는 응답은 만료된 후 원본 서버에서 재검증합니다. 이 지시문이 있는 응답은 비활성 상태가 아닙니다.
`immutable`	해당 사항 없음	효과 없음 이는 응답에서 클라이언트로 전달됩니다.
`no-transform`	해당 사항 없음	Cloud CDN에는 변환이 적용되지 않습니다.
`only-if-cached`	`only-if-cached` 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다.	해당 사항 없음

가능한 경우 Cloud CDN은 RFC를 준수(HTTP RFC 7234)하려고 노력하지만 캐시 오프로드를 최적화하고 클라이언트가 적중률 또는 전반적인 원본 부하에 미칠 수 있는 영향을 최소화하는 것을 선호합니다.

HTTP/1.1 Expires 헤더를 사용하는 응답의 경우 다음 사항이 적용됩니다.

Expires 헤더의 값은 RFC 7231에 정의된 유효한 HTTP 날짜여야 합니다.
과거 날짜 값, 잘못된 날짜 또는 0 값은 콘텐츠가 이미 만료되었고 재검증해야 함을 나타냅니다.
응답에 Cache-Control 헤더가 있으면 Cloud CDN은 Expires 헤더를 무시합니다.

응답에 유효한 향후 Expires 헤더가 있으면 응답이 캐시될 수 있으며 다른 캐시 지시문을 지정할 필요가 없습니다.

HTTP/1.0 Pragma 헤더가 응답에 있는 경우 이 헤더는 무시되며 클라이언트에 그대로 전달됩니다. 이 헤더가 포함된 클라이언트 요청은 원본으로 전달되며 Cloud CDN이 응답을 제공하는 방식에 영향을 미치지 않습니다.

`Vary` 헤더

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

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

FORCE_CACHE_ALL 캐시 모드는 이 동작을 재정의하지 않습니다. Vary 헤더는 가능한 여러 원본 서버 응답 간의 캐시 악성을 방지하기 위해 중요합니다. FORCE_CACHE_ALL가 이러한 응답을 캐시하도록 하는 것은 위험할 수 있습니다.

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

캐시 키에 HTTP 헤더를 사용할 때 Cloud CDN은 Vary 지원과 비슷하게 지정된 요청 헤더의 값을 기반으로 여러 응답 복사본을 캐시하지만, 원본 서버가 Vary 응답 헤더를 명시적으로 지정할 필요가 없습니다. 원본이 Vary 응답의 캐시 키 헤더를 지정하는 경우 Cloud CDN은 헤더가 Vary 응답에 언급되지 않은 것과 동일하게 응답을 올바르게 처리합니다.

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

캐시 항목 만료 시간은 캐시 항목이 유효한 기간을 정의합니다. s-maxage(또는 max-age 또는 expires) 값에서 제공되는 값을 사용하면 사용자가 생성한 비활성 캐시 콘텐츠의 유효성을 자동으로 다시 검사할 수 있습니다.

Cloud CDN이 요청을 받으면 해당 캐시 항목을 조회하고 저장 기간을 확인합니다. 캐시 항목이 존재하고 새 항목이면 캐시에서 응답을 제공할 수 있습니다. 만료 시간이 경과하면 Cloud CDN은 백엔드 중 하나에 연락하여 캐시 항목 유효성을 다시 검사합니다. 이는 검증이 비동기식으로 수행되는 오래된 경우에도 제공을 사용 설정하지 않는 한 응답을 제공하기 전에 수행됩니다.

일부 캐시 모드의 경우 TTL 값을 설정할 수 있습니다. 자세한 내용은 TTL 설정 및 재정의 사용을 참조하세요.

캐시 모드는 최신 상태가 결정되는 방식에 영향을 미칩니다.

캐시 모드	유효성 검사 동작
`CACHE_ALL_STATIC`	원본 헤더(`Cache-Control: s-maxage`, `Cache-Control: max-age` 또는 `Expires` 헤더)가 최신 상태를 확인하기 위해 참조됩니다. 정적 콘텐츠의 경우 원본 헤더가 없으면 구성된 `default_ttl`에서 최신 상태를 결정합니다. 정적 콘텐츠가 `default_ttl`보다 오래되면 Cloud CDN은 유효성을 다시 검사합니다.
`USE_ORIGIN_HEADERS`	Cloud CDN 캐시의 각 캐시 항목에는 RFC 7234에 따라 `Cache-Control: s-maxage`, `Cache-Control: max-age` 또는 `Expires` 헤더에서 정의한 만료 시간이 있습니다.
`FORCE_CACHE_ALL`	구성된 `default_ttl`에서 원본 헤더 대신 최신 상태를 결정합니다. 콘텐츠가 `default_ttl`보다 오래되면 Cloud CDN은 유효성을 다시 검사합니다.

두 개 이상 있으면 Cache-Control: s-maxage가 Cache-Control: max-age보다 우선시되고 Cache-Control: max-age가 Expires보다 우선시됩니다.

기본적으로 만료 시간 값이 30일(2,592,000초)을 초과하면 Cloud CDN은 만료 값을 2,592,000초로 처리합니다. 30일을 초과하더라도 다운스트림 클라이언트는 여전히 max-age 및 s-maxage의 정확한 값을 볼 수 있습니다.

제거

인기가 없는 항목을 만료되기 전에 언제든지 제거하여 새 콘텐츠를 위한 공간을 확보할 수 있으므로 캐시 항목이 만료될 때까지 캐시에 보존된다는 보장은 없습니다. 상한으로 인해 30일 동안 액세스되지 않은 캐시 항목은 자동으로 삭제됩니다.

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

유효성 검사에 조건부 요청 사용

Cloud CDN은 캐시된 응답 헤더의 정보를 사용하여 백엔드가 있는 캐시 항목의 유효성을 검사할 수 있습니다. 다음 두 조건이 모두 충족되는 경우에 가능합니다.

이전에 캐시된 응답에 Last-Modified 또는 ETag 헤더가 있습니다.
클라이언트 요청은 If-Modified-Since 또는 If-None-Match 헤더가 없는 GET 요청입니다.

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은 만료된 캐시 항목을 무시하고 수정되지 않은 클라이언트 요청을 백엔드로 전달합니다.

바이트 범위 요청 지원

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

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

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

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

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

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

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

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

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

분산 특성으로 인해 Cloud CDN은 위치당 두 번 이상 원본에서 최종 청크를 가져오는 경우가 있습니다. 이로 인해 캐시 키당 처음 몇 개의 요청만 영향을 받습니다.

요청 축소(병합)

요청 축소(병합이라고도 함)는 동일한 캐시 키에 대한 여러 사용자 기반 캐시 채움 요청을 에지 노드별 단일 원본 요청으로 축소합니다. 이렇게 하면 원본에서 부하를 적극적으로 줄일 수 있으며 항목 요청(직접 응답을 가져옴) 및 청크 요청 모두에 적용됩니다. 여기서 Cloud CDN은 Range 요청을 사용하여 더 효율적으로 더 큰 객체를 가져옵니다.

요청 축소는 기본적으로 사용 설정됩니다.

축소된 요청은 다음과 같은 방식으로 작동합니다.

축소된 요청은 클라이언트용 요청과 캐시 채우기 요청(축소됨)을 모두 로깅합니다.
축소된 세션의 리더는 원본 채우기 요청을 수행하는 데 사용됩니다.
User-Agent 또는 Accept-Encoding 헤더와 같이 캐시 키에 속하지 않는 요청 속성은 축소된 세션의 리더만 반영합니다.
캐시 키가 동일한 요청은 축소될 수 없습니다.

다음 다이어그램은 요청이 병합되는 방식을 보여줍니다.

반면 요청 축소가 사용 중지되었거나 병합될 수 없는 요청의 경우 원본 요청과 응답의 수가 현재 캐시되지 않는 객체를 가져오려고 시도하는 클라이언트 수와 동일할 수 있습니다.

모든 유형의 요청에 대해서는 축소가 기본적으로 사용 설정됩니다. 항목 요청 유형의 경우 축소 기능을 사용 중지할 수 있습니다. 이 기능은 원본 부하가 고려되지 않는 광고 게재와 같이 지연 시간에 매우 민감한 시나리오에서 항목 요청을 중지하는 것이 좋습니다.

다음 표는 다양한 요청 유형의 기본 동작과 구성 가능성을 요약합니다.

요청 유형	기본 동작	구성 가능	축소의 이점
청크 요청	사용 설정됨	아니요	원본 대역폭을 상당히 줄일 수 있음
항목 요청	사용 설정됨	예	원본 요청 볼륨을 줄일 수 있습니다.

Cloud Storage 버킷을 참조하는 백엔드 버킷에 Google Cloud CLI를 사용하여 항목 요청 축소를 중지하려면 다음 안내를 따르세요.

gcloud

gcloud compute backend-services 또는 backend-buckets 명령어를 사용합니다.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Google Cloud CLI를 사용하여 백엔드 버킷에서 축소를 사용 설정하려면 다음 안내를 따르세요.

gcloud

gcloud compute backend-buckets 명령어를 사용합니다.

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

VM 그룹 및 외부 백엔드를 비롯한 백엔드 서비스에 Google Cloud CLI를 사용하여 항목 요청 축소를 사용 설정하려면 다음 안내를 따르세요.

gcloud

gcloud compute backend-services 명령어를 사용합니다.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Cloud CDN에서 시작된 요청

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

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

캐시 부적중의 경우 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 같은 클라이언트 관련 헤더를 포함하지 않습니다.

Cloud Logging httpRequest.userAgent 필드에서 Cloud-CDN-Google은 Cloud CDN이 요청을 시작했음을 의미합니다.

캐시 우회

캐시 우회는 특정 요청 헤더가 포함된 요청이 캐시를 우회하도록 허용합니다. 콘텐츠가 이전에 캐시된 경우에도 마찬가지입니다.

이 섹션에서는 Pragma 및 Authorization과 같은 HTTP 헤더를 사용하여 캐시를 우회하는 방법을 설명합니다. 이 기능은 사용자 또는 고객이 원본 서버에서 최신 콘텐츠를 항상 가져오도록 하려는 경우 유용합니다. 테스트, 스테이징 디렉터리 설정, 스크립트를 위해 이 작업을 수행하는 것이 좋습니다.

지정된 헤더가 일치하면 모든 캐시 모드 설정에 대해 캐시가 우회됩니다. FORCE_CACHE_ALL도 마찬가지입니다. 지정된 헤더가 많은 요청에서 공통된 경우 캐시 우회가 다수의 캐시 부적중을 유발합니다.

시작하기 전에

Cloud CDN이 사용 설정되어 있는지 확인합니다. 자세한 내용은 Cloud CDN 사용을 참조하세요.
필요한 경우 Google Cloud CLI를 최신 버전으로 업데이트합니다.
```
gcloud components update
```
참고: gcloud CLI 버전 324.0.0 이상을 사용 중인지 확인하세요.

캐시 우회 구성

최대 5개의 HTTP 헤더 이름을 지정할 수 있습니다. 값은 대소문자를 구분하지 않습니다. 헤더 이름은 올바른 HTTP 헤더 필드 토큰이어야 합니다. 헤더 이름은 추가된 헤더 목록에 두 번 이상 나타나지 않아야 합니다. 유효한 헤더 이름에 관한 규칙은 커스텀 헤더 작동 방식을 참조하세요.

콘솔

Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.
부하 분산 페이지로 이동
외부 애플리케이션 부하 분산기의 이름을 클릭합니다.
수정 을 클릭합니다.
백엔드 구성에서 백엔드를 선택하고 수정 을 클릭합니다.
Cloud CDN 사용 설정이 선택되어 있는지 확인합니다.
창 하단에서 고급 구성을 클릭합니다.
요청 헤더에서 캐시 우회 아래에서 헤더 추가를 클릭합니다.
Pragma 또는 Authorization과 같은 헤더 이름을 입력합니다.
업데이트를 클릭합니다.
업데이트를 다시 클릭합니다.

gcloud

백엔드 버킷의 경우 --bypass-cache-on-request-headers 플래그와 함께 gcloud compute backend-buckets create 또는 gcloud compute backend-buckets update 명령어를 사용합니다.

백엔드 서비스의 경우 --bypass-cache-on-request-headers 플래그와 함께 gcloud compute backend-services create 또는 gcloud compute backend-services update 명령어를 사용합니다.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

예를 들면 다음과 같습니다.

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

api

백엔드 버킷의 경우 Method: backendBuckets.insert, Method: backendBuckets.update 또는 Method: backendBuckets.patch API 호출을 사용합니다.

백엔드 서비스의 경우 Method: backendServices.insert, Method: backendServices.update 또는 Method: backendServices.patch API 호출을 사용합니다.

예를 들면 다음과 같습니다.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

JSON 요청 본문에 다음 스니펫을 추가합니다.

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

캐시 우회 사용 중지

gcloud

백엔드 버킷의 경우 --no-bypass-cache-on-request-headers 플래그와 함께 gcloud compute backend-buckets create 또는 gcloud compute backend-buckets update 명령어를 사용합니다.

백엔드 서비스의 경우 --no-bypass-cache-on-request-headers 플래그와 함께 gcloud compute backend-services create 또는 gcloud compute backend-services update 명령어를 사용합니다.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

api

백엔드 버킷의 경우 Method: backendBuckets.insert 또는 Method: backendBuckets.update API 호출을 사용합니다.

백엔드 서비스의 경우 Method: backendServices.insert 또는 Method: backendServices.update API 호출을 사용합니다.

다음 API 호출 중 하나를 사용합니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

JSON 요청 본문에 다음 스니펫을 추가합니다.

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

다음 단계

캐시 모드가 콘텐츠를 더 쉽게 캐시하는 방법을 알아보려면 캐시 모드 사용을 참조하세요.
HTTP(S) 부하 분산 인스턴스 및 스토리지 버킷에 Cloud CDN을 사용 설정하려면 Cloud CDN 사용을 참조하세요.
캐시 무효화에 대한 자세한 내용은 캐시 무효화 개요를 참조하세요.
GFE 접속 지점을 찾으려면 캐시 위치를 참조하세요.