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

캐시가 없을 때

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야한다.
• 인터넷 네트워크는 매우 느리고 비싸다
• 브라우저 로딩 속도가 느리다.(느린 사용자 경험)

캐시 적용

• cache-control: max-age =60 //캐시 지속시간(?) 60초로 설정
• 캐시 덕분에 캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다.
• 브라우저 로딩 속도가 매우 빠르다.
• 빠른 사용자 경험

캐시 시간 초과

• 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
• 이때 다시 네트워크 다운로드가 발생한다.(불필요한 손실)

캐시 시간 초과(해결방안)

검증헤더(Last-Modified)와 조건부(if-Modified-since) 요청

• 서버 데이터를 변경하지 않았을 경우(검증이 필요함)
• Last-Modified / if-modified-since 이 둘을 비교해서 변경 유무를 확인(날짜를 보고 비교하고 판단)
  • 304 Not Modified(변경 x), HTTP Body가 없다.헤더만 전송
  • 헤더가 0.1m, 바디가 1.0m라고 가정했을 때, 0.1m만 보내서 손실 최소화(효율성 상승)
• 서버 데이터가 변경되었을 경우
  • if-Modified-since와 Last-Modified가 서로 다름, 따라서 200 OK 호출되면서 모든 데이터 전송(헤더+바디)
• 단점
  • 초단위기 때문에 초 이하 단위로는 캐시 조정이 불가능
  • A->B로 수정했다가 B->A로 수정했다면, 결국 A로 결정됐는데 날짜가 다름. 따라서 전체 데이터를 다시 받게 됨.

검증헤더(ETag)와 조건부 요청(if-none-match)

• if-None-Match / ETag
• 조건이 만족하면 200, 그렇지 않으면 304
• 날짜가 아닌 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다.
  • 데이터가 변경되면 이 이름을 바꿔서 변경한다(Hash를 다시 생성)
• 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!
• 캐시 제어 로직을 서버에서 완전히 관리
• 사용 예) 서버는 베타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
  • 애플리케이션 배포 주기에 맞춰 ETag 모두 갱신

캐시 제어 헤더

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

프록시 캐시

• 원 서버 직접 접근(원 서버 : 진짜 리소스가 있는 서버)
  • 장거리에 위치한 서버에 빠르게 접속하기 위해 프록시 캐시 서버 구축
  • 프록시 캐시 서버는 public server
  • Cashe-Control 기본은 private

캐시 무효화

• 캐시가 되면 안되는 프로그램에 사용
• Cashe-Control: no-cache, no-store, must-revalidate(revalidate:재검증)
  • no-cache : 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
  • no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨
  • must-revalidate : 캐시 만료후 최초 조회시 원 서버에 검증해야함.
    • 네트워크 장애로 원서버에 요청이 닿지 않았을 때, 임시방편으로 프록시 서버에서 응답을 해주는 no-cache 정책이 있는데
    • must-revalidate는 항상 오류가 발생하도록 하는것(504 Gateway Timeout)
• pragma: no-cache : HTTP 1.0 하위 호환