[Cloudflare] CDN Cache 응답(Response Status)에 따른 HTTP 통신 파악하기

Cloudflare 에서 제공하는 Cache Respose Status 는 아래 참조 문서에서 확인할 수 있다.

참조 : https://developers.cloudflare.com/cache/concepts/default-cache-behavior/

Default Cache Behavior · Cloudflare Cache (CDN) docs

 

 

cloudflare Cache Respose Status

 

HIT					The resource was found in Cloudflare’s cache.
MISS					The resource was not found in Cloudflare’s cache and was served from the origin web server.
NONE/UNKNOWN					Cloudflare generated a response that denotes the asset is not eligible for caching. This may have happened because: A Worker generated a response without sending any subrequests. In this case, the response did not come from cache, so the cache status will be none/unknown. A Worker request made a subrequest (fetch). In this case, the subrequest will be logged with a cache status, while the main request will be logged with none/unknown status (the main request did not hit cache, since Workers sits in front of cache). A Firewall rule was triggered to block a request. The response will come from the edge network before it hits cache. Since there is no cache status, Cloudflare will log as none/unknown. A redirect page rule caused the edge network to respond with a redirect to another asset/URL. This redirect response happens before the request reaches cache, so the cache status is none/unknown.
EXPIRED					The resource was found in Cloudflare’s cache but was expired and served from the origin web server.
STALE					The resource was served from Cloudflare’s cache but was expired. Cloudflare could not contact the origin to retrieve an updated resource.
BYPASS					The origin server instructed Cloudflare to bypass cache via a Cache-Control header set to no-cache,private, or max-age=0 even though Cloudflare originally preferred to cache the asset. BYPASS is returned when enabling Origin Cache-Control. Cloudflare also sets BYPASS when your origin web server sends cookies in the response header. If the Request to your origin includes an `Authorization` header, its response will be also BYPASS.
REVALIDATED					The resource is served from Cloudflare’s cache but is stale. The resource was revalidated by either an If-Modified-Since header or an If-None-Match header.
UPDATING					The resource was served from Cloudflare’s cache and was expired, but the origin web server is updating the resource. UPDATING is typically only seen for very popular cached resources.
DYNAMIC					Cloudflare does not consider the asset eligible to cache and your Cloudflare settings do not explicitly instruct Cloudflare to cache the asset. Instead, the asset was requested from the origin web server. Use Page Rules or Cache Rules to implement custom caching options.

 

 

Cloudflare CDN 는 기본적으로 Client(사용자) -> Edge Server -> Origin Server 의 형태로 동작한다.

이때 Edge Server 에서 Cache를 담당하며 일반적으로 Proxy 형태로 동작하게 된다.

 

 

Cloudflare 에서 제공하는 json 형태의 Log Data 는 크게 Client 정보, Edge 정보, Origin  정보, 3가지 부분으로 제공한다.

이 글에서 살펴 볼 부분은 Edge Response Status 로 Client와 Origin과의 동작 방식이다.

 

사실 Cloudflare Edge 가 아니더라도 일반적인 Cache 역할을 담당하는 중간 서버는 비슷한 형태로 동작한다.

 

 

 

브라우저와 Edge 서버의 Cache

Cache를 담당하는 곳은 Cloudflare Edge같은 중간 서버 외에 Client 의 브라우저, Origin 서버의 Cache 등 이 있지만 일반적으로 Cloudflare Edge 같은 중간서버에서 Cache를 담당하는 구성이면 Origin에서의 Cache는 구성하지 않는다. (장애시 장애 포인트는 적을 수록 좋으니까..)

 

따라서 크게 신경써서 볼곳은 Client 브라우저, Edge Server 2곳이다.

 

물론 Origin에서 Cache를 구성하지 않더라도 Edge 와의 Cache TTL 에는 신경을 써야한다. Origin 에서 같은 파일 이름의 데이터가 변경된다면 Edge에 즉시 반영되야 하는 조건이 생기므로 Edge에서 변경된 파일을 purge 하는 등의 작업이 필요하다.

 

 

 

 

 

HIT

Edge 에서 Cache 된 Data가 존재 하는 경우로 Origin을 대신하여 Edge에서 Client로 200 OK 응답을 한다.

 

Request Header 에는 Cache 의 재확인(revalidate)을 요청하는 If-Modified-Since, If-None-Match 같은 내용은 포함되지 않는다.

Response Header에는 아래와 같은 내용을 포함한다.

Cache-Control: max-age = 14400  : 브라우저 Cache TTL은 14400초(4시간) 동안 유지 

Etag: "asdasdasdasd"  : 요청한 Data의 고유 식별자

Last-Modified: Thu, 15 Jun 20203 00:37:55 GMT  : 요청한 Data의 최종 수정 시간

 

Etag와 Last-Modified 의 값은 브라우저의 Cache TTL 이 지난후 같은 데이터 Request 시 재사용여부를 확인하기 위하여 사용한다.

 

 

 

 

MISS

Edge 에서 Cache 된 Data가 존재 하지 않는 경우로 Edge -> Origin으로 Request 하고 받은 response 200 OK를 Client에 전달한다.

 

Response Header 에는 HIT 와 마찬가지로 아래 내용이 포함된다.

Cache-Control: max-age = 14400  : 브라우저 Cache TTL은 14400초(4시간) 동안 유지

Etag: "asdasdasdasd"  : 요청한 Data의 고유 식별자

Last-Modified: Thu, 15 Jun 20203 00:37:55 GMT  : 요청한 Data의 최종 수정 시간

 

 

 

Expire

Edge 에서 Cache 된 Data가 존재 하지만 만료된 경우로 Edge -> Origin으로 Request 하고 받은 response 200 OK를 Client에 전달한다.

 

s-maxage

Edge Server TTL 이 만료 된 경우이며 Edge Server TTL 은 Origin Server 에서 Edge Server 로 Response 하는 Header에 아래 내용을 포함하여 정의 할 수 있다.

Cache-control: s-maxage = 14400, max-age = 3600

 -> Edge 에서는 1440초(4시간) 동안 cache 하고 Client 브라우저는 3600초(1시간)동안 cache 해라 라는 의미이다.

즉 s-maxage 는 중간서버에서 max-age는 Client 브라우저에서 적용되는 내용이다.

 

 

Request Header 에는 Cache 의 재확인(revalidate)을 요청하는 If-Modified-Since, If-None-Match 같은 내용은 포함되지 않으며 Edge와 Origin의 Response Header에는 아래 내용을 포함한다.

Cache-Control: max-age = 14400  : 브라우저 Cache TTL은 14400초(4시간) 동안 유지

Etag: "asdasdasdasd"  : 요청한 Data의 고유 식별자

Last-Modified: Thu, 15 Jun 20203 00:37:55 GMT  : 요청한 Data의 최종 수정 시간

 

 

 

 

Revalidate

Edge 에서 Cache 된 Data가 존재 하지만 만료되어 Origin에 재사용여부를 확인하는 경우로 Edge -> Origin으로 Request 하고 받은 response는 재사용이 가능하면 304, 재사용할 수 없다면 200 OK를 Client에 전달한다.

 

Request Header 에는 Cache 의 재확인(revalidate)을 요청하는 If-Modified-Since, If-None-Match 같은 내용이 포함된다.

 

If-Modified-Since

Response에서 받은 Last-Modified Header 값을 이용하여 Data의 수정시간에 변동이 없는지를 통해 재사용 여부를 요청한다.

 

 

 

If-None-Match

Response에서 받은 Etag Header 값을 이용하여 Data의 변동이 없는지의 확인을 통해 재사용 여부를 요청한다.

 

 

Dynamic

동적 콘텐츠로 규정된 확장자(,json, html ..)를 가진 Data로 해당 request는 cache 하지 않는다. 

 

Cloudflare 에서 Dynamic 콘텐츠를 caching 하고 no-store, no-cache, must-revalidate 값을 가지는 cache-control을 무시할 수 있는 설정 방법은 다음 내용에서 다루도록 하겠다.