Cache

---

본 내용은 HTTP 완벽가이드 도서를 통한 학습과정을 기록한 글입니다. 개인적인 공부를 위해 남기는 목적이기에 내용상에 오류가 있을 수 있습니다. 잘못된 내용이 있다면 주저하지 마시고 알려주시면 감사드리겠습니다.

---

1. Cache

웹 캐시는 자주 쓰이는 리소스들의 사본을 자동으로 보관하는 HTTP 장치이다. 웹 요청이 캐시에 도착했을 때 캐시 된 리소스가 존재한다면 해당 요청에 대한 리소스는 원 서버가 아니라 캐시로부터 제공된다. 이처럼 캐시는 원 서버에 대한 부하를 줄여줄 수 있으며, 더 빨리 응답할 수 있도록 해주는 장점이 있다. 몇 가지 장점을 더 살펴보자면 다음과 같다.

- 캐시는 불필요한 데이터 전송을 줄여 네트워크 비용을 줄여준다.

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

- 페이지를 먼 곳에서 불러오면 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다.

- 캐시는 원 서버에 대한 요청을 줄여 부하를 중리고 더 빨리 응답할 수 있게 해 준다.

 

---

2. 불필요한 데이터 전송

복수의 클라이언트가 자주 쓰이는 원 서버의 페이지에 접근할 때, 서버는 같은 문서를 클라이언트들에게 각각 한 번씩 전송하는 비효율적인 일을 한다. 따라서 원 서버가 중복해서 트래픽을 주고받는 낭비와 부하를 줄이기 위하여 캐시를 이용한다.

---

3. 프록시와 게이트웨이의 차이점?

프록시는 같은 프로토콜을 사용하는 둘 이상의 어플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다. 게이트웨이는 클라이언트와 서버가 서로 다른 프로토콜로 말하더라도 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 작동한다. 하지만 실질적으로 프록시와 게이트웨이의 차이점은 모호하다. 브라우저와 서버는 다른 버전의 HTTP를 구현하기에 프록시는 때때로 약간의 프로토콜 변환을 한다. 또한 상용 프록시 서버는 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근 등을 지원하기 위해 게이트웨이 기능을 구현한다.

---

4. 대역폭 병목

캐시는 WAN(광역 통신망)의 제한된 대역폭으로 인한 병목을 개선할 수 있다. 만약 클라이언트가 더 넓은 대역폭을 가지고 빠른 속도의 LAN에 있는 캐시로부터 사본을 가져온다면 캐싱의 성능은 대폭 개선된다. 문서의 크기가 작다면 성능 개선이 미미하겠지만 큰 용량의 문서에 대해서는 현저한 영향을 미친다.

---

5. 갑작스런 요청 쇄도

갑작스러운 사건으로 인해 많은 사람이 거의 동시에 웹에 전근하면 웹 서버와 네트워크에 심각한 장애를 야기한다. 이에 캐싱을 통해 갑작스러운 요청 쇄도에 대처하는 방법이 중요하다.

---

6. 적중과 부적중

캐시의 메모리도 유한하기에 세상 모든 문서의 사본을 저장하지 않는다. 캐시에 요청이 왔을 때, 만약 그에 대응하는 사본이 있다면 요청이 처리된다. 이를 캐시 적중(Cache Hit)이라고 부른다. 만약 대응하는 사본이 없다면 그냥 원 서버로 전달되기만 할 뿐이다. 이것을 캐시 부적중(Cache Miss)라고 부른다.

6-1. 재검사(Revalidation)

원 서버 콘텐츠는 변경될 수 있기 때문에 캐시는 반드시 그들이 갖고 있는 사본이 여전히 최신인지 서버를 통해 점검해야 한다. 이러한 신선도 검사를 HTTP 재검사라 부른다. 캐시는 캐시된 사본의 재검사가 필요할 때 원 서버에 작은 재검사 요청을 보낸다. 그 사본이 여전히 유효하다면 캐시는 즉각 사본이 신선하다고 임시로 다시 표시한 뒤 그 사본을 클라이언트에 제공한다. 이를 재검사 적중 혹은 느린 적중이라고 한다. 하지만 이것은 순수 캐시 적중보다는 느린 단점이 있지만 최신 유지를 위해 필요하다.

 

HTTP는 캐시된 객체를 확인하기 위해 If-Modified-Since 헤더를 제공한다. 만약 서버 객체가 변경되지 않았다면 서버는 클라이언트에게 HTTP 304 Not Modified 응답을 보낸다. 다를 경우에는 HTTP 200 Ok 응답을 보낸다. 또한 서버 객체가 삭제될 경우에는 404 Not Found 응답을 보낸다.

6-2. 적중률

캐시가 요청을 처리하는 비율을 캐시 적중률, 혹은 문서 적중률이라고 부른다. 적중률은 0에서 1까지 값으로 되어 있으나 흔히 퍼센트로 표현되기도 한다. 실제 적중률은 캐시가 얼마나 큰지, 캐시 사용자들의 관심사가 얼마나 비슷한지, 캐시된 데이터가 얼마나 자주 변경되거나 개인화되는지, 캐시가 어떻게 설정되어 있는지에 달려있다. 적중률은 예측하기 어려운 것으로 악명이 높지만 오늘날 적중률 40%면 웹 캐시로 괜찮은 편이다.

 

하지만 문서들이 다 같은 크기가 아니기에 문서 적중률만으로는 판단하기 어렵다. 이에 바이트 단위 적중률도 존재한다. 문서 적중률이나 바이트 단위 적중률은 둘 다 캐시 성능에 대한 유용한 지표이다. 문서 적중률은 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지 계산하며 전체 지연시간을 최적화한다. 바이트 단위 적중률은 얼마나 많은 바이트가 인터넷으로 나가지 않았는지를 보여주며 대역폭 절약을 최적화한다.

* HTTP 응답이 캐시 적중인지 아닌지의 파악은 클라이언트 응답의 Date 헤더의 시각과 현재 시각을 비교하여 알 수 있다. 또한, Age 헤더를 이용하는 것도 방법이다.

---

7. 캐시 토폴로지

7-1. 개인 전용 캐시

개인 전용 캐시는 많은 에너지나 저장 공간을 필요로 하지 않으므로 작고 저렴할 수 있다. 웹 브라우저의 대부분은 개인 전용 캐시를 내장하고 있다. 대부분의 브라우저는 자주 스이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓는다.

7-2. 공용 프록시 캐시

공용 캐시는 여러 사용자가 접근하기 때문에 불필요한 트래픽을 줄일 기회가 많다. 또한 자주 찾는 객체를 단 한 번만 가져와 모든 요청에 대해 공유된 사본을 제공함으로써 네트워크 트래픽을 줄인다.

7-3. 프록시 캐시 계층들

여러 개의 캐시를 계층화해 사용하는 것이 합리적일 때가 많다. 클라이언트 주위에는 작고 저렴한 캐시를 사용하고, 계층 상단에는 많은 사용자들에 의해 공유되는 문서를 유지하기 위해 더 크고 강력한 캐시를 사용하여 효율적으로 운용할 수 있다. 하지만 캐시 계층이 깊어질수록 현저한 성능 저하가 발생될 수 있으므로 이를 유념한 설계가 이루어져야 한다

* 미래에는 계층 연쇄의 길이가 문제되지 않는 방향으로 발전될 것이다.

 

캐시 계층 구조

---

8. 캐시 처리 단계

웹 캐시의 기본적인 동작은 7 단계로 이루어져 있다.

 

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

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

검색 : 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아온 후 로컬에 저장한다.

신선도 검사 : 캐시는 캐시된 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사향이 있는지 서버에 물어본다.

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

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

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