[HTTP 완벽 가이드] 7장 캐시

웹 캐시

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

웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면, 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다.

불필요한 데이터 전송

불필요한 데이터 전송은 대역폭을 잡아먹고, 전송을 느리게하며, 웹 서버의 부하룰 준다.

캐시를 이용하면 , 첫 번째 서버 응답은 캐시에 보관된다.

캐시된 사본이 뒤이은 요청들에 대한 응답으로 사용 될 수 있기 때문에 원 서버가 중복해서 트래픽을 주고 받는 낭비가 줄어들게 된다.

대역폭 병목

캐시는 또한 네트워크 병목을 줄여 줄 수 있다.

갑작스러운 요청 쇄도

캐싱은 갑작스러운 요청 쇄도에 대처하기 위해 특히 중요하다.

갑작스러운 사건으로인해 많은사람이 거의 동시에 웹 문서에 접근할때 캐싱은 아주 유용하다.

거리로 인한 지연

비록 대역폭이 문제가 되지 않더라도, 거리가 문제가 될 수 있다.

모든 네트워크 라우터는 제각각 인터넷 트래픽을 지연시킨다.

캐시를 설치해서 문서가 전송되는 거리를 많이 줄 일 수 있다.

적중과 부적중

캐시는 유용하지만 캐시가 세상 모든 문서의 사본을 저장하지는 않는다.

캐시에 요청이 도착했을때, 만약 그에 대응 하는 사본이 있다면 그를 이용해 요청이 처리 될 수 있다.

이것을 캐시 적중 이라 부른다.

만약 대응하는 사본이 없다 하면 원 서버로 전달되기만 할 뿐이고 이것을 캐시 부적중 이라고 부른다.

재검사

캐시는 반드시 그들이 갖고 있는 사본이 여전히 최신인지 서버를 통해 때때로 점검해야한다.

이러한 신선도 검사 를 HTTP 재검사 라고 부른다.

캐시는 스스로 원한다면 언제든지 사본을 검사 할 수 있다.

대부분의 캐시는 클라이언트가 사본을 요청하였으며 그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 실시한다.

캐시는 캐시된 사본의 재검사가 필요할때, 원 서버에 작은 재검사 요청을 보낸다.

재검사 적중

콘텐츠가 변경되지 않았다면, 서버는 아주 작은 304 Not Modified 응답을 보낸다.

이를 통해 사본이 여전히 유효함을 알게된 캐시는 신선하다고 임시로 다시 표시한뒤 사본을 클라이언트에게 제공한다. 이를 재검사 적중 혹은 느린 적중 이라 부른다.

재검사 부적중

서버 객체가 캐시된 사본과 다르다면, 서버는 콘텐츠의 전체와 함께 평범한 HTTP 200 OK 응답을 클라이언트에게 보낸다.

객체 삭제

만약 서버 객체가 삭제되었다면, 서버는 404 Not Found 응답을 돌려보내며 캐시는 사본을 삭제한다.

문서 적중률

캐시가 요청을 처리하는 비율을 캐시 적중률 혹은 문서 적중률 이라 부르기도 한다.

0%는 모든 요청이 부적중임을 ( 네트워크 너머로 문서를 가져와야 했던 경우),

100%는 모든 요청이 캐시적중(캐시에서 사본을 가져온경우)를 의미한다.

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

문서 적중률은 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지 보여주며, 문서 적중률을 개선하면 전체 대기(지연)시간이 줄어든다.

바이트 적중률

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

이 측정값은 트래픽이 절감된 정도를 포착해내고 바이트 단위 적중률 100%는 모든 바이트가 캐시에서 왔으며, 어떤 트래픽도 인터넷으로 나가지 않았음을 의미한다.

바이트 단위 적중률은 얼마나 많은 바이트가 인터넷으로 나가지 않았는지 보여주며, 바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.

적중과 부적중의 구별

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

클라이언트가 응답이 캐시에서 왔는지 알아내는 한 가지 방법은 Date헤더를 이용하거나 Age 헤더를 이용하는 것 이다.

캐시 토폴로지

캐시는 한 명의 사용자에게만 할당될 수 있고 여러명의 사용자들 간에 공유될 수도 있다.

• 개인 전용 캐시 - 한명에게만 할당된 캐시이며 개인을 위한 캐시이므로 한 명의 사용자가 자주 찾아가는 페이지를 담는다.
• 공용 캐시 - 공유되는 캐시인 공용 캐시는 사용자 집단에 자주 쓰이는 페이지를 담는다.

개인 전용 캐시

개인 전용 캐시는 많은 에너지나 저장 공간을 필요로 하지않으므로, 작고 저렴 할 수 있다.

웹브라우저는 개인 전용 캐시를 내장하고 있다. 대부분 브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해놓는다.

공용 프락시 캐시

공용 캐시는 캐시 프락시 서버 혹은 프락시 캐시 라고 불리는 특별한 종류의 공유된 프락시 서버다.

프락시 캐시는 로컬 캐시에서 문서를 제공하거나, 사용자의 입장에서 서버에 접근한다.

공유된 공용 캐시에서, 캐시는 자주 찾는 객체를 단 한번만 가져와 모든 요청에 대해 공유된 사본을 제공함으로써 네트워크 트래픽을 줄요준다.

프락시 캐시 계층들

클라이언트 주위에는 작고 저렴한 캐시를 사용하고, 계층 상단에는 많은 사용자들에 의해 공유되는 문서를 유지 하기위해 더 크고 강력한 캐시를 사용하자는 것이다.

캐시 계층이 깊다면 요청은 캐시의 긴 연쇄를 따라가게 될것이다.

프락시 연쇄가 길어질수록 각 중간 프락시는 현저한 성능 저하가 발생할 것이다.

캐시 처리 단계

HTTP GET 메세지 하나를 처리하는 기본적인 캐시 처리 절차는 일곱 단계로 이루어져 있다.

요청 받기

커넥션에서의 활동을 감지하고 들어오는 데이터를 읽어들인다.

고성능 캐시는 여러 개의 들어오는 커넥션들로부터 데이터를 동시에 읽어들이고 메세지 전체가 도착하기도 전에 트랙잭션 처리를 시작한다.

파싱

캐시는 요청 메세지를 여러 부분으로 파싱하여 헤더 부분을 조작하기 쉬운 자료구조에 담는다.

검색

캐시는 URL을 알아내고 그에 해당하는 로컬 사본이 있는지 검사한다.

만약 문서를 로컬에서 가져올 수 없다면, 캐시는 상황이나 설정에 따라서 그것을 원 서버나 부모 프락시에서 가져오거나 혹은 실패를 반환한다.

캐시된 객체는 또한 객체가 얼마나 오랫동안 캐시에 머무르고 있었는지를 알려주는 기록이나 얼마나 자주 사용되었는지 등에 대한 몇몇 메타데이터를 포함한다.

신선도 검사

HTTP는 캐시가 일정 기간 동안 서버 문서의 사본을 보유할 수 있도록 해준다.

캐시된 사본을 신선도 한계를 넘을 정도로 너무 오래 갖고 있었다면 그 객체는 신선하지 않은 것으로 간주하며, 캐시는 그 문서를 제공하기 전에 문서에 어떤 변경이 있었는지 검사하기 위해 서버와 재 검사를 해야 한다.

응답 생성

캐시된 응답을 원 서버에서 온 것처럼 보이게 하고 싶기 때문에, 캐시는 캐시된 서버 응답 헤더를 토대로 응답 헤더를 생성한다. 기저 헤더들은 캐시에 의해 수정되고 늘어난다.

캐시는 또한 캐시 신선도 정보를 삽입하며(Cache-Control, Age, Expires 헤더), 또 요청이 프록시 캐시를 거쳐갔음을 알려주기 위해 종종 via헤더를 포함시킨다.

단 단 캐시가 Date 헤더를 조정해서는 안된다.

전송

응답 헤더가 준비되면, 캐시는 응답을 클라이언트에게 돌려준다.

프록시 캐시는 클라이언트와의 커넥션을 유지할 필요가 있다.

로깅

대부분의 캐시는 로그 파일과 캐시 사용에 대한 통계를 유지한다.

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

사본을 신선하게 유지하기

캐시된 사본 모두가 서버의 문서와 항상 일치하는것은 아니다.

결국 문서들은 시간에 따라 변경된다.

캐시된 데이터는 서버의 데이터와 일치하도록 관리되어야 한다.

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

HTTP는 이 단순한 매커니즘을 문서 만료와 서버 재검사 라고 부른다.

문서 만료

HTTP는 Cache-Control과 Expires 라는 특별한 헤더를 이용해서 원 서버가 각 문서에 유효기간을 붙일 수 있게 해준다.

캐시 문서가 만료되기전 캐시는 필요하다면 서버와의 접촉 없이 사본을 제공할 수 있다.

일단 캐시된 문서가 만료되면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야하며 만약 그렇다하면 신선한 사본을 얻어와야함.

유효기간과 나이

서버는 응답 본문과 함께 Expires 나 Cache-Control: max-age 응답 헤더를 이용해서 유효기간을 명시한다.

max-age 헤더는 기본적으로 같은 일을 하지만 절대 시간은 컴퓨터의 시계가 올바르게 맞추어져 있을것을 요구한다.

헤더	설명
Cache-Control: max-age	max-age 값은 문서의 최대 나이를 정의함 (초 단위)
Expires	절대 유효기간을 명시함.
만약 유효기간이 경과디었다면, 그 문서는 더이상 신선하지 않다.

서버 재검사

캐시된 문서가 만료되었다는 것은 이제 검사할 시간이 되었음을 뜻함.

이 검사를 캐시가 원 서버에게 문서가 변경되었는지의 여부를 물어 볼 필요가 있음을 의미하는 서버재 검사 라고 부름

• 재 검사 후 변경되었을때 - 캐시는 그 문서의 새로운 사본을 가져와 오래된 데이터 대신 저장한뒤 클라잉너트에게 보내줌
• 재 검사 후 변경되지 않았을때 - 캐시는 새 만료일을 포함한 새 헤더들만 가져와서 캐시 안의 헤더들을 갱신함.

HTTP 프로토콜은 캐시가 다음 중 하나를 반환하는 적절한 행동을 할 것을 요구함

• 충분히 신선한 캐시된 사본
• 원 서버와 재검사 되었기 때문에, 충분히 신선하다고 확신할 수 있는 캐시된 사본
• 에러 메세지( 원 서버가 다운된 경우)
• 경고 메세지가 부착된 캐시 사본

조건부 메소드와 재 검사

HTTP의 조건부 메서드는 재 검사를 효율적으로 만들어준다.

HTTP는 캐시가 서버에게 조건부 GET 이라는 요청을 보낼 수 있도록 해줌.

이 요청은 서버가 갖고있는 문서가 캐시가 갖고 있는 것과 다른 경우에만 객체 본문을 보내달라고 하는 것

HTTP는 다섯가지 조건부 요청 헤더를 정의한다.

그중 두가지는 캐시 재검사를 할 떄 유용한 If-Modifed-Since 와 If-None-Match 이다.

If-Modifed-Since: 날짜 재 검사

가장 흔히 쓰이는 캐시 재검사 헤더는 If-Modifed-Since이며 흔히 IMS 요청이라 불림.

서버에게 리소스가 특정 날짜 이후 변경된 경우에만 요청한 본문을 보내달라고 한다.

• 변경되었을때 - 새문서가 , 새로운 만료 날짜와 그 외 다른 정보들이 담긴 헤더들과 함께 캐시에 반환됨.
• 변경안됬을때 - 304 Not Modifed 응답 메세지를 클라이언트에게 돌려준다.

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

If-Modifed-Since검사가 적절히 행해지기 어려운 상황이 몇 있음

• 어떤 문서는 일정 시간 간격으로 다시 쓰여지지만 실제로는 같은데이터를 포함하고 있을때 내용 에는 변화가 없더라도 변경시간은 바뀔 수 있음
• 최근 변경 일시를 정확하게 판별 할 수 없을때
• 1초보다 작은 간격으로 갱신되는 문서를 제공하는 서버들에게는, 변경일에 대한 1초의 정밀도는 충분하지 않을 수 있음

엔터티 태그 재검사는 문서의 엔티티 태그를 새로운 버전으로 표현할 수 있다.

엔터티 태그가 변경되었다면, 캐시는 새문서의 사본을 얻기(GET)위해 If-None-Match 조건부 헤더를 사용할 수있음

• 태그가 변경되었을떄 - 태그가 여전히 변경되지 않았으면 304 Not Modifed 응답이 반환됨
• 태그가 변경되었을떄 - 서버는 200 ok 응답으로 새 콘텐츠를 새 ETag 와 함꼐 반환함

캐시가 객체에 대한 여러 개의 사본을 갖고 있는 경우, 하나의 If-None-Match헤더에 여러 개의 엔터티 태그를 포하 시킬 수있음

If-None-Match: "v2.4","v2.5","v2.6" 

약한 검사기와 강한 검사기

HTTP/1.1은 비록 콘텐츠가 조금 변경되었더라도 “그 정도이면 같은것” 이라고 서버가 주장할 수 있도록 해주는 약한 검사기 를 지원한다.

강한 검사기 는 콘텐츠가 바뀔때마다 바뀐다.

약한 검사기는 어느 정도 콘텐츠 변경을 허용하지만, 콘텐츠의 중요한 의미가 변경되면 함께 변경된다.

캐시 제어

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

no-cache와 no-store 응답 헤더

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

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

no-store

이 표시가 표시된 응답은 캐시가 그 응답의 사본을 만드는것을 금지함.

이렇게되면 캐시서버는 클라이언트에게 응답으 전달하고 나면 객체를 삭제하기됨

no-cache

이 표시가 표시된 응답은 사실 로컬 캐시 저장소에 저장될 수 있음

다만 먼저 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없음

이 헤더의 더 나은 이름은 “Do-Not-Service-From-Cache-Without-Revalidaton” (재 검사 없이 캐시에서 제공하지 마라)일 것

Max-Age 응답 헤더

Cache-Control: max-age 헤더는 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간이고, 초로 나타냄

s-maxage헤더는 max-age처럼 행동하지만 공유된(공용) 캐시에서만 적용됨

Expires 응답 헤더

더 이상 사용하지 않기를 권하는 Expires 헤더는 초 단위의 시간 대신 실제 만료 날짜를 명시한다.

Must-Revalidate 응답 헤더

만약 캐시가 만료 정보를 엄격하게 따르길 원한다면 원 서버는 이 헤더를 붙일 수 있다.

Cache-Control: must-revalidate

이 헤더는 캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 재검사 없이는 제공해서는 안됨을 의미함.

만약 해당 캐시가 신선도 검사를 시도했을 떄 원 서버가 사용 할 수 없는 상태라면 504 Timeout erorr 를 반환해야함

휴리스틱 만료

만약 응답에 어느것도 포함하지 않고 있다면, 캐시는 경험적인 방법으로 최대 나이를 계산할 것

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

만약 캐시된 문서가 마지막으로 변경된것이 상당히 예전이면 갑자기 바뀔 가능성은 별로 크지 않을 것이므로, 캐시에 더 오래 보관하고 있어도 안전하다

만약 캐시된 문서가 최근에 변경되었다면 그것은 아마 자주 변경될 것이고, 따라서 우리는 그것을 서버와 재검사하기 전까지 짧은 기간동안만 캐시해야 한다.

클라이언트 신선도 제약

클라이언트는 Cache-Control 요청 헤더를 사용하면 만료 제약을엄격하게 하거나 느슨하게 할 수 있음