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

출처 : https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

캐시가 없다면 데이터가 변경되지 않아도 계속 네트워크를 통해서 동일한 데이터를 받아야한다.

데이터의 용량이 크다면 이는 로딩 속도가 느려지게 된다.

캐시를 적용해보자.

캐시를 적용함으로써 캐시 가능 기간동안은 네트워크를 사용하지 않아도 된다.

기존 로컬에서 가지고 있기에 로딩 속도가 매우 빠르다.

 

하지만 만약 캐시 시간이 초과된다면?

서버를 통해 다시 데이터를 조회하고 캐시를 갱신해야겠지. 이 때 다시 네트워크 다운로드가 발생한다.

 

캐시 유효 시간이 초과되서 서버에 다시 요청하면 두 가지 상황이 생긴다.

1. 서버에서 그 사이 기존 데이터를 변경한 경우

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

 

만약 2번의 경우처럼 기존 데이터를 변경하지 않은 경우라면 굳이 다시 똑같은 데이터를 받는 것보다는

클라이언트 안의 캐시의 데이터와 서버의 데이터가 같다라는 것만 파악하면 

서버의 데이터를 다시 받지 않고 캐시의 데이터를 재활용하면 된다.

이를 위해 검증헤더 + 조건부요청을 활용한다.

캐시 유효시간이 초과되어도, 서버의 데이터가 갱신되지 않았다면 
304 Not Modified + 헤더 메타 정보단 응답 받음으로써 캐시에 저장되어 있는 데이터를 재활용한다.

 

 

• 검증 헤더
  캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  Last-Modified, ETag
  
  
• 조건부 요청 헤더
  검증 헤더로 조건에 따른 분기
  If-Modified-Since : Last-Modified 사용
  If-None-Match : ETag 사용
  조건이 만족하면 200 OK
  조건이 만족하지 않으면 304 Not Modified.

 

*Last-Modified, If-Modified-Since의 단점

1초 미만 단위로 조정 불가.

같은 데이터를 수정해서 날짜는 다르지만 데이터의 결과는 같을 경우 문제가 생김.

(분명 데이터는 같은데 해당 로직으로는 다른 데이터라 판단해서 데이터를 다시 서버에서 받으므로)

 

-> 이를 해결하고자 ETag를 사용한다.

ETag(Entity Tag), If-None-Match

캐시용 데이터에 임의의 고유한 버전 이름을 달아두는 것(보통 hash함수를 사용)

데이터가 변경되면 이 이름을 바꾸어서 변경함.

ETag만 보내서 같으면 유지하고, 다르면 다시 받기!

 

*Cache-Control

• Cache-Control : max-age 
  캐시 유효 시간, 초 단위
• Cache-Control : no-cache
  데이터는 캐시해도 되지만, 항상 원(origin)서버에 검증하고 사용.
• Cache-Control : no-store
  데이터에 민감한 정보가 있으므로 저장하지 말고 최대한 빨리 삭제.

 

<프록시 캐시>

 

<캐시 무효화>

• Cache-Control : no-cache, no-store, must-revalidate
• Pragma : no-cache(HTTP 1.0 하위호환)

no-cache와 must-revalidate의 가장 큰 차이점은

프록시 캐시와 원 서버가 단절되서 접근이 불가할 경우

no-cache는 오류보다는 오래된 데이터라도 다시 웹 브라우저에 보내줌으로써 OK를 보낼 수도 있다.

하지만 must-revalidate의 경우 무조건 원 서버를 거쳐야한다고 명시하는 것이기 때문에 504 Gateway Timeout이 난다.