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

이 장에서 다룰 내용

• 어떻게 캐시가 성능을 개선하고 비용을 줄이는가
• 캐시 효과를 극대화 하기 위해 캐시를 어디에 위치시켜야 하는가
• 어떻게 HTTP가 캐시된 사본을 신선하게 유지하는가
• 어떻게 캐시가 다른 캐시나 서버와 상호작용하는가\

 

7.1 불필요한 데이터 전송

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

 

7.2 대역폭 병목

• 캐시는 광역 통신망의 제한된 대역폭으로 인한 병목을 개선할 수 있다.
• 먼 지역의 파일을 가져오는것보다, 같은 지역의 캐시된 파일을 가져오는 것이 더 빠르다
• 대역폭은 속도에 영향을 주는 네트워크 종류와 문서 크기에 따라 전송 시간이 차이난다

 

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

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

 

7.4 거리로 인한 지연

• 모든 네트워크 라우터는 제각각 인터넷 트래픽을 지연시킨다
• 빛의 속도 그 자체가 유의미한 지연을 유발한다.
• 병렬이면서 Keep-alive인 커넥션이라 할지라도, 빛의 속도는 뚜렷한 지연을 발생시킨다

 

7.5 적중과 부적중

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

 

7.5.1 재검사(Revalidation)

• 원 서버 콘텐츠가 변경될 수 있기 때문에, 캐시는 반드시 그들이 가지고 있는 사본이 여전히 최신인지 서버를 통해 때때로 점검해야 한다. 이러한 '신선도 검사'를 HTTP 재검사라 부른다.

• 성공적인 재검사는 캐시 부적중보다 빠르다. 실패한 재검사는 부적중과 거의 같다.

• HTTP는 재검사를 위해 If-Modified-Since 헤더를 사용한다

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

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

 

7.5.2 적중률

• 캐시가 요청을 처리하는 비율을 캐시 적중률 혹은 문서 적중률이라고 부른다
• 0~1 사이의 값으로 부르기도 하며, 퍼센트로 부르기도 한다
• 0%는 모든 요청이 캐시 부적중(네트워크 너머로 문서를 가져와야 했던 경우)
• 100%는 모든 요청이 캐시 적중(캐시에서 사본을 가져옴)

7.5.3 바이트 적중률

• 몇몇 큰 객체는 덜 접근되지만 크기 때문에 전체 트래픽에는 더 크게 기여한다
• 바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현한다
• 바이트 단위 적중률 100%는 모든 바이트가 캐시에서 왔으며, 어떤 트래픽도 인터넷으로 나가지 않았음을 의미한다

7.5.4 적중과 부적중의 구별

• 클라이언트는 캐시 적중이었는지 원 서버 접근이었는지 응답 코드 200 OK만 받으므로 알 수 없다
• 어떤 상용 프락시 캐시는 Via 헤더에 추가 정보를 붙인다
• 클라이언트는 Date헤더값을 현재 시각과 비교해서 캐시에서 온 건지 알 수 있다.
• 응답이 얼마나 오래되었는지 알기 위해선 Age 헤더를 이용한다

7.6 캐시 토폴로지

— 토폴로지 : 컴퓨터 네트워크의 요소들을 물리적으로 연결해 놓은 것, 또는 그 연결 방식

 

7.6.1 개인 전용 캐시

• 한 명에게만 할당된 캐시
• 웹브라우저는 개인 전용 캐시를 내장하고 있다
• 대부분의 브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정을 수정할 수 있도록 허용한다

7.6.2 공용 프락시 캐시

• 수천 명의 사용자들 간에 공유된 캐시
• 캐시 프락시 서버, 프락시 캐시라고도 불린다
• 공유된 공용 캐시에서, 캐시는 자주 찾는 객체를 단 한번만 가져와 모든 요청에 대해 공유된 사본을 제공함으로써 네트워크 트래픽을 줄인다

7.6.3 프락시 캐시 계층들

 

• 캐시 계층이 깊다면 요청은 캐시의 긴 연쇄를 따라가게 될 것이다. 프락시 연쇄가 깊어질수록 각 중간 프락시는 현저히 성능 조하가 발생할 것이다

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

캐시망의 프락시 캐시는 복잡한 방법으로 서로 대화하여, 어떤 부모 캐시와 대화할 것인지, 아니면 요청이 캐시를 완전히 우회해서 원 서버로 바로 가도록 할 것인지에 대한 캐시 커뮤니케이션 결정을 동적으로 내린다

 

7.7 캐시 처리 단계

 

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

 

7.8 사본을 신선하게 유지하기

7.8.1 문서 만료

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

7.8.2 유효기간과 나이

 

7.8.3 서버 재검사

• 재검사 결과 콘텐츠가 변경되지 않았다면, 캐시는 새 만료일을 포함한 새 헤더들만 가져와서 캐시 안의 헤더들을 갱신한다

7.8.4 조건부 메서드와의 재검사

 

7.9 캐시 제어

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

• no-store : 응답된 캐시가 그 응답의 사본을 만드는 것을 금지
• no-cache : 표시괸 응답은 사설 로컬 캐시 저장소에 저장된다. 다만 먼저 서버와 재검사를 하지 않고사는 캐시에서 클라이언트로 제공할 수 없다

7.9.2 Max-Age 응답 헤더

• 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간이고, 초로 나타낸다

7.9.3 Expires 응답 헤더

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

7.9.4 Must-Revalidate 응답 헤더

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

7.10 캐시 제어 설정

7.10.1 아파치로 HTTP헤더 제어하기

• mod-headers : 개별 헤더의 설정을 제어한다
• mod-expires : 적절한 만료 날짜가 담긴 헤더를 자동으로 생성하는 프로그램 로직을 제공한다

7.10.2 HTTP-EQUIV를 통한 HTML 캐시 제어

• 제공할 문서에 올바른 캐시 제어 헤더들을 부여하기 위해 설정 파일들과 상호작용한다
• 이 태그는 원래 웹 서버에서 사용되도록 의도된 것이다.

7.11 자세한 알고리즘

7.11.1 나이와 신선도 수명

• 문서의 나이는 서버가 문서를 보낸 후 그 문서가 나이를 먹은 시간의 총합이다
• 문서의 신선도 수명은 아직 문서가 신선하다고 볼 수 있는 수명이다

7.11.2 나이 계산

 

7.12 캐시와 광고

7.12.1 광고 회사의 딜레마

• 많은 콘텐츠 제공자가 광고를 통해 돈을 번다. 그러나 캐시는 원 서버가 실제 접근 횟수를 알 수 없게 숨길 수 있다. 만약 캐싱이 동작한다면 서버는 접근을 수신하지 않는다. 만약 접근 횟수에 따라 돈을 벌고 있다면, 이는 달갑지 않은 일일 것이다

7.12.2 퍼블리셔의 응답

• 콘텐츠 제공자는 캐시가 그들의 트래픽을 흡수하도록 내버려두어야하며, 캐시는 그들에게 적중이 얼마나 많이 일어났는지 알려주어야한다

7.12.3 로그 마이그레이션

• 이상적인 해결책은 서버로 요청이 가지 않도록 하는 것이다.
• 불행히도, 적중 로그는 그 크기 때문에 옮기기 어렵다.