HTTP - 8. Cache

Cache

캐시는 네트워크 자원 낭비, 대역폭, 로드 밸런스, 거리에 따른 지연 등 웹 컨텐츠를 보다 효율적으로 운영하기 위해 사용되는 장치이다. HTTP 요청 메시지를 받아 메시지를 파싱하고 로컬 사본이 있는지 검색한다. 사본을 찾았을 경우에는 캐시된 메시지의 헤더 값을 참조하여 조건에 맞는 캐시 리소스인지 확인하고, 클라이언트에 응답한다. 마지막으로 로그 파일과 캐시 사용에 대한 통계를 갱신한다. 캐시에는 모든 사본이 존재하는 것은 아니기 때문에, cache hit, cache miss로 나뉜다.

원본 서버 콘텐츠가 변경될 수 있기 때문에, GET If-Modified-Since 헤더 등을 사용하여 오리진 서버에 재검사를 수행한다.

l  Revalidation hit: 서버로부터 304 Not Modified를 응답 받아 최신임을 확인

l  Revalidation miss: 서버로부터 콘텐츠와 200 OK 응답을 받은 경우로, 사본이 최신이 아님을 확인

l  Entity delete: 리소스가 삭제되었다면, 404 Not Found 응답을 받고, 캐시는 사본을 삭제한다.

또한 캐시 효율을 가늠하는 기준으로 캐시 적중률과 바이트 적중률을 사용할 수 있다. 각 %로 표시되며 100에 가까울수록 캐시 효율이 좋다고 본다. 특히 바이트 단위는 좀더 디테일한 적중률을 알 수 있다. 클라이언트에서 응답 메시지가 캐시 된 것인지 아닌지 판별하는 방법은, 응답 메시지의 Age 헤더나 Date 헤더를 확인하는 방법이 있다.

RFC 2227에서 HTTP를 위한 간단한 cache-hit 측정과 사용량 제한을 정의한다. HTTP에 특정 URL에 대한 cache-hit 횟수를 정기적으로 서버에 돌려주는 Meter 헤더를 추가한다. 또한, 서버에 보고 전까지 캐시에 리소스 제공 횟수나, 처리시간을 제어할 수 있다.

-       Private cache
개인 전용 캐시로 그리 큰 공간을 필요로 하지 않기 때문에 브라우저에 내장되어 있다. 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정을 수정 가능하게 허용한다.

-       Public cache (Proxy cache)
공유된 프록시 서버로, 로컬 캐시에서 문서를 제공하거나, 사용자 입장에서 서버에 접근한다. 모든 요청 중에 중복된 요청이 있다면 그만큼 트래픽을 줄일 수 있다.

-       프록시 캐시 계층 구성: 클라이언트들 주변에는 작은 레벨 1 캐시를 위치시키고, 상위 네트워크 위쪽에 레벨 2 캐시를 위치시키는 방식이다. 단, 캐시 계층이 깊어지면 프록시 연쇄가 길어지고, 각 중간 프록시는 성능 저하가 발생하게 된다. 고성능 프록시 서버들의 경우 이에 해당하지 않는다.

-       캐시 네트워크, 컨텐츠 라우팅, 피어링
URL 등 기준을 잡고 특정 캐시 또는 원본 서버를 선택하도록 유도하거나 우회하는 방법을 사용하거나, HTTP 확장을 통해 ICP, HTCP 등의 프로토콜을 이용해 피어링 구성을 하는 방법도 있다.

캐시 컨트롤 헤더

Cache-Control:	설명
max-stale [= <s>]	캐시는 최근 문서가 아니어도 자유롭게 제공. 매개변수 지정 시, 해당 시간이 지난 리소스도 받음.
min-fresh = <s>	클라이언트는 지금으로부터 s초 후까지 최신 문서만 받음
max-age = <s>	s초보다 오랫동안 캐시 문서 반환 못함.
no-cache	재검사 없이 캐시된 리소스 받지 않음
no-store	캐시된 리소스 삭제
only-if-cached	클라이언트는 캐시만을 받음

 

캐시 컨트롤 우선순위

1.     Cache-Control: no-store: 어떤 것도 캐싱 하지 않음. 이전 캐시 존재 시 삭제

2.     Cache-Control: no-cache: 사본을 클라이언트로 전달하지 않지만 캐시가 존재할 수 있음
2-1. Pragma: no-cache: HTTP/1.0+ 하위호환성을 위해 HTTP/1.1에 포함.

3.     Cache-Control: must-revalidate: 캐시 사용 이전에 재검사, 만료 리소스 사용 금지

4.     Cache-Control: max-age: 리소스가 최신이라고 판단할 최대 시간

5.     Expire: Deprecated. 실제 만료 시간 명시.

6.     캐시 스스로 휴리스틱(체험적인) 방법으로 결정: max age를 계산하는 방식을 캐시 스스로 결정하며, 계산된 시간이 24시간을 초과할 경우, Heuristic Expiration 경고 헤더를 응답 헤더에 추가한다.
6-1. LM 인자 알고리즘: 리소스의 최근 변경 일시를 알 때 사용 가능하며, 얼마나 자주 바뀌는지에 대한 추정에 사용한다.
  - 캐시의 마지막 변경이 오래 전이라면, 안정적인 리소스로 판단하고 앞으로 바뀔 가능성도 낮으니, 더 오래 보관해도 안전하다
  - 최근에 변경된 캐시는 자주 변경될 확률이 높기 때문에, 재검사 전 짧은 기간만 캐시한다.
  - 최근 변경 일시가 없는 리소스는 디폴트 값으로 유지 시간을 설정(ex. 한 시간, 하루 등)

기본적으로 응답 메시지는 만들어진 시간부터 지금까지의 시간을 헤더에 포함한다. Date 또는 Age 헤더를 기반으로 하며, 나이 계산은 응답 메시지가 캐시에 도착한 나이에 캐시에 머무른 시간을 더해주면 된다.

l  Clock Skew: 시간 동기화 문제로, 프록시, 클라이언트, 서버가 각기 시간 동기화가 제대로 이루어져 있지 않은 경우 발생하며, age가 부정확하거나 음수로 계산되기도 한다.

HTTP/1.1은 캐시나 프록시 통과시, Age 헤더에 상대적인 나이를 누적해서 더하는 방법을 사용한다. 추가된 헤더를 인식하지 못하는 장치를 거칠 경우 해당 헤더가 삭제되거나 수정되지 않을 수도 있다. 이 상대 나이는 Date 기반 나이와 별도로 계산되어, 더 큰 값을 선택한다. 또, 요청 시간, 응답을 받은 시간을 계산하여 네트워크 지연을 보수적으로 교정한다.