[인프런] 모든 개발자를 위한 HTTP 웹 기본 지식 (HTTP 헤더 - 캐시와 조건부 요청2)
캐시 제어 헤더와 조건부 요청 헤더에 대해 알아보고, 프록시 캐시와 캐시 무효화하는 방법까지 살펴보자.
캐시와 조건부 요청 헤더
캐시 제어 헤더
- cache-control: 여러 지시어를 통해 캐시를 제어함
- max-age 캐시 유효 시간을 초 단위로 작성하는 지시어
- no-cache 데이터는 캐시해도 되지만, 항상 원서버(Origin Server)에 검증하고 사용
- no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨 → 메모리에서 사용하고 최대한 빨리 삭제
- public 응답(데이터)이 public 캐시에 저장되어도 됨
- private 응답(데이터)이 해당 사용자만을 위한 것임, 원래 기본값으로 private 캐시에 저장해야 함
- must-revaildate 캐시 만료 후 최초 조회시, 원서버(Origin Server)에 검증해야 함 → 원서버에 접근 실패시 반드시 504 Gateway Timeout 오류 발생
- pragma: 캐시 제어 헤더인데, HTTP 1.0 하위 호환을 원할 때만 사용
- expires: 캐시 만료일을 정확한 날짜로 지정하는 것인데, HTTP 1.0부터 사용한 거라서 지금은 cache-control: max-age를 권장함
검증 헤더 (Validator)
- ETag
- last-modified
조건부 요청 헤더
- if-match, if-none-match → ETag 값 사용
- if-modified-since, if-unmodified-since → last-modified 값 사용
프록시 캐시
클라이언트가 원서버에 있는 데이터에 직접 접근하지 않고, 중간 다리 역할인 프록시 서버에 있는 캐시에 접근한다. 그러면 데이터를 불러오는 시간을 단축할 수 있게 된다.
프록시 캐시 서버에 있는 캐시는 여러 브라우저에서 접근할 수 있도록 해야하기 때문에 public이다.
캐시 무효화
캐시를 하지 않았는데 브라우저가 임의로 캐시하는 경우가 있다. 그런데 사용자 통장 잔고 등 절대로 캐시가 되면 안되는 페이지에 이런 경우가 발생하면 문제가 되기 때문에, 확실하게 캐시를 하지 않도록 설정해줄 필요가 있다.
- cache-control: no-cache, no-store, must-revalidate
- pragma: no-cache
이렇게 설정해주면 확실한 캐시 무효화 응답이 된다.
그런데 여기서 no-cache, must-revalidate는 역할이 같아보인다. 둘다 캐시를 원서버에 검증하고 사용하기 때문이다. 그럼 굳이 이 두개를 다 설정해줘야 하는지 의문이 들 수 있는데, 사실 두 지시어는 비슷하지만 차이점이 있다.
no-cache 기본 동작을 보면 다음과 같다.
그런데 만약 순간 네트워크가 단절되어 원서버에 접근이 불가할 경우, 프록시 캐시는 오류를 보내기 보다는 그냥 이전 데이터라도 보여주는 게 낫다고 생각하여 이전 데이터를 보내 응답한다. 예를 들어서 계좌이체를 했는데 액수가 변하지 않고 이전 상태 그대로라면 혼란스러울 것이다.
그렇기 때문에 must-revalidate가 필요하다.
must-revalidate는 원서버에 접근할 수 없으면 무조건 오류를 발생시켜 응답한다. 이런 과정을 모두 거쳐야 확실한 캐시 무효화를 한다고 말할 수 있다.