[HTTP 완벽 가이드] 캐시

1) 캐시란?

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

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

 

- 캐시는 다음과 같은 혜택을 준다.

  (1) 캐시는 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다.

  (2) 캐시는 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 한다

  (3) 캐시는 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다.

  (4) 페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다.  

  

- 우리는 어떻게 캐시가 성능을 개선하고 비용을 줄이는지, 어떻게 그 효과를 측정하는지,

  그리고 효과를 극대화하기 위해 캐시를 어디에 위치시켜야 하는지 배울 것이다.

  우리는 또한 어떻게 HTTP가 캐시된 사본을 신선하게 유지하는지, 

  그리고 어떻게 캐시가 다른 캐시나 서버와 상호작용하는지도 설명할 것이다. 

 

2) 캐시가 필요한 이유

 

(1) 불필요한 데이터 전송

- 복수의 클라이언트가 자주 쓰이는 원 서버 페이지에 접근할 때, 서버는 같은 문서를 클라이언트들에게

  각각 한 번씩 전송하게 된다. 똑같은 바이트들이 네트워크를 통해 계속 반복해서 이동한다.

  이 불필요한 데이터 전송은 값비싼 네트워크 대역폭을 잡아먹고, 전송을 느리게 만들며, 웹 서버에 부하를 준다.

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

  캐시된 사본이 뒤이은 요청들에 대한 응답으로 사용될 수 있기 때문에,

  원 서버가 중복해서 트래픽을 주고 받는 낭비가 줄어들게 된다. 

 

(2) 대역폭 병목

- 캐시는 또한 네트워크 병목을 줄여준다. 많은 네트워크가 원격 서버보다 로컬 네트워크 클라이언트에

  더 넓은 대역폭을 제공한다. 클라이언트들이 서버에 접근할 때의 속도는,

  그 경로에 있는 가장 느린 네트워크의 속도와 같다.

  만약 클라이언트가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 캐싱은 성능을 대폭 개선할 수 있을 것이다.

 

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

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

  갑작스런 사건으로 인해 많은 사람이 거의 동시에 웹 문서에 접근할 때 이런 일이 발생한다.

  이 결과로 초래된 불필요한 트래픽 급증은 네트워크와 웹 서버의 심각한 장애를 야기시킨다.

  

(4) 거리로 인한 지연

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

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

  그리고 클라이언트와 서버 사이에 라우터가 그리 많지 않더라도, 

  빛의 속도 그 자체가 유의미한 지연을 유발한다. 

 

 

3) 캐시 적중과 부적중

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

  이것을 캐시 적중(Cache hit)이라고 부른다. 

  만약 대응하는 사본이 없다면 그냥 원 서버로 전달되기만 할 뿐이다.

  이것을 캐시 부적중(Cache miss)이라고 부른다.

 

3-1) 재검사(Revalidation)

- 원 서버 콘텐츠는 변경될 수 있기 때문에, 캐시는 반드시 그들이 갖고 있는 사본이 

  여전히 최신인지 서버를 통해 때때로 점검해야 한다. 

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

  효과적인 재검사를 위해, HTTP는 서버로부터 전체 객체를 가져오지 않고도 

  콘텐츠가 여전히 신선한지 빠르게 검사할 수 있는 특별한 요청을 정의했다. 

 

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

  그러나 캐시가 문서를 수백만 개씩 갖고 있는 경우가 흔한데 비해

  네트워크 대역폭은 부족하기 때문에, 대부분의 캐시는 클라이언트가 사본을 요청하였으며,

  그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 한다.

  

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

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

  그 사본이 여전히 유효함을 알게 된 캐시는 즉각 사본이 신선하다고 임시로 다시 표시한 뒤

  그 사본을 클라이언트에게 제공한다.

  이를 재검사 적중 혹은 느린 적중이라고 부른다. 

 

- HTTP는 캐시된 객체를 재확인하기 위한 몇 가지 도구를 제공하는데, 

  그 중에서 가장 많이 쓰이는 것은 If-Modified-Since 헤더다.

  서버에게 보내는 GET 요청에 이 헤더를 추가하면 

  캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미가 된다. 

 

 

3-2) 적중률

- 캐시가 요청을 처리하는 비율을 캐시 적중률(혹은 캐시 적중비), 혹은 문서 적중률(혹은 문서 적중비)

  이라고 부르기도 한다. 적중률은 0에서 1까지의 값으로 되어 있지만, 흔히 퍼센트로 표현되기도 한다.

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

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

 

- 캐시 관리자는 캐시 적중률이 100%에 근접하게 되는 것을 좋아할 것이다.

  실제 적중률으 캐시가 얼마나 큰지, 캐시 사용자들의 관심사가 얼마나 비슷한지,

  캐시된 데이터가 얼마나 자주 변경되거나 개인화되는지, 

  캐시가 어떻게 설정되어 있는지에 달려있다. 

 

- 적중률은 예측하기 어려운 것으로 악명이 높지만, 오늘날 적중률 40%면 웹 캐시로 괜찮은 편이다. 

   

4) 캐시 토폴로지

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

 한 명에게만 할당된 캐시를 개인 전용 캐시(private cache)라 부른다.

 공유된 캐시는 공용 캐시(public cache)라고 불린다. 

 

 

5)  캐시 처리 단계

-오늘날 상용 프락시 캐시는 꽤 복잡하다. 매우 고성능이면서도 HTTP와 그 외 다른 기술의 고급 기능을 

 지원하도록 만들어졌다. 그러나 몇 군데 미묘한 구석이 있긴 하지만, 웹 캐시의 기본적인 동작은 대개 단순하다.

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

 

 

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

2. 파싱 - 캐시는 메시지를 파싱하여 URL과 헤더들을 추출한다. 

3. 검색 - 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아온다(그리고 로컬에 저장한다)

4. 신선도 검사 - 캐시는 캐시된 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지

                          서버에게 물어본다.

5. 응답 생성 - 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다.

6. 발송 - 캐시는 네트워크를 통해 응답을 클라이언트에게 돌려준다.

7. 로깅 - 선택적으로, 캐시는 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남긴다. 

 

 

6)사본을 신선하게 유지하기

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

  결국 문서들은 시간에 따라 변경된다. 보고서는 매달 바뀔 수 있다.

  온라인 신문은 매일 바뀐다. 금융 자료는 매 초 변경될 수 있다.

  오래된 데이터를 제공하는 캐시는 불필요하다. 

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

 

- HTTP는 어떤 캐시가 사본을 갖고 있는지 서버가 기억하지 않더라도,

  캐시된 사본이 서버와 충분히 일치하도록 유지할 수 있게 해주는 단순한 메커니즘을 갖고 있다.

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

 

(1) 문서 만료

- HTTP는 Cache-Control과 Expires라는 특별한 헤더들을 이용해서 원 서버가 각 문서에 유효기간을 

  붙일 수 있게 해준다.

  우유팩에 쓰여 있는 유효기간과 마찬가지로, 이 헤더들을 콘텐츠가 얼마나 오랫동안 신선한 상태로

  보일 수 있는지 좌우한다. 

 

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

  그러나 일단 캐시된 문서가 만료되면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 하며, 

  만약 그렇다면 신선한 사본을 얻어 와야 한다. 

 

 

7) 캐시 제어

- HTTP는 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지

  서버가 설정할 수 있는 여러가지 방법을 정의한다.

  우선순위대로 나열해보면 서버는, 
  (1) Cache-Control: no-store 헤더를 응답에 첨부할 수 있다

  (2) Cache-Control: no-cache 헤더를 응답에 첨부할 수 있다

  (3) Cache-Control: must-revalidate 헤더를 응답에 첨부할 수 있다

  (4) Cache-Control: max-age 헤더를 응답에 첨부할 수 있다

  (5) Expires 날짜 헤더를 응답에 첨부할 수 있다

  (6) 아무 만료 정보도 주지 않고, 캐시가 스스로 체험적인(휴리스틱) 방법으로 결정하게 할 수 있다.