HTTP 헤더 - 캐시와 조건부 요청

캐시 기본 동작

 

캐시가 없을 때 - 데이터를 자주 다운로드 받아야 해. 느린 사용자 경험

 

캐시 적용 -  (캐시유효시간검증)  캐시 가능 시간동안 네트워크를 사용하지 않음. 빠른 경험

 

      캐시 시간 초과 -  서버를 통해 데이터를 다시 조회하고, 캐시를 갱신 

                             이때, 다시 네트워크 다운로드가 발생

 

             1. 서버에서 기존 데이터를 변경함

             2. 서버에서 기존 데이터를 변경하지 않음

정리

- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신 되지 않으면

- 304 Not Modified + 헤더 메타 정보만 응답(바디X)

- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신

- 클라이언트는 캐시에 저장되어 있는 데이터 재활용

- 결과적으로 네트워크 다운로드가 발생하지만, 용량이 적은 헤더 정보만 다운로드

- 매우 실용적인 해결책

 

>> 웹브라우저는 다 이 방법 사용함!

 

검증헤더 

 - Last-Modified, ETag

 

조건부 요청 헤더

 - If-Modified-Since: Last-Modified사용

 - lf-None-Match: ETag사용

 

캐시 제어 헤더

★Cache-Control: 캐시 제어

Cache-Control : max-age  캐시유효시간, 초 단위

 

Cache-Control: no-cache 데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용

 

Cache-Control: no-store 데이터에 민감한 정보가 있으므로, 저장하면 안됨

 

Pragma:캐시 제어(하위호환)

Expires:캐시 유효 기간(하위호환)

 

프록시 캐시

 

캐시 무효화

*확실한 캐시 무효화 응답 방법

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

Pragma:no-cache

 

must-revaldate : 캐시 만료 후 최초 조회시 원 서버에 검증해야함.

                       원 서버 접근 실패시 반드시 오류 발생해야함-504

                   

 

no-cache 뿐 만 아니라, must- revaldate 까지 왜 사용하나?

>>> 순간 원 서버에 접속 할수 없는 상태일떄, 프록시 서버 설정이 과거 데이터를

보여주게 설정 되어 있다면, 낭패를 볼수 가 있기 때문에, 확실하게 하기 위해서.

 

[출처]- 인프런 김영한  '모든 개발자를 위한 HTTP 웹 기본 지식']  강의듣고 정리