Web cache 간단 정리

캐시를 사용해야하는 이유

• 캐시 없이 매번 데이터를 다운로드하면,
  • 네트워크로 매번 데이터를 다운로드하면 느리고, 비싸다.
  • 브라우저 로딩 속도가 느리다
  • 사용자에게 표시되는 속도가 느려 사용자 경험 측면에서 불리
• 캐시를 적용하는 것으로,
  • 캐시 가능 시간동안 네트워크 사용이 감소
  • 브라우저 로딩 속도가 빠르다.
  • 사용자 경험 측면에서 유리

캐시 유효시간, 검증 헤더, ETag

• 캐시 유효시간이 만료되면, 서버에 다시 다운로드를 요청한다.
• 이때, 마지막으로 수정된 시간 Last-Modified 를 통해 변경 여부를 확인
  • 변경되지 않았다면 304 Not modifed 코드와 함께 빈 http body 를 응답한다. (헤더만 응답)
  • 클라이언트는 캐시 데이터 재활용 & 메타 정보 갱신
• 수정된 시간 외에도 ETag 를 통해 데이터가 동일한지 확인
  • 검증 헤더로 분기
    • If-None-Match: ETag 사용
      • 캐시 제어 로직을 서버에서 관리
    • If-Modified-Since: Last-Modified 사용

Cache-Control

• 캐시 지시어(directives)
  • Cache-Control: max-age : 캐시 유효 시간, 초 단위
  • Cache-Control: no-cache : 데이터는 캐시해도 되지만, 항상 원 서버에 검증 후 사용
  • Cache-Control: no-store : 저장하지 않음
    • ex) 민감한 정보로 저장하면 안되는 등
  • Cache-Control: must-revalidate : 캐시 만료후 최초 조회시 원 서버에 검증해야함
    • no-cache 와 차이는 캐시 프록시 서버에서 원 서버 접근 불가시, no-cache는 캐시 프록시 설정에 따라 응답이 가능하지만 must-revalidate 는 504 Gateway timeout을 리턴

Expires

• 캐시 만료일을 명시적으로 지정
  • expires 보다는 Cache-Control: max-age 사용 권장
  • 둘을 동시 사용할 경우 expires 는 무시됨