캐시(Cache)란 무엇인가?

캐시를 한 마디로 표현하면 웹에서 자주 쓰이는 리소스의 사본은 자동으로 보관하는 HTTP 장치이다.

 

캐시는 어떠한 이유로 나타나게 된 것일까?

먼저 캐시가 없는 보통의 환경을 생각해보자.

클라이언트가 여럿 존재하고 리소스를 가지고 있는 서버가 존재할 것이다.

여러 클라이언트가 자주 쓰는 페이지가 존재한다면 페이지에 접속할 때마다 항상 서버에 요청을 보내고 서버는 같은 리소스를 클라이언트들에게 매 번 보내야 된다.

똑같은 바이트들이 네트워크를 통해 전송이 이루어지면 네트워크 대역폭이 소모되고 웹 서버에 부하를 주게 된다.

이러한 점을 개선하기 위해 나온 것이 캐시이다.

클라이언트와 가까운 곳에 캐시를 두어 자주 요청되는 리소스의 사본을 저장하고 추후에 같은 요청에 대해서는 캐시에서 응답을 줄 수 있기 때문에 웹 서버가 중복해서 트래픽을 주고받는 낭비가 줄어들게 된다.

 

캐시가 나온 이유를 알게되었고 캐시로 인해 생긴 장점을 알게 되었다.

이외에 다른 캐시의 장점이 있을까?

캐시를 사용하게 되면 네트워크 병목을 줄여줄 수 있다.

대부분의 네트워크는 원격에 있는 웹 서버와의 연결보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공한다.

즉, 캐시를 클라이언트와 가까운 곳에 두어 LAN을 통해 리소스를 요청하고 가져올 수 있다면 웹 서버에서 가져오는 것에 비해 빠른 속도로 가져올 수 있게 되어 네트워크 병목을 줄여줄 수 있다.

 

다음 장점으로는 캐싱은 갑작스러운 요청 쇄도에 대처하는데 도움을 준다.

어떠한 사이트에서 특급 행사를 진행하여 사용자가 갑작스럽게 접속을 많이 하게 된다면 트래픽 급증으로 네트워크와 웹 서버의 심각한 장애를 야기시킬 수 있다. 캐시가 존재한다면 웹 서버에 대한 요청을 줄일 수 있어 대처에 도움을 줄 수 있다.

 

마지막으로 캐시를 두게 되면 거리로 인한 지연을 줄일 수 있다.

지연을 유발하는 데에는 네트워크의 대역폭에 따라 달라질 수 있지만 거리도 지연을 유발할 수 있다.

만약, 클라이언트와 서버의 거리가 매우 멀다면 그것 또한 지연 발생의 원인이 될 수 있으므로 클라이언트와 가까운 곳에 캐시를 둔다면 지연을 줄일 수 있게 된다.

 

이렇게 캐시는 많은 장점을 가지고 있다. 하지만 캐시는 모든 리소스의 사본을 가질 수 없다.

그리고 캐시에서 사본을 가지고 있는데 웹 서버에서 원본의 리소스가 변경될 수 있다.

이러한 경우에 어떻게 해야할까?

캐시는 자신이 갖고 있는 사본이 최신인지 아닌지 서버를 통해 점검을 하게 되고 이를 재검사(Revaildation)라 한다.

효과적인 재검사를 위해 HTTP는 서버로부터 전체 객체를 가져오지 않아도 콘텐츠가 최신인지 빠르게 검사할 수 있는 특별한 요청을 정의했다.

캐시가 재검사가 필요하다면 서버에게 작은 재검사 요청을 보내고 서버는 콘텐츠가 변경되지 않았다면 아주 작은 304 not Modified 응답을 보낸다.

만약 콘텐츠가 변경되었다면 서버는 변경된 콘텐츠와 함께 평범한 HTTP 200 OK응답을 보낸다.

또한 캐시가 보낸 재검사의 사본이 서버에서는 삭제된 콘텐츠일 수 있다. 이러한 경우에는 서버는 404 Not Found응답을 돌려보내고 캐시는 사본을 삭제한다.