• 웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치

    • 불필요한 데이터 전송으로 인한 네트워크 비용 감소

      • 지속적인 동일한 데이터 요청은 중복 트래픽이 발생함

    • 대역폭으로 인한 네트워크 병목 감소

      • 클라이언트들이 서버에 접근할 때의 속도는 그 경로에 있는 가장 느린 네트워크의 속도와 같음

    • 서버 부하 감소

      • 갑작스런 과도한 요청은 웹 서버에 과부하를 줌

    • 서버 거리로 인한 지연 감소

      • 대역폭이 문제되지 않더라고 거래가 문제될 수 있음

      • 빛의 속도 그 자체가 유의미한 지연을 유발할 수 있음

적중과 부적중

  • 캐시 적중(cache hit): 캐시 요청이 도착했을 때 대응하는 사본이 있어 그 요청을 처리 할 수 있는 경우

  • 캐시 비적중(cache miss): 요청에 대해 대응하는 사본이 없을 경우 그대로 원 서버에 전달되는 경우

  • 재검사(revalidation): 캐시 내의 사본들이 최신인지 서버를 통해 점검하는 것

    • 서버에 재검사 요청을 보냈을 때, 콘텐츠가 변경되지 않았다면 304 Not Modified 응답을 보냄

    • 위와 같은 경우는 '재검사 적중' or '느린 적중’이라 함

      • 순수 캐시 적중보다는 느림. because of 검사 비용

      • 캐시 부적중보다는 빠름. because of 서버로부터 객체 데이터를 받아올 필요가 없으므로

      • 실패한 재검사는 부적중과 거의 같음.

  • HTTP는 캐시된 객체를 재확인하기 위해 몇 가지 도구를 제공함

    • If-Modified-Since Header

      • 서버 콘텐츠가 변경되지 않은 경우(재검사 적중): 서버는 304 Not Modified 응답을 보냄

      • 서버 콘텐츠가 변경된 경우: 서버는 변경된 콘텐츠와 200 OK 응답을 보냄

      • 객체가 삭제된 경우: 서버는 404 Not Found 응답을 보내고, 캐시는 사본을 삭제함

  • 적중률(≒ 문서 적중률): 캐시가 요청을 처리하는 비율

    • 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지 보여줌

    • 이를 개선하면 전체 대기시잔(지연)이 줄어듬

  • 바이트 적중률: 캐시를 통해 제공된 모든 바이트의 비율

    • 100%라는 의미는 모든 바이트가 캐시에서 왔으며, 어떤 트래픽도 인터넷으로 나가지 않았음을 의미

    • 이를 개선하면 대역폭 절약을 최적화함

  • 적중/부적중 구별

    • Via 헤더를 넣어주는 proxy cache가 있음

    • Date 헤더를 현재 시간과 비교하여 응답의 생성일이 더 오래되었다면 캐시된 것임을 암

    • Age 헤더를 통해 확인 가능

캐시 토폴리지

topology: 일반적인 의미는 물리적인 배치의 형태로 이루어진 어떤 현장이나 종류. 수학에서는 위상이라고 함

  • 개인 전용 캐시(private cache): 개인만의 위한 캐시

    • 웹브라우저는 개인 전용 캐시를 내장하고 있음

  • 공용 캐시(public cache): 공유된 캐시. 사용자 집단에게 자주 쓰이는 페이지를 담음

캐시 처리 단계

  1. 요청 받기

  2. 파싱

  3. 검색

  4. 신선도 검사

  5. 응답

    • 캐시가 Date 헤더를 조정해서는 안됨. 이는 그 객체가 원 서버에서 최초로 생겨난 일시를 표현하는 것

  6. 발송

  7. 로깅

최신 캐시 데이터 유지(사본을 신선하게 유지하기)

  • Cache-Control, Expires 헤더를 통해 원서버가 각 문서에 유효기간 설정 가능

  • Cache-Control: max-age=<sec>: 문서의 최대 나이를 설정함(초 단위서 설정)

  • Expires: 절대 유효기간을 명시

  • HTTP 조건부 메서드는 재검사를 효율적으로 만들어줌

    • 조건부 GET은 GET 요청 메세지에 특별한 조건부 헤더를 추가함으로써 시작. 웹 서버는 조건이 참인 경우에만 객체를 반환.

    • 모든 조건부 헤더는 If- 접두어로 시작

    • If-Modified-Since: 만약 문서가 주어진 날짜 이후로 수정되었다면 요청 메서드 처리. 이는 캐시된 버전으로부터 콘텐트가 변경된 경우에만 가져오므로 Last-Modified 서버 응답 헤더와 함께 사용

      • 이 재검사 요청을 'IMS' 요청이라고도 함

    • If-None-Match: 날짜 대신 문서에 대한 일련번호와 같이 동작하는 특변한 태그 제공 가능. 이 태그가 서버에 있는 태그와 다를때만 요청을 처리

캐시 제어

  • Cache-Control: no-store: 응답에 해당 값이 있을 경우 캐시가 그 응답의 사본을 만드는 것음 금지함

  • Cache-Control: no-cache: 응답에 해당 값이 있을 경우 캐시된 사본을 사용자에게 보여주기 이전에 서버에 재검사를 하도록 강제함

  • Pragma: no-cache: HTTP/1.0+와의 하위호환성을 위해 HTTP/1.1에 포함됨. HTTP/1.0 어플리케이션에 대응해야하는 경우가 아니라면 `Cache-Control: no-cache`를 사용해야 함

  • Cache-Control: max-age=<sec>: 리소스가 최신 상태라고 판단할 최대 시간을 정함

  • Cache-Control: s-maxage=<sec>: 공유 캐시에만 적용

  • Expires: <http-date>: 더 이상 신선하지 않다고 판단할 날짜/시간 지정

  • Cache-Control: must-revalidate: 캐시 사용하기 이전에 리소스 상태를 반드시 확인해야함. 만료된 리소스라면 `504 Gateway Timeout error`를 반환.

  • 응답이 Cache-Control: max-age or Expires 헤더 중 어느 것도 포함하지 않는다면 캐시는 경험적인 방법으로(heuristic) 최대 나이를 계산할 것임.

    • 계산 결과 얻은 최대 나이 값이 24시간보다 크면 Heuristic Expiration 경고 헤더가 응답 헤더에 추가되어야 함.

    • 그러나 대게 이 경고 정보를 사용자에게 볼 수 있게 해주는 브라우저는 거의 없음

  • 많은 원 서버들이 아직도 Expires와 max-age 헤더를 생성하지 못함. 캐시의 만료 기본값을 신중하게 선택하라.

  • 클라이언트에서 헤더를 추가하여 강제로 캐시 재검사하거나 서버로부터 가져오게끔 하는 리프레시 버튼이 있음

캐시 제어 설정

  • 각 웹서버의 모듈 참고

  • <META HTTP-EQUIV> 태그를 이용한 HTML 캐시 제어

etc