<div id="readability-page-1" class="page"><div><h2 id="cache-맛보기">Cache 맛보기</h2>
<h3 id="캐시의-생명-주기cache-control">캐시의 생명 주기(cache-control)</h3>
<img src="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/f4514c23-1130-4868-967f-adcb7c874b5c/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2022-09-02_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.25.58.png">
no-cache(강제 재검증) vs no-store(캐싱을 하지않음)
cache-control에 no-cache 로 설정하면 캐시를 사용하지만 항상 서버(프록시서버, 리버스 프록시서버, CDN, 서버)에 재검증 요청을 보내게된다.
<img src="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/7d427313-5012-4726-b608-1be51afb5f19/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2022-09-02_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_7.35.26.png">
이런 강제 재검증을 해야하는 경우 max-age=0, must-revalidate 를 사용하는 경우도 있다. HTTP1.1 이전 버전에서는 no-cache를 제대로 처리를 못했기 때문에 사용했던 방법이다. 
no-store 는 아예 캐싱하지 않겠다는 설정이다. 브라우저에서 백 포워드 캐시를 활용하지 못한다.(페이지 뒤로가기, 앞으로가기)
한 줄 정리: no-store 보다는 no-cache 사용을 추천하며 no-cache와 private을 같이 사용하면 클라이언트에서는 항상 최신 버전을 유지할 수 있다.
private vs public
cache-control에 private 으로 설정하게 되면 오로지 웹 브라우저에서만 캐싱할 수 있음을 나타낸다. 중간 서버에서는 캐싱하지 않는다.
 사용시 주의할 점은 서버의 응답에 authorization 헤더가 있으면 private Cache에 저장되지 않는다.
public는 중간 서버에 캐싱할 수 있음을 나타낸다.
한 줄 정리: js, css 와 같은 정적 파일을 버저닝해서 public으로 관리한다면 중간 서버를 활용해서 서버의 부하를 줄일수 있다.
캐시의 유효기간(max-age)
최대 설정할 수 있는 기간은 1년이다.
캐시 유효기간을 표시할때 Expires를 쓰는 경우가 있지만 HTTP1.1 이전에 쓰던 방식이다.
s-maxage
중간 서버에서만 적용되는 max-age 값을 설정하기 위해 s-maxage 값을 사용할 수 있다.
만약 s-maxage=31536000, max-age=0 과 같이 설정하면 CDN에서는 1년동안 캐시되지만 브라우저에서는 매번 재검증 요청을 보내도록 설정할 수 있다.
이때 s-maxage가 유효하다면 클라이언트에서는 항상 CDN 에 재검증을 요청할 것이다.
서버에서 배포할 일이 생긴다면 CDN invalidation을 수행해서 캐시를 지운뒤에 새로운 버전을 CDN에 캐싱한다.
한 줄 정리: CDN을 사용한다면 s-maxage를 사용해서 서버의 부하를 줄일수 있다. 다만 서버에서 배포할 일이 생긴다면 직접 CDN invalidation을 수행해서 CDN에 최신 버전에 대한 캐싱이 이뤄지도록 해야한다.
재검증(Conditional Request)
캐시의 유효기간이 만료됐다면 클라이언트는 재검증 요청을 보낸뒤 기존 캐시를 재사용할지 결정한다. 이 때 두가지 방법으로 재검증을 할 수 있다.
If-Modified-Since vs ETag/If-None-Match
If-Modified-Since는 Last-Modifed를 비교해서 유효성 검증을 한다. 이때 Last-Modifed는 초 단위로 헤더에 저장되기 때문에 간발의 차이로 서버에서 최신 데이터를 빠르게 받아오지 못하는 경우가 생길 수 있다. 이런점을 보완하기 위해서 ETag/If-None-Match를 사용한다.
ETag/If-None-Match는 시간이 아닌 태그로 유효성 검증을 하기 때문에 클라이언트는 항상 최신 데이터를 빠르게 받아올 수 있다.
Last-Modified 와 ETag 를 같이 쓰는 경우가 있다. 이 경우 재검증을 할때 당연히 ETag를 사용하며 Last-Modified는 캐싱 외에 크롤러에게 마지막 수정 시간을 알려주어 크롤링 빈도를 조정할 수 있다.
<h3 id="휴리스틱-캐싱">휴리스틱 캐싱</h3>
만약 응답에 Cache-Control, Expires 헤더가 들어있지 않다면 브라우저는 휴리스틱을 사용하여 자체적으로 캐시 유효기간을 계산한다.
휴리스틱 캐싱을 사용하지 않는 이유는 서버입장에서 휴리스틱 캐싱이 이뤄진 브라우저의 해당 캐시를 제거할 방법이 없다. 즉 클라이언트가 서버에서 최신 데이터를 받아올 수 없게 된다.
한 줄 정리: 즉 효과적으로 캐시를 사용하기 위해서는 Cache-Control를 꼭 사용하자.
<h3 id="캐시-무효화cache-busting">캐시 무효화(Cache Busting)</h3>
<h3 id="spring에-적용해보기">Spring에 적용해보기</h3>
Control-Cache 설정하는 법
WebContentInterceptor
Etag 설정하는 법
FilterRegistrationBean, ShallowEtagHeaderFilter
응답 압축하기
캐시 무효화 설정하기
<code>WebMvcConfigurer</code> 의 <code>addResourceHandlers</code> 재정의
구구강의
클레이, 블링, 필즈와의 대화
<a href="https://toss.tech/article/smart-web-service-cache">https://toss.tech/article/smart-web-service-cache</a>
<a href="https://paulcalvano.com/2018-03-14-http-heuristic-caching-missing-cache-control-and-expires-headers-explained/">https://paulcalvano.com/2018-03-14-http-heuristic-caching-missing-cache-control-and-expires-headers-explained/</a></div></div>

0_0_yoon.log

yoon

Cache 맛보기
캐시의 생명 주기(cache-control)
no-cache(강제 재검증) vs no-store(캐싱을 하지않음)
cache-control에 no-cache 로 설정하면 캐시를 사용하지만 항상 서버(프록시서버, 리버스 프록시서버, CDN, 서버)에 재검증 요청을 보내게된다.
이런 강제 재검증을 해야하는 경우 max-age=0, must-revalidate 를 사용하는 경우도 있다. HTTP1.1 이전 버전에서는 no-cache를 제대로 처리를 못했기 때문에 사용했던 방법이다. 
no-store 는 아예 캐싱하지 않겠다는 설정이다. 브라우저에서 백 포워드 캐시를 활용하지 못한다.(페이지 뒤로가기, 앞으로가기)
한 줄 정리: no-store 보다는 no-cache 사용을 추천하며 no-cache와 private을 같이 사용하면 클라이언트에서는 항상 최신 버전을 유지할 수 있다.
private vs public
cache-control에 private 으로 설정하게 되면 오로지 웹 브라우저에서만 캐싱할 수 있음을 나타낸다. 중간 서버에서는 캐싱하지 않는다.
 사용시 주의할 점은 서버의 응답에 authorization 헤더가 있으면 private Cache에 저장되지 않는다.
public는 중간 서버에 캐싱할 수 있음을 나타낸다.
한 줄 정리: js, css 와 같은 정적 파일을 버저닝해서 public으로 관리한다면 중간 서버를 활용해서 서버의 부하를 줄일수 있다.
캐시의 유효기간(max-age)
최대 설정할 수 있는 기간은 1년이다.
캐시 유효기간을 표시할때 Expires를 쓰는 경우가 있지만 HTTP1.1 이전에 쓰던 방식이다.
s-maxage
중간 서버에서만 적용되는 max-age 값을 설정하기 위해 s-maxage 값을 사용할 수 있다.
만약 s-maxage=31536000, max-age=0 과 같이 설정하면 CDN에서는 1년동안 캐시되지만 브라우저에서는 매번 재검증 요청을 보내도록 설정할 수 있다.
이때 s-maxage가 유효하다면 클라이언트에서는 항상 CDN 에 재검증을 요청할 것이다.
서버에서 배포할 일이 생긴다면 CDN invalidation을 수행해서 캐시를 지운뒤에 새로운 버전을 CDN에 캐싱한다.
한 줄 정리: CDN을 사용한다면 s-maxage를 사용해서 서버의 부하를 줄일수 있다. 다만 서버에서 배포할 일이 생긴다면 직접 CDN invalidation을 수행해서 CDN에 최신 버전에 대한 캐싱이 이뤄지도록 해야한다.
재검증(Conditional Request)
캐시의 유효기간이 만료됐다면 클라이언트는 재검증 요청을 보낸뒤 기존 캐시를 재사용할지 결정한다. 이 때 두가지 방법으로 재검증을 할 수 있다.
If-Modified-Since vs ETag/If-None-Match
If-Modified-Since는 Last-Modifed를 비교해서 유효성 검증을 한다. 이때 Last-Modifed는 초 단위로 헤더에 저장되기 때문에 간발의 차이로 서버에서 최신 데이터를 빠르게 받아오지 못하는 경우가 생길 수 있다. 이런점을 보완하기 위해서 ETag/If-None-Match를 사용한다.
ETag/If-None-Match는 시간이 아닌 태그로 유효성 검증을 하기 때문에 클라이언트는 항상 최신 데이터를 빠르게 받아올 수 있다.
Last-Modified 와 ETag 를 같이 쓰는 경우가 있다. 이 경우 재검증을 할때 당연히 ETag를 사용하며 Last-Modified는 캐싱 외에 크롤러에게 마지막 수정 시간을 알려주어 크롤링 빈도를 조정할 수 있다.
휴리스틱 캐싱
만약 응답에 Cache-Control, Expires 헤더가 들어있지 않다면 브라우저는 휴리스틱을 사용하여 자체적으로 캐시 유효기간을 계산한다.
휴리스틱 캐싱을 사용하지 않는 이유는 서버입장에서 휴리스틱 캐싱이 이뤄진 브라우저의 해당 캐시를 제거할 방법이 없다. 즉 클라이언트가 서버에서 최신 데이터를 받아올 수 없게 된다.
한 줄 정리: 즉 효과적으로 캐시를 사용하기 위해서는 Cache-Control를 꼭 사용하자.
캐시 무효화(Cache Busting)
Spring에 적용해보기
Control-Cache 설정하는 법
WebContentInterceptor
Etag 설정하는 법
FilterRegistrationBean, ShallowEtagHeaderFilter
응답 압축하기
캐시 무효화 설정하기
WebMvcConfigurer 의 addResourceHandlers 재정의
구구강의
클레이, 블링, 필즈와의 대화
https://toss.tech/article/smart-web-service-cache
https://paulcalvano.com/2018-03-14-http-heuristic-caching-missing-cache-control-and-expires-headers-explained/

Cache 맛보기

댓글