앞서 캐시의 사용 이유와 캐시의 장점에 대해 작성하고, 이러한 캐시를 어떻게 정보의 실시간성을 유지하는지에 대해 작성 했습니다. 이번에는 이 캐시를 직접적으로 제어하는 내용에 대해 작성 해 보겠습니다.
Cache-Control Header
캐시를 저장 하냐 마냐, 캐시 데이터를 재검증 받냐 등... 다양한 캐시의 요청을 관리하는 것은 바로 서버 입니다. 웹 브라우저 캐시가 비록 Client 사이드에 존재하지만, 데이터를 직접 생성 밑 전송하는 것은 바로 Server 입니다. 그렇기 때문에, 서버에서 캐시 데이터 관리하는 헤더를 통해 캐시 데이터의 유효성 검증 및 저장 유무를 관리하게 됩니다.
Cache-Control Header 세부 속성
해당 사진은 서버에서 준 응답 메시지의 헤더 영역에 담긴 Response Header 입니다. 저런 식으로 서버가 Response Header의 Cache-Control 영역에 캐시 설정이 가능한 속성 값들을 전달 해 주게 됩니다.
캐시 저장 여부
no-store: 캐시 안함no-cache: 캐시 함. 단, 매번 재검증 후 사용(패킷 경량화). 캐시를 하지 말라는 것이 아님.
캐시 저장 장소
public: Private (웹 브라우저) + Shared (프록시) 모두에 저장private: Private (웹 브라우저)에만 저장
캐시 재검증 주기
max-age: Expires(유효시간)으로 변환(기존 Expires 가 있다면 덮어씀)max-age가 0일 경우, 매번 재검증 하라는 의미를 가짐.
-s-maxage: 프록시 캐시에만 적용되는 유효기간.
재검증 강제
-must-revalidate: 꼭 웹 서버와 직접 재검증이 완료된 캐시를 사용해야 함.
서버와의 접속 문제가 있을 경우, 재검증이 실패하면 기존 캐시를 반환하지만 해당 정책을 활성화 하면 504 메시지 발생
SWR(Stale-While-Revalidate)
-stale-while-revalidate: 현재 캐싱된 컨텐츠를 즉시 로드하는 즉시성 + 미래에 업데이트 된 캐싱 컨텐츠가 사용될 수 있도록 보장하는 최신성. 재검증 요청을 동시에 하며 오래된 캐시를 반환함.
📑 출처 및 참조
[ASAC] 강의 자료
https://stackoverflow.com/questions/36020837/cache-control-headers-max-age-defined-but-back-button-always-deliver-web-cache
