7. 캐시

• 불필요한 데이터 전송을 줄여, 네트워크 요금으로 인한 비용을 줄여줌.

• 네트워크 병목을 줄임.

• 원 서버에 대한 요청을 줄임.

• 거리로 인한 지연을 줄임.

불필요한 데이터 전송

• 첫 번째 서버 응답은 캐시에 보관됨.

• 캐시된 사본이 뒤이은 요청들에 대한 응답으로 사용되어, 원 서버가 중복해서 트래픽을 주고받는 낭비가 줄어듦.

대역폭 병목

• 클라가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 캐싱은 성능을 대폭 개선함.

• 이더넷 LAN이라면 5MB 크기의 파일을 전송하는데 1초도 걸리지 않지만, 56-kbps 모뎀이라면 749초(12분 이상)가 걸림. 특히 큰 문서들에 대해 캐싱이 큰 역할을 함.

갑작스런 요청 쇄도(Flash Crowds)

• 갑작스런 뉴스 속보, 유명 인사와 관련된 사건 등으로 인해 많은 사람들이 거의 동시에 웹 문서에 접근할 때 발생.

• CNN의 경우 평균 매초 50,000건이 넘는 요청을 받는다고 보고함.

거리로 인한 지연

• 어떤 웹페이지가 20개의 작은 이미지를 포함한다면, 한 서버에 들어있을 때, 동시에 4개의 커넥션을 열고, 그 커넥션을 유지한다면 아무리 빛의 속도라할지라도 보통 수준으로 복잡한 웹페이지들은 지연이 수 초에 달할 수도 있음.

• 심지어 신호는 빛보다 약간 느리게 이동하므로, 거리로 인한 지연은 이보다 클 수 있음.

적중과 부적중

• 캐시는 유용하지만 세상 모든 문서의 사본을 저장하진 않음.
• 웹의 모든 문서를 보관할만큼 충분한 캐시를 사는 것은 매우 비쌈.
• 사더라도 몇몇 문서는 매우 자주 변경되므로 항상 신선한 상태를 유지하지 못함.

• 캐시에 요청이 왔을 떄, 그에 대응하는 사본이 있어 처리하는 것을 캐시 적중(cache hit)라고 부름.

• 대응하는 사본이 없어 원 서버로 전달하는 것을 캐시 부적중(cache miss)라고 부름.

재검사

• 원 서버 콘텐츠는 변경될 수 있기 때문에, 캐시는 자신의 사본이 최신인지 서버를 통해 때때로 점검해야 함.

• 캐시 스스로 재검사를 할 수 있지만 보통 클라가 요청할 때, 그 사본이 충분히 오래된 경우에만 검사함.

• 효과적인 재검사를 위해 HTTP는 서버로부터 전체 객체를 가져오지 않고 If-Modified-Since 헤더를 보냄. 서버에게 보내는 GET 요청에 이 헤더를 추가하면 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미임.

• 이 요청이 서버에 도착했을 때 일어날 수 있는 일은 3가지임.
• 재검사 적중



• 콘텐츠(서버 객체)가 변경되지 않았다면 304 Not Modified 응답을 보냄.
• 원 서버와 검사를 하기 때문에 순수 캐시 적중보다 느림.
• 하지만 서버로부터 객체 데이터를 받아오지 않기 때문에 아래 캐시 부적중보단 빠름.
• 재검사 부적중
• 서버 객체가 캐시된 사본과 다르다는 뜻으로, 서버는 콘텐츠 전체와 함께 평범한 HTTP 200 OK 응답을 클라에게 보냄.
• 객체 삭제
• 만약 서버 객체가 삭제되었다면, 서버는 404 응답을 돌려보내며, 캐시는 사본을 삭제함.

적중률

• 캐시가 요청을 처리하는 비율을 캐시 적중률(혹은 캐시 적중비), 혹은 문서 적중률 (혹은 문서 적중비)이라 부름.

• 적중률은 0에서 1까지의 값으로 되어 있지만, 흔히 퍼센트로 표현됨.

• 0%는 모든 요청이 캐시 부적중(네트워크 너머로 문서를 가져와야 했던 경우)임을, 100%는 모든 요청이 캐시 적중(캐시 에서 사본을 가져온 경우)임을 의미함.

• 적중률은 실제 적중률은 캐시가 얼마나 큰지, 캐시 사용자들의 관심사가 얼마나 비슷한지, 캐시된 데이터가 얼마나 자주 변경되거나 개인화되는지, 캐시가 어떻게 설정되어 있는지에 달림.

• 2002년 기준 캐시 적중률 40%.

• 보통 크기의 캐시라도 충분한 분량의 자주 쓰이는 문서들을 보관하여 상당히 트래픽을 줄이고 성능을 개선함.

바이트 적중률

• 얼마나 많은 바이트가 인터넷으로 나가지 않았는지를 보여줌.

• 몇몇 큰 객체는 덜 접근하지만 크기 때문에 전체 트래픽에 더 크게 기여하는 경우 바이트 단위 적중률 측정값을 사용함.

• 바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현함.

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

적중과 부적중의 구별

• 불행히도, HTTP는 클라이언트에게 응답이 캐시 적중이었는지 아니면 원 서버 접근인지 말해줄 수 있는 방법을 제공하지 않음.

• 두 경우 모두 응답 코드는 응답이 본문을 갖고 있음을 의미하는 200 OK가 됨.

• 클라이언트가 응답이 캐시에서 왔는지 알아내는 한 가지 방법은 Date 헤더를 이용헤 응답의 Date 헤더 값을 현재 시각과 비교하여, 응답의 생성일이 더 오래되었다면 클라이언트는 응답이 캐시된 것임을 알아냄.

• 또는 수신자에게 응답이 얼마나 오래되었는지를 말하는 Age 헤더를 이용함.

캐시 토폴로지(연결 방식)

• 캐시는 한 명의 사용자에게만 할당될 수도 있고 반대로 수천 명의 사용자들 간에 공유될 수 있음.

• 개인 전용 캐시
• 개인만을 위한 캐시.
• 많은 에너지나 저장 공간을 필요로 하지 않으므로, 작고 저렴할 수 있음.
• 대부분의 브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정을 수정할 수 있도록 허용함.
• 캐시에 어떤 것들이 들어있는지 브라우저를 통해 볼 수 있음.
• 예를 들어, 구글 크롬의 경우, 특별한 URL인 about:cache를 통해 연결되는 페이지에서 캐시 콘텐츠의 목록을 볼 수 있음.

• 공용 프락시 캐시
• 공용 캐시는 프락시 캐시라고 불리는 특별한 종류의 공유된 프락시 서버임.
• 프락시 캐시는 로컬 캐시에서 문서를 제공하거나, 혹은 사용자의 입장에서 서버에 접근함.
• 공용 캐시에는 여러 사용자가 접근하기 때문에, 불필요한 트래픽을 줄일 수 있는 더 많은 기회가 있음.
• 그림 7-8b과 같이, 캐시는 자주 찾는 객체를 단 한 번만 가져와 모든 요청에 대해 공유된 사본을 제공함으로써 네트워크 트래픽을 줄임.

• 프락시 캐시 계층들



• 작은 캐시에서 캐시 부적중이 발생했을 때 더 큰 부모 캐시가 그 ‘걸러 남겨진’ 트래픽을 처리하도록 하는 계층을 만드는 방식이 합리적인 경우가 많음.
• 클라이언트 주위에는 작고 저렴한 캐시를 사용하고, 계증 상단에는 많은 사용자들에 의해 공유되는 문서를 유지하기 위해 더 크고 강력한 캐시를 사용하자는 것임.

• 캐시망, 콘텐츠 라우팅, 피어링
• 몇몇 네트워크 아키텍처는 단순한 캐시 계층 대신 복잡한 캐시망을 만듦.
• 캐시망의 프락시 캐시는 복잡한 방법으로 서로 대화하여, 어떤 부모 캐시와 대화할 것인지, 아니면 요청이 캐시를 완전히 우회해서 원 서버로 바로 가도록 할 것인지에 대한 캐시 커뮤니케이션 결정을 동적으로 내림.
• 캐시망 안에서의 콘텐츠 라우팅을 위해 설계된 캐시들은 다음에 나열된 일들을 할 수 있음.
• URL에 근거하여, 부모 캐시와 원 서버 중 하나를 동적으로 선택.
• URL에 근거하여 특정 부모 캐시를 동적으로 선택.
• 부모 캐시에게 가기 전에, 캐시된 사본을 로컬에서 찾음.
• 다른 캐시들이 그들의 캐시된 콘텐츠에 부분적으로 접근할 수 있도록 허용하되,그들의 캐시를 통한 Internet transit(트래픽이 다른 네트워크로 건너가는 것)은 허용하지 않음.
• 이러한 한층 더 복잡한 캐시 사이의 관계는, 서로 다른 조직들이 상호 이득을 위해 그들의 캐시를 연결하여 서로를 찾아볼 수 있도록 해줌.
• 선택적인 피어링을 지원 하는 캐시는 형제 캐시라고 불림(그림 7-10).
• HTTP는 형제 캐시를 지원하지 않 기 때문에, 사람들은 인터넷 캐시 프로토콜(ICP)이나 하이퍼텍스트 캐시 프로토콜 (HTCP)같은 프로토콜을 이용해 HTTP를 확장함.

캐시 처리 단계

• 오늘날 사용 프락시 캐시는 복잡하지만 기본적인 동작은 다음과 같음.

1. 요청 받기
1. 캐시는 네트워크로부터 도착한 요청 메시지를 읽음.

2. 파싱
1. 캐시는 메시지를 파싱하여 URL과 헤더들을 추출하여 조작하기 쉬운 자료구조에 담음.

3. 검색
1. 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아와 로컬에 저장함.
2. 만약 문서를 로콜에서 가져올 수 없다면, 캐시는 설정에 따라 원 서버나 부모 프락시에서 가져오거나 실패를 반환함.
3. 이때 응답 헤더와 본문에 서버 응답 본문과 원 서버 응답 헤더, 캐싱 기간, 사용 빈도 등에 대한 메타데이터를 포함함.

4. 신선도 검사
1. 캐시는 캐시된 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지 서버에게 물어봄.
2. 신선도 검사 규칙은 복잡하기에 이 장 나머지를 신선도 계산에 대해 설명함.

5. 응답 생성
1. 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만듦(원 서버에서 온 것처럼 하고 싶기 때문).
2. 캐시는 클라이언트에 맞게 이 헤더를 조정해야 하는 책임이 있음.
3. 예를 들어, 클라이언트가 HTTP/1.1 응답을 기대하는 상황에서 서버가 HTTP/1.0 응답(혹은 HTTP/0.9 응답)을 반환했다면, 캐시는 반드시 헤더를 적절하게 번역해야 함. 또한 캐시 신선도 정보를 삽입하며(Cache-Control, Age, Expires 헤더), 요청이 프락시 캐시를 거쳐갔음을 알려주기 위해 종종 via 헤더를 포함시킴.
4. 캐시가 Date 헤더를 조정해서는 안 됨. Date 헤더는 그 객체가 원 서버에서 최초로 생겨난 일시를 표현한 것임.

6. 전송
1. 응답 헤더가 준비되면, 네트워크(커넥션 유지)를 통해 응답을 클라이언트에게 돌려줌.

7. 로깅
1. 선택적으로, 캐시는 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남김.
2. 로그파일에는 통계 캐시 적중과 부적중 횟수(그리고 다른 관련 지표들), 로그 파일에 요청 종류, URL, 무엇이 일어났는지를 알려주는 항목이 있음.
3. 가장 많이 쓰이는 캐시 로그 포맷은 Squid log format과 Netscape extended common log format이지만, 많은 캐시 제품이 커스텀 로그 파일을 허용함.

사본을 신선하게 유지하기

• HTTP는 어떤 캐시가 사본을 갖고 있는지 서버가 기억하지 않더라도, 캐시된 사본이 서버와 충분히 일치하도록 유지할 수 있게 해주는 단순한 메커니즘을 갖고 있음.

• 이 단순한 매커니즘을 문서 만료와 서버 재검사라고 부름.

문서 만료

• HTTP는 Cache-Control과 Expires라는 헤더들을 이용해서 원 서버가 각 문 서에 유효기간을 붙일 수 있게 함.

• 캐시 문서가 만료되지 않았다면 서버와의 접촉 없이 사본을 제공할 수 있음(리소스의 제공을 거부하는 헤더가 없을 경우만).

• 캐시된 문서가 만료되면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 하며, 변경되었을 경우 새 유효기간과 함께 최신의 사본을 얻어 와야 한다.

• 서버는 HTTP/1.0+ Expires나 HTTP/1.1 Cache-Control: max-age 응답 헤더를 이용해서 유효기간을 명시함.

• max age의 숫자는 484,200초가 남은 것을 의미함.

서버 재검사

• 캐시된 문서가 만료되었다 해서 반드시 원 서버의 문서와 다르다는 걸 의미하지 않음. 이제 검사할 시간이 되었다는 뜻임.

• 캐시가 원 서버에게 문서가 변경되었는지의 여부를 물어볼 필요가 있음을 의미하는 서버 재검사라고 함.
• 재검사 결과 콘텐츠가 변경되었다면, 캐시는 그 문서의 새로운 사본을 가져와 오래된 데이터 대신 저장한 뒤 클라이언트에게도 보내줌.
• 재검사 결과 콘텐츠가 변경되지 않았다면, 캐시는 새 만료일을 포함한 새 헤더들만 가져와서 캐시 안의 헤더들을 갱신함.

• 이렇게 해서 HTTP 프로토콜은 캐시로부터 최신의 사본 혹은 재검사를 실패했을 경우 적절한 에러 메세지를 요구함.

조건부 메서드와의 재검사

• HTTP의 조건부 메서드는 재검사를 효율적으로 만듦.

• HTTP는 캐시가 서버에게 조건부 GET이라는 조건부 헤더를 추가한 요청을 보낼 수 있게 함.

• 조건부 요청 헤더 다섯 가지 중 가장 유용한 두 가지는 다음과 같음.

• If-Modified-Since: 날짜 재검사
• ‘IMS’ 요청이라 불림.
• 날짜가 지나지 않았다면 서버는 304 Not Modified를 돌려줌. 보통 효율을 위해 본문 없이 새 만료 날짜를 보내줌.
• 이때 이 날짜 이후로 변경되었다면이 아닌이 날짜에 마지막 변경이 일어난 것이 아니라면으로 해석해야 함.

• If-None-Match: 엔터티 태그 재검사
• 다음과 같이 IMS 요청이 적절하지 않은 상황이 있음.
• 일정 시간 간격으로 다시 쓰여지지만(ex 백그라운드 프로세스) 실제로는 같은 데이터를 포함하고 있을 때.
• 철자나 주석의 변경 등 캐시들이 그 데이터를 다시 읽어들이기엔 사소할 때.
• 페이지의 최근 변경 일시를 정확하게 판별 할수 없을 때.
• 1초보다 작은 간격으로 갱신될 때 (1초의 정밀도는 필요하지 않을 때).



• 추가로 여러 개의 사본을 갖고 있는 경우, 여러 개의 엔터디 태그를 포함시킬 수 있음. ex) If-None-Match: "v2.4", "v2.5"

• 만약 이 둘을 모두 받았다면, 두 가지의 재검사 정책을 모두 활용해 엄격히 검사함.

약한 검사기와 강한 검사기

• 서버는 때때로 모든 캐시된 사본을 무효화하지 않고 문서를 일부만 수정하고 싶은 경우가 있음.

• 약한 검사기는 유의미한 변경이 있을 때마다 변경되지만, 강한 검사기는 콘텐츠가 바뀔 때마다 바뀜.

• W/접두사로 약한 검사기를 구분함. ex) If-None-Match: W/"2.6"

• 캐시 항목은 긴 기간 동안 지속될 수 있기 때문에 재활용하면 안됨.

캐시 제어

• HTTP는 얼마나 캐시가 지속될 수 있게 할 것인지 서버가 설정할 수 있는 여러 가지 방법을 정의함.

• no-cache와 no-store 응답 헤더

Cache-Control: no-store
Cache-Control: no-cache
Pragma: no-cache

• ‘no-store’가 표시된 응답은 캐시가 그 응답의 사본을 만드는 것을 금지함. 이 경우 캐시는 클라에게 no-store 응답을 전달하면 객체를 삭제함.
• ‘no-cache’로 표시된 응답은 사실 로컬 저장소에 저장될 수 있음. 다만 클라로 제공할 수 없을 뿐임.
• pragma는 http 버전 하위호환성을 위해 사용됨. 하지만 pragram만 이해할 수 있는 http/1.0 대응이 아니라면 cache-control을 사용해야 함.

• Max-Age 응답 헤더

Cache-Control: max-age=3600
Cache-Control: s-maxage=3600

• 문서를 최신 상태로 만든 후의 흐른 시간을 의미하고, 초로 나타냄.
• s-maxage 헤더는 max-age처럼 행동하지만 공유된(공용) 캐시에만 적용됨.
• 0이면 최신 상태라는 의미로, 캐시가 접근마다 문서를 캐시하지 하지 않음.

• Expires 응답 헤더

Expires: Fri, 05 Jul 2002, 05:00:00 GMT

• 초 단위의 시간 대신 실제 만료 날짜를 명시함.
• 하지만 시계 표현애 대해 공통된 합의가 없기 때문에 더 이상 사용하지 않는 경우가 많음.
• Expires: 0같은 응답 헤어들 사용하지도 않음(문서 위반).

• Must-Revalidate 응답 헤더

Cache-Control: must-revalidate

• 최신이 아닌 사본을 원 서버와 재검사없이 제공해선 안 됨을 의미함. 만약 서버와 재검사를 할 수 없는 상태라면 504 Gateway Timeout Error를 반환해야 함.
• 케시가 만료 정보를 엄격하게 따르길 원할 때 사용.

• 휴리스틱 만료
• 앞선 헤더 없이 캐시가 경험적인 방법으로(heuristic) 최대 나이를 계산함.
• 보통 기본 신선도 유지기간을 하루(엄격) ~ 일주일(평균)로 설정함.
• 다양한 알고리즘이 사용되지만 LM 인지 알고리즘이 유명함.
• 만약 캐시된 문서가 마지막으로 변경된지가 오래됐다면, 이 문서는 정적일 것이고 갑자기 바뀔 가능성이 크지 않다 판단해 캐시에 더 오래 보관해도 안전하다고 판단.
• 만약 캐시된 문서가 최근에 변경되었다면, 또 변경될 것이라 판단해 서버와 재검사하기 전까지 짧은 기간 동안만 캐시하려 함.

• 클라이언트 신선도 제약
• 클라는 성능, 신뢰성, 비용 개선을 위해 신선도 요구하사항을 느슨하게 할 수 있음.

캐시 제어 설정

• 웹 서버들은 만료 HTTP 헤더들을 설정하는 다양한 매커니즘을 제공함.

• 아파치로 HTTP 헤더 제어하기
• mod_headers : 개별 헤더들을 설정함.

<File *.html>
  Header set Cache-control no-cache
</Files>

• mod_expires : 적절한 만료 날짜가 담긴 Expires 헤더를 자동으로 생성하는 프로그램 로직 제공. 문서에 접근, 수정한 시한을 기준으로 유효기간을 설정할 수 있게 해줌.

ExpiresDefault A3600
ExpiresDefault M86400
ExpiresDefault "access plus 1 week"
ExpiresByType text/html "modification plus 2 days 6 hours 12 minutes"

• mod_cern_meta : 이 모듈을 켜면 제어하고자 하는 파일에 각각 대응되는 메타파일을 생성하여 HTTP 헤더들의 파일을 특정 개체와 연결시켜줌.

• HTTP-EQUIV를 통한 HTML 캐시 제어
• HTML 2.0에서 <META HTTP-EQUIV> 태그를 정의하여 웹 서버 설정 파일과 상호작용 없이도 쉽게 HTML 문서에 HTTP 헤더 정보를 부여할 수 있게 함.

<html>
  <head>
      <title>My Document</title>
      <META HTTP-EQUIV="Cache-control" CONTENT="no-cache">
  </head>
...

• 하지만 서버 부하 가중, 정적인 설정값, HTML 외의 타입을 지원하지 않는 등 한계가 많아 웹 서버나 프록시에서 해당 기능을 지원하지 않음.

자세한 알고리즘

• 나이와 신선도 수명
• 캐시된 사본의 나이가 신선도 수명보다 작으면 사본은 제공하기에 충분히 신선함.
• 펄로 작성한다면$충분히_신선한가 = ($나이 < $신선도_수명);
• 문서의 나이는 서버가 보낸(서버가 마지막으로 재검사한) 후 그 문서가 흐른 시간의 총합임.
• 신선도 수명은 아직 문서가 신선하다고 볼 수 있는 수명임. 문서의 나이가 신선도 수명을 넘었다면, 클라에게 제공하기엔 충분하지 않는 것임.

• 나이 계산
• 캐시가 도착한 시간 + 머무른 시간
• http는 clock skew(두 컴퓨터의 시계 설정 차이로 인한 문제)와 네트워크 지연을 보상하기 위해 추가적인 로직이 들어가지만, 기본 계산은 위와 같음. 이를 겉보기 나이라 함.
• 불행히 Date로 계산을 하려 해도 모든 시계가 동기화되어 있지 않음. 그래서 가끔 계산이 음수가 되는 경우도 있는데, 이런 경우 겉보기 나이를 0으로 설정함.
• 하지만 0으로 계산했을 때 전반적으로 정확도 손실이 일어남. 따라서 문서가 프락시나 캐시를 통과할 때마다 그 장치들이 Age 헤더에 상대적인 나이를 누적해서 더함. Age 헤더 값은 문서가 프락시들을 통과하면서 점점 늘어나는 것임.
• 이 값은 Date 기반 나이와 별개로 계산되어, 두 나이 추정값 중 가장 큰 것을 선택함. 실제보다 작게 계산된 값일 확률이 높기 때문.
• 캐시의 중요한 동기인 느린 트랜잭션으로 인해 문서가 긴 시간동안 갇혀있었던 경우 오차가 커질 수 있음. 이런 경우 전체 왕복 시간을 계산해 더함으로써 네트워크 지연을 보수적으로 교정함.

• 신선도 수명 계산

//서버 신선도 제약 계산
sub 서버_신선도_한계 {
  local($휴리스틱, $서버_신선도_한계, $마지막으로_변경된_시각)

  $휴리스틱 = 0;
  if ($Max_Age_값이_설정되었나) { $서버_신선도_한계 = $Max_Age_값 }
  elsif ($Expires_값이설정되었나) { $서버_신선도_한계 = $Expires_값 - $Date_값 }
  elsif ($Last_Modified_값이_설정되었나) {
    $마지막으로_변경된_시각 = max(0, $Date_값 - $Last_Modified_값)
    $서버_신선도_한계 = int($마지막으로_변경된_시각 * $lm_인자);
    $휴리스틱 = 1;
  } else {
    $서버_신선도_한계 = $캐시_최소_수명_기본값;
    $휴리스틱 = 1;
  }

  if ($휴리스틱) {
    if ($서버_신선도_한계 > $캐시_최대_수명_기본값) $서버_신선도_한계 = $캐시_최대_수명_기본값
    if ($서버_신선도_한계 < $캐시_최소_수명_기본값) $서버_신선도_한계 = $캐시_최소_수명_기본값
  }
  return $서버_신선도_한계
}

// 클라 신선도 대조 계산
sub 클라이언트가_수정한_신선도_한계 {
  $나이_한계 = 서버_신선도_한계()

  if ($Max_Stale_값이_설정되었나) {
    if ($Max_Stale_값 == $INT_MAX) { $나이_한계 = $INT_MAX }
    else { $나이_한계 = 서버_신선도_한계() + $Max_Stale_값 }
  }
  if ($Min_Fresh_값이_설정되었나) {
    $나이_한계 = min($나이_한계, 서버_신선도_한계() - $Min_Fresh_값)
  }
  if ($Max_Age_값이_설정되었나) { $나이_한계 = min($나이_한계, $Max_Age_값) }
}

• 전체 과정을 설명하자면 문서의 나이와 신선도 한계라는 두 가지 변수로 신선도를 측정함. 이후 클라 신선도 대조 계산을 통해 추가적인 클라의 제약사항에 근거하여 신선도를 조절함.
 

캐시와 광고

• 캐시는 사용자를 도와 더 좋은 경험을 제공하고, 네트워크 사업자들이 트래픽을 줄일 수 있도록 지원하지만 아래와 같은 문제가 있을 수 있음.
• 광고 콘텐츠 제공과 관련하여 캐시로 인해 원 서버가 HTTP 접근을 수신하지 않게 되어 만약 접근 횟수로 돈을 번다면 문제가 있을 수 있음. 캐시는 원 서버가 실제 접근 횟수를 알 수 없게 숨길 수 있기 때문.
• 이를 캐시가 가로채지 못하도록 ‘캐시 무력화'기법을 사용하는데 이러한 광고 시청 수를 관리하려는 시도는 캐싱의 긍정적인 효과를 감소시킴.
• 대안으로 원 서버와 재검사하도록 캐시를 설정하는 것이 있지만 이는 트랜잭션을 느리게 만듦.

• 이상적인 해결책 중 하나는 서버로 요청이 가지 않도록 하는 것임. 캐시에서 로그를 갖고 있는 것인데(적중) 이는 크기 때문에 다루기가 어렵고, 표준화도 되어있지 않음. 뿐만 아니라 인증과 프라이버시 이슈도 있음. 이에 따라 광고 수익을 교정해주는 지원 인프라를 개발하는 사업도 생김.

• 또 한가지 방법으로 캐시 적중 횟수를 정기적으로 서버에게 돌려주는 Meter라는 새 헤더를 추가하여 서버가 캐시된 문서의 적중 횟수를 정기적으로 캐시로 부터 받을 수 있음(RFC 2227, Simple Hit-Metering and Usage-Limiting for HTTP). 추가적으로 서버는 캐시가 서버에게 보고해야 하기 전까지 문서를 제공할 수 있는 횟수나 처리시간을 제어할 수 있음(사용량 제한) . 이를 통해 캐시된 리소스의 사용량을 서버가 제한할 수 있게 됨.