캐시가 없다면 해당 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
인터넷 네트워크는 매우 느리고 비싸다.
이를 해결하기 위한것이 '캐시'

캐시를 적용하면 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
비싼 네트워크 사용량을 줄일 수 있다.

캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.

캐시 유효 시간이 초과하여 서버를 통해 데이터를 다시 조회하는데, 데이터가 갱신되지 않았다면 굳이 데이터를 다운받지 않아도 캐시 유효시간만 갱신해도 된다.
이를 위해 사용하는 HTTP 헤더가
If-modified-since - 시간을 입력해서 변하지 않았다면 304 Not Modified를 받는다.(HTTP Body가 없다)

If-modified-since(응답: Last-Modified) 단점
1초 미만 단위로 캐시 조정 불가능, 수정 날짜가 다르지만 데이터는 같은 경우 - 체크 안됨
이를 위해 ETag(응답), If-None-Match(요청) 사용

ETag(Entity Tag)
캐시 데이터에 임의의 고유한 버전 이름을 달아둠, 데이터가 변경되면 이름을 변경

• 이름만 체크해서 변경 감지 가능, 캐시 제어 로직을 서버에서 완전히 관리(클라는 단순히 이 값을 서버에 제공)

캐시 제어 헤더
Cache-Control: 캐시 제어
(max-age: 캐시 유효 기간, no-cache: 항상 오리진 서버에 검증하고 캐시 사용, no-store: 저장x)
Pragma: 캐시 제어(하위 호환)
Expires: 캐시 유효 기간(하위 호환)

프록시 캐시

클라와 서버 중간에 있는 작은 캐시 서버?

캐시 지시어
(Cache-Control)
public: public 캐시에 저장 가능
private: 사용자만을 위한것(기본값)
s-maxage: 프로시 캐시에 적용되는것

캐시 무효화

Cache-Control: no-cache, no-store, must-revalidate

no-cache vs must-revalidate
no-cache는 프록시 캐시에있는 데이터도 믿음
must-revalidate는 프록시 캐시에 있는 데이터 안믿음
ex) 오리진 서버에 문제가 생겨서 프로시 캐시 서버를 이용한다면,
no-cache는 200 OK
must-revalidate는 504 Gateway Timeout