HTTP - header2

캐시와 조건부 요청

캐시 기본 동작

1. 클라이언트가 서버에 요청

2. 서버는 응답에 캐시가 유효 조건을 적어서 응답

3. 클라이언트는 응답 결과는 브라우저 캐시에 저장

4. 다음 요청부터는 캐시 가능 여부를 확인하고 가능하다면 캐시에서 조회. 불가능하다면 재요청

* 캐시 가능 기간동안 네트워크를 사용하지 않아도 됨 -> 비싼 네트워크 사용량을 줄일 수 있음

* 브라우저 로딩 속도가 매우 빨라진다 -> 사용자 경험 향상!

 

검증 헤더와 조건부 요청

-> 유효 시간이 초과했을 때 서버에 재요청했을 때 가능한 경우의 수는 두 가지

1. 기존 데이터가 변경됨

2. 기존 데이터가 변경되지 않음

만약 캐시 만료 후에도 서버에서 데이터를 변경하지 않은 경우라면 캐시를 재사용 할 수 있음. 이 경우 캐시된 데이터가 서버의 데이터와 일치한다는 사실을 확인할 수 있는 방법 필요

-> 해당 문제를 해결하기 위해 검증 헤더(캐시 데이터와 서버 데이터가 같은지 검증하는 데이터) 추가

검증 헤더로 분기하여 조건이 만족하면 200 OK, 만족하지 않으면 304 Not Modified

 

Last-Modified: 마지막으로 변경된 시각

ETag(Entity Tag): 캐시용 데이터의 임의의 고유한 버전. 데이터가 바뀌었다면 Hash등을 사용하여 이름을 바꾸어서 변경

 

캐시 가능 여부를 시간으로 정한 경우

최종 수정일을 추가하여 검증

캐시가 만료되었더라도 헤더에 최종 수정일을 추가하여 검증할 수 있다. 이때 응답은 헤더만 반환!

 

하지만 시간으로 캐시 가능 여부를 체크하는 것은 1초 미만 단위로 캐시 조정이 불가능하고 같은 데이터로 수정되어 수정된 날짜는 다르지만 데이터 결과가 같은 경우를 체크할 수 없다.

 

캐시 가능 여부를 ETag로 정한 경우

캐시 제어 로직을 서버에서 완전히 관리할 수 있으므로 편해짐!

 

캐시 제어 헤더

Cache-Control: 캐시 제어

* max-age: 캐시 유효 시간 (초 단위)

* no-cache: 데이터는 캐시해도 되지만 항상 본(origin) 서버에서 검증하고 사용

* no-store: 민감한 정보가 있으므로 캐시하면 안됨

 

프록시 캐시

클라이언트가 저~~~ 멀리 있는 본(origin) 서버에 접근하려면 물리적으로 오래 걸림

따라서 응답 속도를 높이기 위해 클라이언트 가까운 곳에 캐시를 위한 프록시 서버를 하나 둠 -> Public Cache

 

Cache-Control

* public: 응답이 public 캐시에 저장되어도 됨

* private: 응답이 해당 사용자만을 위한 것으로 private 캐시(클라이언트)에 저장해야 함 (기본 값)

* s-maxage: public 캐시에만 적용되는 max-age

 

캐시 무효화

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

-> 확실한 캐시 무효화 응답

* must-revalidate: 캐시 만료 후 최초 조회 시 본(origin) 서버에 검증해야 함. 본 서버 접근 실패시 반드시 오류 발생 (캐시 유효 기간이라면 캐시를 사용함)