7장 캐시

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

• 캐시는 불필요한 데이터 전송을 줄여서, 네트워크요금으로 인한 비용을 줄여 준다.
• 캐시는 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 된다.
• 캐시는 원서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다.
• 페이지 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다.

불필요한 데이터 전송

원 서버 페이지에 접근할 때, 서버는 같은 문서를 여러 클라이언트에게 전송한다.
똑같은 바이트들이 네트워크를 통해 계속 반복해서 이동한다.
캐시는 이런 불필요한 데이터 전송을 줄여준다.
캐시를 이용하면, 첫 번째, 서버 응답은 캐시에 보관되며 뒤 이은 응답은 캐시된 사본으로 사용하기 때문에 서버로부터 데이터를 다시 전송받을 필요가 없다.

대역폭 병목

캐시는 네트워크 병목을 줄여준다.
많은 네트워크가 원격 서버보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공한다.

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

캐싱은 갑작스런 요청 쇄도에 대응하기 위해 중요하다. 갑작스런 사건으로 많은 사람이 거의 동시에 웹 문서에 접근할 때 발생한다.
이 결과로 불필요한 트래픽 급증은 네트워크와 웹 서버의 심각한 장애를 야기시킨다.

거리로 인한 지연

대역폭이 문제가 되지 않더라도, 거리가 문제가 될 수 있다.
모든 네트워크 라우터는 제각각 인터넥 트래픽을 지연 시킨다. 또한 클라이언트와 서버 사이의 라우터가 많지 않더라도, 빛의 속도 그 자체가 유의마한 지연을 유발한다.

적중과 부적중

캐시에 요청이 도착했을 때, 만약 그에 대응하는 사본이 있다면 그를 이용해 요청이 처리된다. 이를 캐시 적중(cache hit)이라고 한다.
만약 캐시에 요청에 대응하는 사본이 없다면, 원 서버에 요청을 전달하기만 한다. 이를 캐시 부적중(cache miss)이라고 한다.

재검사(Revalidation)

원 서버의 콘텐츠는 변경될 수 있기 때문에 캐시는 사본이 신선한지 확인해야 한다.
이러한 신선도검사를 HTTP 재검사라고 한다.
캐시는 캐시된 사본의 재겁사가 필요할 때, 원 서버에 작은 재거사 요청을 보낸다. 콘텐츠가 변경 되지 않았으면 서버는 아주 작은 304 Not Modified 응답을 보낸다.
사본이 여전히 유효함을 알게 된 캐시는 즉각 사본이 신선하다고 임시로 표시한 후 그 사본을 클라이언트에 제공한다. 이를 재검사 적중 혹은 느린 적중이라고 부른다.

If-Modified-Since 헤더를 사용하여 GET 요청을 하게 되면 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미가 된다.

다음은 GET If-Modified-Since 요청이 서버에 도착했을 때 일어나는 세 가지 상황이다.

• 재검사 적중 : 만약 서버 객체가 변경되지 않았다면, 서버는 클라이언트에게 작은 HTTP 304 Not Modified 응답을 보낸다.
• 재검사 부적중 : 만약 서버 객체가 변경되었다면, 서버는 클라이언트에게 HTTP 200 OK 응답을 새로운 객체와 함께 보낸다.
• 객체 삭제 : 서버 객체가 삭제되었다면, 서버는 404 Not Found 응답을 돌려보내며, 캐시는 사본을 삭제한다.

적중률

캐시가 요청을 처리하는 비율을 캐시 적중률, 혹은 문서 적중률이라고 부르기도 한다.
적중률을 0~100% 사이의 숫자로 표현한다.
적중률을 예측하기는 어렵지만 40%정도면 꽤 좋은 적중률이다.

바이트 적중률

문서들의 크기가 모두 같은 것이 아니기 때문에 때로 적중률보다는 바이트 적중률을 사용한다.
바이트 적중률은 캐시가 전체 바이트 중에서 얼마나 많은 바이트를 처리하는지를 나타낸다.

적중과 부적중의 구별

HTTP는 클라이언트에게 응답이 캐시 적중이었는지 아니면 원 서버 접근인지 말해주지 않는다. 모두 200 OK로 응답한다.
어떤 상용 프락시 캐시는 캐시에 무슨 일이 일어났는지 설명하기 위해 Via 헤더에 추가 정보를 붙인다.

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

캐시 토폴로지

한 명에게만 할당된 캐시를 개인 전용 캐시(private cache)라고 한다.
공유된 캐시는 공용 캐시(public cache)라고 한다.

개인 전용 캐시

캐인 전용 캐시는 많은 저장 공간, 에너지를 필요로 하지 않으므로 작고 저렴하다.
보통 웹브라우저는 개인 전용 캐시를 내장하고 있다.
브라우저가 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정을 수정할 수 있도록 허용한다.

공용 프락시 캐시

공용 캐시는 캐시 프락시 서버 혹은 프락시 캐시라고 불리는 공유된 프락시 서버이다.
수동 프락시를 지정하거나 프락시 자동설정 파일을 설정함으로써 브라우저가 프락시 캐시를 사용하도록 설정할 수 있다.

프락시 캐시 계층들

작은 캐시에서 캐시 부적중시 더 큰 부모 캐시가 남겨진 트래픽을 처리하도록 계층을 만드는 경우도 있다.
이러한 계층을 프락시 캐시 계층이라고 한다.

캐시망, 콘텐츠 라우팅, 피어링

몇몇 네트워크 아키텍처는 단순한 캐시 계층 대신 복잡한 캐시망을 만든다.
캐시망의 프락시 캐시는 캐시에 대한 커뮤니케이션 결정을 동적으로 내려 캐시에게 요청할지 원 서버로 갈지 결정한다.

캐시망 안에서의 콘텐츠 라우팅을 위해 설계된 캐시들의 역할

• URL에 근거하여, 부모 캐시와 원 서버 중 하나를 동적으로 선택한다.
• URL에 근거하여 특정 부모 캐시를 동적으로 선택한다.
• 부모 캐시에게 가기 전에, 캐시된 사본을 로컬에서 찾아본다.
• 다른 캐시들이 그들의 캐시된 콘텐츠에 부분적으로 접근할 수 있도록 허용하되, 그들의 캐시를 통한 인터넷 트랜짓(Internet transit)은 허용하지 않는다.

서로 다른 조직들이 상호 이득을 위해 그들의 캐시를 연결하여 서로를 찾아볼 수 있도록 해준다. 이를 피어링(peering)이라고 한다.
그리고 선택적인 피어릉을 지원하는 캐시는 형제 캐시라고 한다.
HTTP는 형제 캐시를 지원하지 않기 때문에, 인터넷 캐시 프로토콜(ICP)이나 하이퍼 텍스트 캐시 프로토콜(HTCP)을 이용해 HTTP를 확장해서 사용한다.

캐시 처리 단계

HTTP GET 메시지 하자는 처리하는 기본적인 캐시 처리 절차는 일곱 단계이다.

1. 요청 받기 : 캐시는 네트워크로부터 도착한 요청 메시지를 읽는다.
2. 파싱 : 캐시는 메시지를 파싱하여 URL과 헤더들을 추출한다.
3. 검색 : 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아온다.(그리고 로컬에 저장한다.)
4. 신선도 검사 : 캐시는 캐시된 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지 서버에게 물어본다.
5. 응답 생성 : 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다.
6. 발송 : 캐시는 네트워크를 통해 응답을 클라이언트에게 돌려준다.
7. 로깅 : 캐시는 선택적으로 트랜잭션을 로그에 기록한다.

단계 1: 요청 받기

캐시는 네트워크 커넥션에서의 활동을 감지 하고, 들어오는 데이터를 읽어들인다. 고성능 캐시는 여러 커넥션으로 부터 동시에 요청을 받고 메시지 전체가 도착하기 전 트랜잭션을 처리한다.

단계 2: 파싱

캐시는 요청 메시지를 여러 부분으로 파싱하여 헤더 부분을 조작하기 쉬운 자료 구조에 담는다. 이는 캐싱 소프트웨어가 헤더 필드를 처리하고 조작하기 쉽게 만들어준다.

단계 3: 검색

캐시는 URL을 알아내고 그에 해당하는 로컬 사본이 있는지 검사한다.
전문적인 수준의 캐시는 객체를 로컬 캐시에서 가져올 수 있는지 판단하기 위해 빠른 알고리즘을 사용해야한다.
만약 가져 올 수 없다면 원서버나 부모 프락시에서 가져오거나 혹은 실패한다.
캐시된 객체는 서버 응답 본문과 원 서버 응답 헤더를 포함하고 있으므로, 캐시 적중 동안 올바른 서버 헤더가 반환될 수 있다.

단계 4: 신선도 검사

HTTP는 캐시가 일정 기간 동안 서버 문서의 사본을 보유할 수 있도록 해준다.
하지만 신선한 문서와 신선하지 않은 문서를 구분하고 신선하지 않은 문서를 재검사 해야한다. 신선도 검사 규칙은 복잡하여 뒤쪽에서 자세히 다루겠다.

단계 5: 응답 생성

캐시된 응답은 원 서버에서 온 것 처럼 보이게 해야한다.
따라서 캐시는 캐시된 서버 응답 헤더를 토대로 응답 헤더를 생성한다.
하지만 클라이언트에 맞게 헤더를 조정해야 하는데 클라이언트가 HTTP/1.1 응답을 기대하는 상황에서 서버가 HTTP/1.0 응답을 반환 했다면, 캐시는 헤더를 적절히 번역 해야한다. 또한 캐시 신선도 정보도 포함( Cache-Control, Age, Expires)해야한다.
캐시는 Date 헤더는 조정하면 안된다. Date 헤더는 원 서버에서 객체 가 생성된 최초의 일시를 표시한다.

단계 6: 전송

응답 헤어가 준비되면, 캐시는 응답을 클라이언트에게 돌려준다.
모든 프락시 서버들과 마찬가지로, 프락시 캐시는 클라이언트와의 커넥션을 유지할 필요가 있다.
고성능 캐시는 종종 로컬 저장장치와 네트워크 I/O 버퍼 사이에서 문서의 콘텐츠 복사를 피함으로써 데이터를 효과적으로 전송하기위해 노력한다.

단계 7: 로깅

캐시는 로그 파일과 캐시 사용에 대한 통계를 유지한다. 트랜잭션 완료 후 캐시는 통계 캐시 적중과, 부적중 획수에 대한 통계를 갱신하고 로그 파일에 요청 종류, URL 그리고 무엇이 일어났는지를 알려주는 항목을 추가한다.

단계 8 캐시 처리 플로차트

사본을 신선하게 유지하기

캐시된 사본을 항상 서버의 사본과 일치하게 변경해야한다.
HTTP는 어떤 캐시가 사본을 갖고 있는지 서버가 기억하지 않더라도, 캐시된 사본이 서버와 충분히 일치하도록 유지할 수 있게 해주는 단순한 메커니즘을 갖고 있다.
이러한 매커니즘을 문서 만료와 서버 재검사라고 부른다.

문서 만료

HTTP는 Cache-Control과 Expries라는 헤더를 이용해서 원 서버가 각 문서에 유효기간을 붙일 수 있게 해준다.
만료된 캐시는 반드시 서버와 문서에 변경된 것이 없는지 검사해야한다. 만약 그렇다면 신선한 사본을 얻어와야 한다.

유효기간과 나이

서버 재검사

캐시된 문서가 만료되었을 때 서버 재검사를 통해 캐시된 사본이 여전히 신선한지 확인할 수 있다.

• 재검사 결과 콘텐츠가 변경 되었다면, 캐시는 그 문서의 새로운 사본을 가져와 오래된 데이터 대신 저장한 뒤 클라이언트에게도 보내준다.
• 재검사 결과 콘텐츠가 변경되지 않았다면, 캐시는 새 만료일을 포함한 새 헤더들만 가져와서 캐시 안에 헤더들을 갱신한다.

조건부 메서드와의 재검사

HTTP는 캐시가 서버에게 ‘조건부 GET’ 요청을 보낼 수 있도록 해준다.

HTTP는 다섯 가지 조건부 요청 헤더를 정의하고 있는데 자주 사용하는 두가지는 다음과 같다.

If-Modified-Since: 날짜 재검사

가장 흔히 쓰이는 캐시 재검사 헤더는 If-Modified-Since 헤더이다.
이 요청을 흔히 IMS라고 부른다.

• 만약 문서가 주어진 날짜 이후로 변경되었다면, If-Modified-Since 조건은 참이다. 따라서 서버는 새로운 만료 날짜와 그외 헤더들과 함께 캐시에게 반환된다.
• 만약 문서가 주어진 날짜 이후로 변경되지 않았다면, If-Modified-Since 조건은 거짓이다. 따라서 서버는 304 Not Modified 응답을 반환한다. Content-Type은 잘 변하지 않아 대개 보내줄 필요가 없고, 새 만료 날짜는 보통 보내주게 된다.

If-None-Match: 엔터티 태그 재검사

보통은 최근 변경 일시 재검사를 실행하지만 행해지기 어려운 상황이 몇가지 있다.

• 문서가 일정한 간격으로 다시 쓰여지지만, 실제로는 같은 데이터를 포함하는 경우 내용에는 아무런 변화가 없더라도 변경시각은 바뀔 수 있다.
• 1초보다 작은 간격으로 갱신되는 문서를 제공하는 서버는 문서가 변경되었는지 확인하기 위해 1초보다 작은 간격으로 재검사를 해야한다.
• 어떤 서버들은 그들이 갖고 있는 페이지에 대한 최근 변경 일시를 정확하게 판별할 수 없다.

문서를 변경했을 때, 서버는 ETag 헤더를 이용해 문서의 버전을 확인한다.
예를들어 캐시가 엔터티 태그 v2.6인 문서를 갖고 있을 때 캐시는 원 서버에게 태그가 더이상 v2.6이 아닌 경우에만 새 객체를 달라고 요청하는 방법으로 유효한지 여부를 검사한다.
만약 문서가 변경되지 않았다면, 서버는 304 Not Modified 응답을 반환한다.
만약 문서가 변경되었다면, 서버는 새로운 문서와 함께 새로운 엔터티 태그와 함께 200 OK 응답을 반환한다.

캐시가 객체에 대한 여러 개의 사본을 갖는 경우 If-None-Match 헤더에 여러개의 ETag를 포함시킬 수 있다. If-None-Match: "v2.6", "v2.5", "v2.4"

약한 검사기와 강한 검사기

서버는 때때로 모든 캐시된 사본을 무효화시키지 않고 문서를 살짝 고칠 수 있도록 허용하고 싶은 경우가 있다.
HTTP/1.1은 이를 위해 약한 검사기(well-behaved validator)와 강한 검사기(strong validator)라는 두 가지 종류의 검사기를 정의하고 있다.

강한 검사기는 콘텐츠가 바뀔 때마다 바뀐다. 약한 검사기는 어느 정도 콘텐츠 변경을 허용하지만, 콘텐츠의 중요한 의미가 변경되면 함께 변경된다.
약한 검사기는 헤더에 W/ 접두사를 붙여서 표시한다.

ETag: W/"v2.6"
If-None-Match: W/"v2.6"

언제 엔터티 태그를 사용하고 언제 Last-Modified 일시를 사용하는가

HTTP/1.1 클라이언트는 만약 서버가 엔터티 태그를 반환했다면, 반드시 엔터티 태그 검사기를 사용해야 한다.
만약 서버가 Last-Modified 값만을 반환했다면, 클라이언트는 If-Modified-Since 검사를 사용할 수 있다. 만약 서버가 Last-Modified와 ETag 둘 다 받았다면, 요청의 모든 조건부 헤더 필드의 조건에 부합되지 않는 한 304 Not Modified 응답을 반환해서는 안된다.

캐시제어

HTTP는 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있는 여러 가지 방법을 정의한다.

• Cache-Control: no-store 헤더를 응답에 첨부할 수 있다.
• Cache-Control: no-cache 헤더를 응답에 첨부할 수 있다.
• Cache-Control: max-age 헤더를 응답에 첨부할 수 있다.
• Cache-Control: must-revalidate 헤더를 응답에 첨부할 수 있다.
• Expires 헤더를 응답에 첨부할 수 있다.
• 아무 만료 정보도 주지 않고, 캐시가 스스로 휴리스틱 방법으로 결정하게 할 수 있다.

no-cache와 no-store 응답 헤더

no-store와 no-cache 헤더는 캐시가 검증되지 않는 캐시된 객체로 응답하는 것을 막는다.

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

no-store는 캐시가 응답을 저장하지 않도록 한다. no-cache는 캐시가 응답을 저장할 수 있지만, 반드시 서버에 재검사를 요청해야 한다. 더 나은 이름은 재검사 없이 캐시에서 제공하지 마라이다. Pragma: no-cache는 HTTP/1.0과의 호환성을 위해 남아있는 헤더이다. 굳이 HTTP/1.0을 사용할 필요가 없다면 Cache-Control: no-cache를 사용하는 것이 좋다.

Max-Age 응답 헤더

Cache-Control: max-age=<seconds> 헤더는 캐시가 응답을 얼마나 오래 저장할 수 있는지를 지정한다.
Cache-Control: s-maxage=<seconds> 헤더는 공용 캐시에만 적용된다. 개인 캐시는 이 헤더를 무시한다.

서버는 최대 나이먹음을 0으로 설정함으로써, 캐시가 매 접근마다 문서를 캐시하지 않거나 혹은 매 접근마다 리프레시 하도록 요청할 수 있다.

Expires 응답 헤더

Expires 현재는 Deprecated 되었지만 사용하는 경우가 많다.
몇몇 서버는 문서를 항상 만료되도록 하기 위해 Expires 헤더에 0을 설정한다. 이는 문서 위반이며 몇몇 소프트웨어와 문제를 일으 킬 수 있다. 이런 값들은 가급적 사용하지 말아야 한다.

Must-Revalidate 응답 헤더

캐시는 성능을 위해 만료된 객체를 제공하도록 설정 할 수 있다.
만약 캐시가 만료 정보를 엄격하게 따르길 원한다면, Cache-Control: must-revalidate 헤더를 사용할 수 있다.
이 헤더는 캐시가 만료된 객체를 제공하지 않도록 강제한다. 만약 만료된 객체를 제공하려고 하면, 캐시는 서버에게 재검사를 요청해야 한다.
만약 캐시가 must-revalidate 신선도 검사를 시도 했을 때 원 서버를 사용할 수 없는 상태라면, 캐시는 504 Gateway Timeout 응답을 반환한다.

휴리스틱 만료

만약 응답이 Cache-Control: max-age 헤더를 포함하지 않고, Expires 헤더를 포함하고 있다면, 캐시는 휴리스틱 방법을 사용해 만료 날짜를 계산한다.
계산 결과 얻은 최대 나이 값이 24보다 크다면 Heuristic Expiration 경고 헤더가 응답 헤더에 추가 되어야한다.

유명한 휴리스틱 만료 알고리즘의 하나인 LM 인자 알고리즘은 문서가 마지막으로 변경된 시간과 문서의 크기를 이용해 만료 날짜를 계산한다.

클라이언트 신선도 제약

웹브라우저는 브라우저나 프락시 캐시의 신선하지 않은 콘텐츠를 강제로 갱신시켜주는 리프레시나 리로드 버튼을 갖고 있다.
이 리프레시 버튼은 Cache-control 요청 헤더가 추가된 GET 요청을 발생시켜서, 강제로 재검사하거나 서버로부터 콘텐츠를 무조건 가져온다.

Cache-Control 요청 지시어는 위의 예 외에도 다양하게 존재하니 한번씩 찾아보는 것이 좋을 듯 하다.

주의할 점

문서 만료는 완벽한 시스템이 아니기 때문에 유효기간을 짧게 설정하는 것이 좋다.

캐시 제어 설정

웹 서버들은 캐시 제어와 만료 HTTP 헤더들을 설정하는 서로 다른 메커니즘을 제공한다.

아파치로 HTTP 헤더제어하기

mode_headers

개별 헤더들을 설정할 수 잇게 해준다. 한번 이 모듈이 로드되면, 헤더들을 설정하기 위해 아파치의 설정 파일에 헤더들을 추가할 수 있다.

mod_expires

적절한 만료 날짜가 담긴 Expires 헤더를 자동으로 생성하는 프로그램 로직을 제공한다.

mod_cern_meta

mod_cern_meta는 HTTP 헤더들의 파일을 특정 객체와 연결시켜준다.

HTTP-EQUIV를 통한 HTML 캐시 제어

HTML 문서는 HTTP-EQUIV 헤더를 이용해 캐시 제어 헤더를 포함시킬 수 있다.
이 헤더는 HTML 문서의 <head> 태그 안에 포함되어야 한다.
웹 서버 설정 파일과의 상호작용 없이도 쉽게 HTML문서에 HTTP 헤더 정보를 부여할 수 있는 장점이 있지만 현재는 거의 사용되지 않는다.

자세한 알고리즘

나이와 신선도 수명

나이 계산

완전한 나이 계산 알고리즘

신선도 수명 계산

완전한 서버 신선도 알고리즘

캐시와 광고

지금 까지 캐시는 사용자를 도와 더 좋은 경험을 제공하고, 또한 네트워크 사업자들이 트래픽을 줄일 수 있도록 도와준다는 것을 알았다.

광고 회사의 딜레마

콘텐츠 제공자 입장에서는 캐시를 쓰게되면 멀티 프로세서 웹서버가 필요없기에 비용을 줄일 수 있고, 또한 캐시를 통해 더 빠른 응답을 제공할 수 있기 때문에 사용자들이 더 많은 콘텐츠를 소비할 수 있게 된다.
하지만 콘텐츠 제공자는 광고를 통해 돈을 번다. 하지만 접근 횟수에 따라 돈을 벌기 때문에 캐시를 통해 접근 횟수가 줄어들면 돈을 덜 벌게 된다.
캐싱이 완벽하게 동작한다면 원서버는 HTTP 접근을 수진하지 못하기에 접근 횟수를 올릴 수 없다.

퍼블리셔의 응답

오늘날 광고회사들은 캐시가 광고 시청 수를 가로채지 못하도록 모든 종류의 캐시 무력화 기법을 사용한다. 이러한 기법들은 캐시가 광고를 제공하는 서버에 접근하도록 강제한다. 보통 CGI 게이트웨이를 통해 제공한다. 매 접근마다 광고 URL을 고쳐 쓴다.
한 가지 방법은 모든 접근에 대해 원 서버와 재검사하도록 캐시를 설정한다. 매 접근마다 원 서버에 캐시 적중이 있었음을 알리지만 보통 본문 데이터를 전송하지 않는다.

로그 마이그레이션

서버로 요청이 가지 않게 하고 모든 적중 로그를 남겨 서버에게 제공하는 방법이 있지만 콘텐츠 제공자별로 분리 될 수 있도록 표준화 되어 있지도 조직되어있지도 않다. 뿐만아니라 인증과 프라이버시 이슈도 있다.

적중 측정과 사용량 제한

RFC 2227, “HTTP를 위한 간단한 캐시 적중량 측정과 사용량 제한”은 간단한 방법을 정의한다.
이 프로토콜은 HTTP에 때때로 특정 URL에 대한 캐시 적중 횟수를 정기적으로 서버에게 돌려주는 Meter라고 하는 헤더를 추가한다.
이 방법은 서버가 캐시된 문서가 적중한 횟수의 정기적인 업데이트를 캐시로부터 받는다.
추가적으로 , 서버는 캐시가 서버에게 보고해야 하기 전까지, 문서를 제공할 수 있는 횟수나 소모할 수 있는 처리시간을 제어할 수 있다.
이를 사용량 제한이라고 부른다.
이것은 캐시가 원 서버에게 보고하기 전에 캐시된 리소스가 얼마나 많이 사용될 수 있는지 서버가 제어할 수 있게 해준다.

문제

1. 캐싱에서 If-Modified-Since 헤더의 의미는 무엇입니까?
   1. 캐시된 콘텐츠의 최대 수명을 지정합니다.
   2. 문서가 마지막으로 수정된 시간을 나타냅니다.
   3. 서버에 대한 조건부 GET 요청에 도움이 됩니다.
   4. 캐시의 만료 시간을 제어합니다.
2. 캐시된 문서가 여전히 최신이고 서버에서 수정되지 않았는지 확인하는 데 사용되는 HTTP 헤더는 무엇입니까?
   1. Expires
   2. Last-Modified
   3. If-None-Match
   4. Cache-Control
3. If-None-Match 헤더를 사용한 조건부 캐싱 프로세스와 이것이 네트워크 리소스 최적화에 어떻게 도움이 되는지 설명하세요.
   • 조건부 캐싱에는 요청에 If-None-Match 헤더가 사용됩니다. 클라이언트는 캐시된 콘텐츠의 ETag 값을 포함하며, 서버가 콘텐츠가 변경되지 않았다고 판단하면(ETag 기반) 304 Not Modified 상태로 응답하여 대역폭과 리소스를 절약합니다.
4. 응답 캐싱을 방지하고 모든 요청에 ​​대해 재검증을 요구하는 Cache-Control 지시어는 무엇입니까?
   1. max-age
   2. s-maxage
   3. no-store
   4. must-revalidate
5. Cache-Control: must-revalidate 헤더는 캐시를 사용하기 전에 캐시가 캐시된 응답의 상태를 사용하기 전에 원본 서버에서 확인해야 하며 재검증에 실패하면 504 Gateway Timeout 응답이 발생하도록 보장합니다.
   • false