•
웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치
•
웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면, 문서는 원 서버가 아닌 캐시로부터 제공됨
•
캐시의 이점
◦
캐시는 불필요한 데이터 전송을 줄여, 네트워크 요금으로 인한 비용을 줄여줌
◦
캐시는 네트워크 병목을 줄여줌으로써, 대역폭을 늘리지 않고도 페이지를 빠르게 불러 올 수 있음
◦
캐시는 원 서버에 대한 요청을 줄여줌
◦
캐시는 거리로 인한 지연을 줄여줌
7.1 불필요한 데이터 전송
•
여러 클라이언트가 원 서버의 특정 페이지에 자주 요청할 때, 원 서버는 클라이언트에게 각각 한 번씩 전송하게됨
⇒ 똑같은 데이터들이 네트워크를 통해 반복해서 이동함
⇒ 불필요한 데이터 전송은 값비싼 네트워크 대역폭을 잡아먹음
⇒ 다수의 요청으로 인해 전송을 느리게 만들고 웹 서버에 부하를 줌
•
캐시는 서버의 첫 번째 응답을 서버에게 요청한 후 응답의 사본을 저장
•
뒤이은 요청들에 대한 응답으로 캐시된 사본을 반환
•
원 서버가 중복해서 트래픽을 주고받는 낭비가 줄어들게 됨
7.2 대역폭 병목
•
일반적으로 원격 서버보다 로컬 네트워크 클라이언트에 더 넢은 대역폭을 제공함
그림 7-1 캐시는 광역 통신망의 제한된 대역폭으로 인한 병목을 개선할 수 있다.
•
클라이언트들이 서버에 접근할 때의 속도는, 그 경로에 있는 가장 느린 네트워크 속도와 같음
⇒ 네트워크 병목
•
캐시를 LAN에 위치시킴으로써, 네트워크 병목 문제를 해결하고 성능을 대폭 개선할 수 있음
◦
특히 큰 문서들에 대하여 더 그러함
[참고자료] 대역폭 별 전송 시간
7.3 갑작스런 요청 쇄도(Flash Crowds)
•
많은 클라이언트들이 거의 동시에 웹 자원에 접근할 때 요청 쇄도(flash crowds)가 발생함
•
이 결과로 초래된 불필요한 트래픽 급증은 네트워크와 웹 서버의 심각한 장애를 야기함
7.4 거리로 인한 지연
•
모든 네트워크 라우터는 제각각 인터넷 트랙픽을 지연시킴
클라이언트와 서버 사이에 라우터가 많지 않더라도, 빛의 속도 그 자체가 지연을 유발함
•
복잡한 웹페이지들은 빛의 속도로 인한 지연이 수 초에 달할 수도 있음
7.5 적중과 부적중
그림 7-4 캐시 적중, 부적중, 재검사
•
캐시에 요청이 도착했을 때, 만약 그에 대응하는 사본이 있다면 ⇒ 캐시 적중(cache hit)
•
만약 대응하는 사본이 없다면 원 서버로 요청이 전달됨 ⇒ 캐시 부적중(cache miss)
7.5.1 재검사(Revalidation)
•
원 서버의 자원은 변경될 수 있기 때문에, 캐시는 사본이 최신인지 점검할 필요가 있음
•
이러한 '신선도 검사'를 HTTP 재검사라고 부름(그림 7-4c)
•
대부분의 캐시는 사용자가 요청한 사본이 검사할 필요가 있을 정도로 오래된 경우에만 재검사를 진행
•
원 서버는 재검사 요청에 대하여 자원이 변경되지 않았다면 304 Not Modified 응답을 보냄
•
사본이 여전히 유효함을 인식한 캐시는 사본이 신선하다고 다시 표시한 후, 그 사본을 클라이언트에게 제공(그림 7-5a) ⇒ 재검사 적중 혹은 느린 적중
•
재검사 적중은
◦
캐시 적중 보다는 느림. 원 서버에 검사할 필요가 있기 때문
◦
캐시 부적중 보다는 빠름. 서버로부터 객체 데이터를 받아올 필요가 없기 때문
그림 7-5 성공적인 재검사는 캐시 부적중보다 빠르다. 실패한 재검사는 부적중과 거의 같다.
•
HTTP에서 캐시된 객체를 재확인하기 위해 보통 If-Modified-Since 헤더를 사용
•
서버에게 보내는 GET 요청에 이 헤더를 추가하면 특정 시간(캐시된 시간) 이후에 변경된 경우에만 사본을 보내달라는 의미
•
다음은 If-Modified-Since 요청이 서버에 도착했을 때 일어날 수 있는 세가지 상황임
◦
재검사 적중(자원이 변경되지 않은 경우)
만약 서버의 자원(객체)가 변경되지 않았다면, 서버는 클라이언트에게 작은 304 Not Modified 응답을 보냄
그림 7-6 HTTP는 재검사를 위해 If-Modified-Since 헤더를 사용한다.
◦
재검사 부적중(자원이 변경된 경우)
만약 서버의 자원이 캐시된 사본과 다르다면, 서버는 자원과 함께 200 OK 응답을 클라이언트에게 보냄
◦
객체 삭제(자원이 삭제된 경우)
만약 서버 객체가 삭제되었다면, 서버는 404 Not Found 응답을 돌려보내며, 캐시는 사본을 삭제함
7.5.2 적중률
•
캐시가 요청을 처리하는 비율을 캐시 적중률 혹은 문서 적중률이라고 부름
•
캐시는 유용한 자원이 캐시 안에 머무르도록 보장하기 위해 노력함
재검사 적중을 캐시 적중률에 포함시키기도 하지만, 대개 적중률과 재검사 적중률은 별도로 측정된다. 캐시 적중률을 검증할 때는, 무엇을 '적중'으로 치는지 정확히 알고 있어야한다.
7.5.3 바이트 적중률
•
문서들의 크기가 모두 같지 않기 때문에, 문서 적중률이 모든 것을 말해주는 것은 아님
•
몇몇 큰 자원들은 비교적 덜 접근되지만 크기 때문에 전체 트래픽에는 더 크게 영향을 줌
•
바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 의미함
•
문서 적중률과 바이트 단위 적중률은 둘 다 캐시 성능에 대한 유용한 지표임
•
문서 적중률은 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지를 보여줌
⇒ 문서 적중률을 개선하면 전체 대기시간(지연)이 줄어듬
•
바이트 단위 적중률은 얼마나 많은 바이트가 인터넷으로 나가지 않았는지를 보여줌
⇒ 바이트 단위 적중률을 개선하면 대역폭을 절약할 수 있음
7.6 캐시 토폴로지
•
캐시는 한 명의 사용자에게만 할당될 수도 있고 반대로 수천 명의 사용자들 간에 공유될 수도 있음
•
한 명에게만 할당된 캐시를 개인 전용 캐시(private cache)라고 부름
⇒ 개인만을 위한 캐시이므로, 한 명의 사용자가 자주 찾는 페이지를 담음
•
여러 사용자에게 공유된 캐시는 공용 캐시(public cache)라고 부름
⇒ 공용 캐시는 사용자 집단이 자주 사용하는 페이지를 담음
7.6.1 개인 전용 캐시
그림 7-7 공용 캐시와 개인 전용 캐시
•
개인 전용 캐시는 많은 에너지나 저장 공간을 필요로 하지 않음
•
웹브라우저는 개인 전용 캐시를 내장하고 있음
7.6.2 공용 프록시 캐시
•
공용 캐시는 캐시 프록시 서버 혹은 프록시 캐시라고 불리는 공유된 프록시
•
프록시 캐시는 로컬 캐시에서 문서를 제공하거나, 혹은 클라이언트 입장에서 서버에 접근함
•
공용 캐시에는 여러 사용자가 접근하기 때문에, 불필요한 트래픽을 줄일 수 있는 기회가 더 많음
공용 캐시는 사용자 집단의 다양한 관심사들을 캐시하기 때문에, 캐시가 보관하고 있는 문서들이 특정 개인의 관심사에 의해 지워지는 일이 없도록 충분히 클 필요가 있다.
•
공용 캐시는 자주 찾는 객체를 단 한 번만 가져와 모든 요청에 대해 공유된 사본을 제공함으로써 네트워크 트래픽을 줄일 수 있음
그림 7-8 공유된 공용 캐시는 네트워크 트래픽을 줄인다.
7.6.3 프록시 캐시 계층들
•
작은 캐시에서 캐시 부적중이 발생했을 때, 부모 캐시가 '걸러 남겨진' 트래픽을 처리하는 방식이 합리적인 경우가 많음
•
아래의 그림은 두 단계의 캐시 계층을 보여줌
클라이언트가 브라우저 캐시를 가지고 있는 브라우저라면, 아래의 그림은 엄밀히 말하면 세 단계의 캐시 계층을 보여주고 있다.
그림 7-9 두 단계 캐시 계층으로 문서에 접근하기.
•
대부분의 요청들이 1단계 캐시에서 적중을 얻는다면 다행일 테지만(그림 7-9a),
•
그렇지 못했다면 더 큰 부모 캐시가 사용자의 요청을 처리할 수 있음(그림 7-9b)
부모 캐시는 관심사가 제각각인 다수의 자식 캐시들로부터의 트래픽을 모두 감당해야 하므로, 더 크고 더 고성능이어야 할 것이다.
7.7 캐시 처리 단계
그림 7-12 캐시 GET 요청 플로우 차트
