WEB

HTTP header 2 - 검증 헤더와 조건부 요청

날라루 2024. 5. 30. 18:59

캐시 만료 후에도 서버에서 데이터가 변경되지 않은 경우

  • 다시 클라이언트로 데이터를 전송하는 방법 대신 저장해두었던 로컬 캐시를 재사용하는 방법
  • 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인해야 함
image image
  • 캐시 유효 시간이 초과해도 서버의 데이터가 갱신되지 않았다면 304 Not Modified + 헤더 메타 정보만 응답(바디X)
  • 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시 메타 정보 갱신
  • 클라이언트는 캐시에 저장되어 있는 데이터를 재활용
  • 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드하면 되므로 비용 절감

검증 헤더

  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  • Last-Modified, ETag

조건부 요청 헤더

  • 검증 헤더로 조건에 따른 분기
  • If-Modified-Since : Last-Modified 사용
  • If-None-Match : ETag 사용
  • 조건이 만족하면 200 OK 모든 데이터 전송(Body 포함), 만족하지 않으면 304 Not Modified 헤더 데이터만 전송(Body 미포함)

If-Modified-Since, Last-Modified

  • 1초 미만 단위로 캐시 조정 불가
  • 날짜 기반 로직 사용으로 데이터 수정으로 날짜값은 다르지만 결과는 같은 데이터도 다른 데이터로 인식
  • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
    • ex) 스페이스나 주석처럼 크게 영향이 없는 변경으로 캐시를 유지하고 싶은 경우

If-None-Match, ETag(Entity Tag)

  • 캐시용 데이터에 임의의 고유한 버전이름을 달아둠
    • ex) ETag: "v1.0" , ETag: "hello11"
  • 데이터가 변경되면 이 이름을 변경(Hash 다시 생성)
    • ex) ETag: "v1.0" → ETag: "v2.0"
  • ETag를 전송해서 같으면 유지, 다르면 다시 받기
image
  • 캐시 제어 로직을 서버에서 완전히 관리, 클라이언트는 단순히 ETag 값을 서버에 제공

캐시 제어 헤더

  • Cache-Control : 캐시 제어
    • cache directives
    • max-age 캐시 유효 시간, 초단위. 이전에는 Expire 헤더로 많이 사용 됐으나 현재는 훨씬 유연한 Cache-Control: max-age=? 사용 권장
    • no-cache 데이터를 캐시하지만 If-Modified-Since,If-None-Match 등으로 언제나 origin 서버에 검증
    • no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용후 빨리 삭제)
    • public 응답이 프록시캐시 서버 내 public 캐시에 저장되어도 됨
    • private 응답이 해당 사용자만을 위한 것임. private 캐시에 저장되어야함(default)
    • s-maxage 프록시 캐시에만 적용되는 max-age