[http] http 헤더 - 2

캐시와 조건부 요청

캐시 기본 동작

• 캐시가 없으면?
  • 헤더 0.1 + 바디 1M
  • 또 요청하면?
  • 동일한 응답으로 리소스가 낭비됨.
• 데이터가 변경되지 않아도 네트워크를 통해서 데이터를 받아야 함
• http header
  • cache-control: max-age=60
  • 브라우저 캐시에 응답 결과를 저장
  • 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
  • 브라우저 로딩 속도가 빠름
    • 60초가 지나면 당연히 다시 네트워크 다운로드가 발생
    • 원래 데이터가 똑같다면 다시 요청하는게 좀 아깝기 때문

 

검증 헤더와 조건부 요청

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

• 서버 데이터가 변경되지 않았을때, 캐시를 다시 재활용하고 싶으면?
• Last-Modified: 데이터가 마지막에 수정된 시간
  • 응답 헤더에 기록해둠
• 캐시가 만료되면 if-modified-since 요청 헤더에 넘김
• 요청했는데 변경된게 없으면 서버에서는 304 Not Modified를 내려줄수 있음!
• 이 메소드로 응답을 내릴때는 응답 바디가 없음
  • 네트워크 부하를 확 줄일 수 있음
  • 기존 캐시 응답 결과를 재활용할 수 있음
• 캐시 유효시간이 초과돼도 바로 삭제하지 않고,
  서버의 데이터가 갱신되지 않으면 304 메소드와 응답 헤더 정보만 응답해서 클라이언트가 캐시에 저장되어 있는 데이터를 재활용함
• Last-Modified, ETag
• 캐시, 서버 데이터 같은지 검증
• If-Modified-Since: 이후에 데이터가 수정되었으면?
  
  1. 미변경시 304
  2. 변경시 200

• Last-Modified, If-Modified-Since 단점
  • 1초 미만 캐시 조정 불가, 초 단위까지 설정할 수 있음.
  • 날짜 기반 로직 사용
  • 데이터를 수정해서 날짜가 다르지만 같은 데이터인경우
  • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
• 앞의 단점을 개선한 ETag(Entity Tag)
  • 캐시용 데이터에 임의 고유 버전 이름을 달아놓음
  • 예) ETag: “V1.0”, ETag: “~~”
  • 데이터가 변경되면 이 이름을 바꾸어서 변경 (Hash 다시 생성)
  • 클라이언트는 간단해짐
    • 같으면 재활용, 다르면 새로 받음
• ETag, If-None-Match
  • 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기
  • 캐시 제어 로직을 서버에서 완전히 관리

 

캐시와 조건부 요청 헤더

• 캐시 제어 헤더
  • Cache-Control : 캐시 제어
    • max-age: 유효 시간, 초 단위
    • no-cache: 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
      • origin이라고 하는 이유는?
        캐시 서버에서는 검증하면 안되고, 요청에 대한 응답을 만드는 원 서버에서 검증해야 된다는거
    • no-store: 캐시로 저장하지 마라
  • Pragma
    • 하위 호환
  • Expires
    • 캐시 만료일
    • max-age가 있으면 무시됨
• 검증 헤더
  • ETag, Last-Modified
• 조건부 요청 헤더

 

프록시 캐시

• 한국에서 미국 서버로 요청한다면 0.5초라고 한다면
• 한국 어딘가에 프록시 캐시 서버를 거치도록 하면? 0.1 → 0.4
• 유투브 보면 한국에서 잘 안보는 외국 컨텐츠는 좀 느림
  • 한국 서버에 없어서
• 브라우저 캐시는 private 캐시, 프록시 서버의 캐시는 public 캐시
• Cache-Control: public
  • 응답이 퍼블릭 캐시에 저장해도 됨
• private
  • 응답이 해당 사용자만을 위한것
• s-maxage
  • 프록시에만 적용되는 max-age
• Age: 60
  • 오리진 서버에서 응답 후 프록시 캐시에 머문 시간

 

캐시 무효화

Cache-Control

• 확실한 캐시 무효화 응답
• 이 페이지는 절대 캐시되면 안돼!
  • Cache-Control: no-cache, no-store, must-revalidate
  • must-revalidate: 캐시 만료후 최초 조회시 원 서버에 검증해야함
  • Pragma: no-cache
• no-cache인 경우
  • 순간 프록시 캐시에서 원 서버 호출이 단절되는 경우에는?
  • 기본적인 로직은 오류보다는 오래된 데이터라도 보여주자
• must-revalidate
  • origin 서버 호출 단절되는 경우
  • 504 Gateway Timeout을 뱉음

---

내용 출처

• 모든 개발자를 위한 http 웹 기본 지식