캐시에는 항상 위계가 있다.
- CDN은 캐시 서버를 구성하는 물리/논리적 방법에 대한 이야기
- HTTP Cache-Control은 개별 HTTP 요청의 캐싱 정책을 다룸
HTTP Cache
- HTTP 캐시 위계 중 서버와 브라우저 사이에 위치한다.
- CDN이 주든, Origin 서버가 주든 관계 없이 HTTP 캐시가 어떻게 적재되고 어떻게 관리할 것인지에 관한 문제
- CDN은 인프라의 영역이라면, HTTP 캐시는 개발의 영역이다.
max-age
- 캐시의 유효 기간을 설정한다.
- '서버가 데이터를 발행한 시점을 기준으로 몇 초동안 캐시가 유효할 것인가?'를 정함
- 유저 입장에서의 max-age라고 볼 수 있으나 s-max-age 헤더 키가 없다면 공유 프록시도 max-age 사용
s-max-age
- CDN을 위한 max-age
- 공유 proxy에서 저장되는 최대 시간
- 프록시 서버(중계 서버)에서의 max-age
max-stale
- 만료된 캐시의 사용 최대 시간이 얼마까지 인지
- stale한 캐시를 쓰는 데에 대한 타임아웃
- stale한 캐시를 보여주고 그 사이에 revalidate를 시킨 다음 revalidate를 마치면 stale한 캐시는 날아감
Expires
- HTTP 1.0에서 제시된 캐시 유효기간 헤더
- 날짜 파싱 버그로 지금은 사용 추천하지 않음
- 아주 예전의 브라우저를 지원하기 위해 사용하는 경우는 있음
Age
- Proxy cache에서 넘어온 HTTP 응답에 대해 보관한 시간을 설명
- 보통 서비스는 직접 발행하기 때문에 0이 일반적이다.
Access-Control-Max-Age
- Preflight 요청(OPTIONS 메소드로 이뤄지는 요청)에 대한 응답인 Access-Control-Allow-Methods에 대한 유효기간
no-cache
- 간단하게 캐시하지 않음을 나타낼 수 있음
- age=0, must-revalidate와 동일함
- 리소스를 요청할 때마다 origin 서버에 검증을 요청함
- 브라우저에 저장은 하고 매번 원 서버에 검증을 요청함
no-store
- 아무도 캐시하지 마라
- 리소스를 하드디스크에도 저장하지 않고 항상 서버에서 가져옴
- 프록시 포함 저장하지 않음(CDN도 캐시하지 않도록 함)
stale
- 캐시가 시간이 지나서 다시 갱신이 필요할 때
- max-age가 지나고 나서부터 stale 상태로 들어감
- stale-while-revalidate(SWR) : stale 상태 동안에도 캐시 정보는 다시 쓴다.
- stale-if-error : 서버에서 에러가 발생하면 stale 상태에서도 캐시를 재활용한다.
Etag
- 브라우저에서 캐시 정보를 갱신할 때 버전 리소스를 확인하는 코드
- 클라이언트는 서버에 현재 내가 가지고 있는 캐시된 리소스 Etag 전송
If-Match
- If-Match 헤더를 포함하여 요청을 전송할 경우, 서버는 헤더에 포함된 ETag 값과 서버의 리소스 ETag 값이 일치하는지 확인한다. 일치하면 요청이 정상적으로 처리되고, 일치하지 않으면 서버는 일반적으로 412 Precondition Failed 응답을 반환한다.
If-None-Match
- 요청 헤더에 포함된 ETag 값과 서버의 리소스 ETag 값이 일치하지 않으면 갱신된 ETag 값을 보낸다.
- 리소스가 바뀌었으나 실제로는 그렇게 중요하지 않은 변경 사항이어서 옛날 리소스를 그대로 써도 되는 경우 = 유의미한 변경 내용에만 캐시를 변경하고 싶을 때
If-Modified-Since
- 특정 날짜 기준으로 캐시가 바뀌었는지 안바뀌었는지 판별
If-Modified-Since vs If-None-Match
- If-Modified-Since 기준으로는 캐시를 갈아야 하는데 If-None-Match 기준으로는 Etag가 일치하는 경우?
- 보통 304 Not Modified
- 실제 RFC를 확인하여 권장사항을 확인해보긴 해야함
조건부 헤더의 경쟁 조건 해지
min-fresh
- 클라이언트가 캐시가 필요한 시간을 지정할 수 있음
- 예를 들어 1일 이상 살아남을 수 있는 캐시를 요청할 수 있음
- 서버의 판단에 따라 응답이 달라짐
must-revalidate
- 항상 캐시를 해선 안되고 만료된 리소스를 사용하면 안됨
no-transform
- 프록시 서버 등이 임의로 HTTP 헤더 내용을 변경해서는 안됨
public, private
- public : 공개 캐시에 저장될 수 있는 캐시
- private : 특정 사용자/그룹만 사용해야 하는 캐시
- 그러나 실무에서는 private 캐시는 사용하지 않을 가능성이 높다. 데이터의 주소를 적당히 숨김으로써 주소를 확보하는 편이다.
