[HTTP 프로토콜 강좌]#8 캐시서버(Cache Servers)

오늘 포스팅할 주제는 웹캐시서버(Web Cache Servers) 이다.
"Cache"의 사전적 의미는 저장소라고 한다.

웹브라우저에 보면 "캐시파일" 이라고 있는데, 브라우저에서 저장하고 있는 내용을 보면 이미지,css,js 등의 파일들이다.
흔히 웹페이지에서 서비스하고 있는 컨텐츠들인데.. 이는 웹페이지의 로딩속도를 좀 더 빠르게 하기 위해 사용되어진다.

캐시파일이 어떻게 사용되는지는 이번 포스팅의 내용을 주의 깊게 보시면 이해하는데 도움이 될 것이다.

웹 캐시 서버(Web Cache Server)란?

웹 캐시 서버는 프록시서버의 한 형태라고 할수 있다. 웹 캐시 서버는 클라이언트가 요청한 컨텐츠들을 기억하고 있다가 어느 한 클라이언트(동일사용자 일수도 있고, 다른 사용자일수도 있는)가 웹 캐시 서버가 기억하고 있는 동일한 컨텐츠를 또 다시 요청하는 경우 이를 직접 응답하여 웹 서버의 부하를 절감시켜 주는 역할을 한다.

아래 두개의 그림으로 동작을 이해하면 좋겠다.

먼저 첫번째..
어느 클라이언트가 웹 서버의 특정 컨텐츠(twice.jpg)를 최초로 요청한 경우의 동작이다.
(요즘은 트와이스가 대세!~~~ _

위 동작 방식에서 볼수 있듯이 웹 캐시 서버의 동작 흐름이 프록시 서버와 같은 것을 볼수 있다.  프록시 동작이 기본이기 때문에 프록시 서버의 특별한 하나의 형태라고 부른다.

웹 캐시 서버 역시 클라이언트에게는 웹서버의 역할을 대신 수행하고, 웹 서버에게는 클라이언트의 역할을 대신 수행하는 중계자가 된다.

프록시와 차이점이 있다면 실제 서버에서 응답해준 컨텐츠를 웹 캐시 서버는 자신의 디스크나 메모리에 저장한 후 클라이언트에게 제공한다는 것이다. (바로 이부분이 웹 캐시 서버의 핵심! 이라 할 수 있다.)

다음 두번째..
같은 클라이언트 또는 다른 클라이언트가 웹 캐시 서버에서 저장된 동일한 컨텐츠를 요청하는 경우 (보통 같은 웹사이트를 접속하는 경우가 되겠지요..) 의 동작 흐름이다.

그림에서와 같이 트와이스 이미지(twice.jpg)를 다시 요청하는 경우, 웹 캐시 서버는 이를 직접 클라이언트에게 응답하게 된다.
실제 서버로 요청이 전달되지 않기 때문에 실제 서버 측면에서는 부담이 줄어든다.





웹 캐시 서버의 고민 거리

이처럼 웹서버 측면에서 보면, 웹 캐시 서버라는 녀석이 대단히 좋은 녀석이긴 하다.
하지만, 항상 좋은 녀석은 아니다. 때로는 실제 웹서버를 괴롭히기도 한다.

예를 들어..
웹 캐시서버와 웹서버가 정상적으로 아무 문제 없이 서비스를 훌륭하게 하고 있었다고 가정하고..
어느날 웹 개발자가 겨울이 되었으니 여름옷을 입은 트와이스의 이미지를 겨울 복장의 이미지로 바꾸게 되었다. 하지만, 미쳐 이 내용을 웹 캐시 서버에게 알리진 못했다.
이 경우 클라이언트들이 요청한 twice.jpg 의 내용은 어땠을까?

그렇다. 실제 웹서버에서 서비스 이미지를 변경했으나 클라이언트에게는 이 내용이 반영되지 않게 된다. 서비스 장애라고 할 수 있다.

이처럼 웹 캐시 서버는 자신이 메모리나 디스크에 저장한 컨텐츠가 유효한지 아닌지를 체크해야 하는 숙제가 있다.

웹 캐시 서버 제품별로 컨텐츠가 유효한지 아닌지를 체크하는 알고리즘이 있고, 이를 계산할 수 있게 HTTP 헤더에 관련 정보들이 존재 한다.

뭐.. 헤더 관련해서 자세한 내용은 이후 포스팅에서 HTTP 헤더 정보를 다룰때 소개하기로 한다.

여기서는 웹 캐시 서버가 하는 역할, 그리고 캐시 서버의 고민거리 정도만 알고 넘어가면 좋겠다.

오늘 내용을 좀 정리해 본다.

1. 웹 캐시는 프록시 서버와 동작 방식이 같다. 클라이언트와 서버 중간에 위치하여 요청과 응답에 대한 중간 대리인 역할을 한다. 
2. 프록시 동작 외에 서버가 응답한 컨텐츠를 직접 저장하고 이후 동일한 요청에 대해 직접 응답함으로써 웹서버의 부담을 줄인다.

끝~