[네트워크]HTTP 헤더 - 캐시와 조건부

📝캐시

캐시가 없으면 해당 페이지 새로고침마다 이미지 등을 다운받아야 한다.

이것은 매우 비효율적인 행위로 캐시는 자신의 브라우저에 저장되어 다운로드를 안하고 사용할 수 있다.

• 캐시는 유효 시간을 가지고 있으며, 유효 시간 만료 후의 특별한 로직을 가지고 있다.

 

Last-Modified + if-modified-since 

캐시 유효 시간이 초과해서 서버에 다시 요청하면 데이터가 변경이 안되어도 다시 다운받아야 한다.

이것을 해결하기 위한 방법이 Last-Modified + if-modified-since (검증헤더 + 조건부요청)이다.

 

밑은 코드는 캐시 생성 과정이다. 

해당 코드에서 60초 후 캐시가 만료되었을 때 요청을 다시보내면

서버에서 데이터 수정일을 비교하여 수정되지 않았다면 클라이언트는 다시 캐시를 재사용한다.

정리하면 다음과 같다

데이터 미변경 시
    캐시 : 2020년 11월 10일 vs 서버 : 2020년 11월 10일
     304 Not Modified, 헤더 데이터만 전송(Body 데이터 미포함)
데이터 변경 시 
    캐시 : 2020년 11월 10일 vs 서버 : 2020년 11월 11일
    200OK, 모든 데이터 전송

• Last-Modified + if-modified-since  단점
  • 날짜 기반 로직 사용
  • 데이터 수정해서 날짜는 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
  • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 

ETag + if-None-Match 

캐시용 데이터에 임의의 고유 버전 이름을 달아둔다.
     예)ETag : "v1.0", ETag: "asid93asdad"
데이터 변경되면 이 이름을 바꾸어서 변경한다.
     예) ETag  : "aaaa" -> ETag : "bbbb" 

• 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기이다.
• 장점
  • 캐시 제어 로직을 서버에서 완전히 관리한다.
  • 클라이언트는 단순히 이 값을 서버에 제공

 

📝캐시 헤더

Cache-Control

• Cache-Control : max-age
  • 캐시 유효 시간을 설정, 초 단위
• Cache-Control : no-cache
  • 데이터는 캐시해도 되지만, 항상 원 서버에서 검증하고 사용 -> 중간 서버에서 검증을 안함
• Cache-Control : no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 빠르게 사용 후 제거

Pragma

HTTP 하위호환으로 거의 사용안함

Expires

• expires: Mon, 01 Jan 1990 00:00:00 GMT
• 캐시 만료일을 지정 가능하나 캐시는 초 단위가 편함 

 

✔정리

• 검증 헤더 
  • ETag : "v1.0", ETag: "asid93asdad"
  • Last-Modified : Thu, 04 Jun 2020 07:19:24 GMT
• 조건부 요청 헤더 
  • If-Match, If-None-Match: ETag 값 사용
  • If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용