프록시 서버
- 웹 캐시의 일종이다.
- 요청을 본 서버에 가지 않고 처리
- 프록시 서버에 캐싱된 것을 응답으로 보내 빠르게 처리하는 것이 목적이다.
예시
본 서버에 요청을 하였고 중간에 프록시 서버를 거쳐간다고 할 때 프록시 서버에 원하는 자원이
캐싱되어 있다면
원 서버로 가지 않고 프록시 서버가 대신 응답을 해준다.
캐싱되어 있지 않다면
프록시 서버가 원 서버에 요청하고
원 서버로부터 응답을 받고 캐싱을 한 다음
응답으로 받은 것을 클라이언트에게 응답으로 준다.
이후 같은 것을 요청하면 캐싱이되어 빠르게 응답을 받을 수 있다.
장점
- 지연시간을 줄일 수 있다.
- 본 서버로 가는 트래픽을 줄일 수 있다.
- 본 서버의 로드가 줄어든다.
단점
- 오래된 버전의 자원을 받을 수도 있다.
- 본 서버의 데이터가 바뀌면 프록시 서버를 업데이트 해야하는데 이는 시간이 걸린다.
- 업데이트 완료 이전에 누군가 요청하면 프록시 서버는 최신 버전이 아닌 캐싱된 자원을 클라이언트에게 줄 수도 있다.
로컬 웹 캐시
두 네트워크 사이의 접근 링크에 병목이 생긴 경우 로컬 웹 캐시를 만들어 접근 링크를 지나는 트래픽 양을 줄여 지연 시간을 줄일 수 있다. 또한 직접 링크를 설치하는 것보다 훨씬 싸다.
예시
전제 조건
- 접근 링크 대역폭 : 1.54Mbps
- LAN 대역폭 : 1Gbps
- institutional 네트워크의 관문 라우터부터 서버까지의 rtt : 2초
- 웹 객체의 크기 : 100k 비트
- 평균 요청 수 : 초당 15개
- 평균적으로 클라이언트에게 오는 데이터 양 : 1.5Mbps
- 접근 링크가 한개이니 접근 링크를 지나가는 데이터 양이라 생각할 수 있다.
분석
로컬 웹 캐시 도입 전
랜 이용률
= 초당 랜에 들어오는 비트양 / 랜의 용량
= 초당 요청 수 한 객체의 크기 / 랜의 용량
= (15개 / 초) 100000 비트 * (1000000000 비트 / 초)
= 0.0015
= 0.15 %
접근 링크 이용률
= 초당 접근 링크에 들어오는 비트양 / 접근 링크 용량
= 1.5 Mbps / 1.54Mbps
= 0.97
= 97%
총 지연 시간
= 인터넷을 타고 서버에서 관문 라우터까지 왔다 갔다 하는 시간 + 접근 링크를 타고 건너오는 시간 + 랜을 타고 클라이언트로 오는 시간
= 2초 + 몇분 + 매우 짧음
접근 링크에서 병목이 일어나니 라우터에서 큐잉이 일어나고 이용률이 거의 97퍼이니 큐일 시간도 크다 따라서 접근 링크를 타고 건너오는데 오랜 시간이 걸린다.
랜은 널널하니 거의 안 걸린다.
로컬 웹 캐시 도입 후
- 캐시 히트 확률 = 0.4
- 평균적으로 클라이언트에게 오는 데이터 양 = 1.5 * 0.6 Mbps = 0.9 Mbps
- 왜냐하면 원래 가던 양의 40프로는 캐싱되어 서버로 가지 않을 것이니 원래보다 40프로가 줄어든다.
- 접근 링크 이용률
= 0.9 Mbps / 1.54 Mbps
= 0.58
= 58%
트래픽이 줄었으니 큐잉 시간도 줄어든다.
관문 라우터에서 서버까지 왔다갔다 하고 큐잉되는 시간을 rtt + 큐잉시간 + 랜 타고 클라이언트에게 오는 시간하여 약 2.01초라 하고
캐싱되어 로컬 캐시에게 응답을 받는데 걸리는 시간은 매우 작은 값이라고 하면 무시 가능
따라서 평균 딜레이는 아래와 같다
= 캐싱 안될 확률 * 캐싱 안 되었을 때 걸리는 시간 + 캐싱될 확률 * 캐싱 되었을 때 걸리는 시간
= 0.6 2.01 + 0.4 아주 작은 값
= 1.2 초
확실히 지연시간이 감소하는 것을 확인할 수 있다.
조건부 캐시
- 브라우저가 처음 요청한 자원을 브라우저 캐시에 저장한다고 할 때
- 캐싱된 것을다음에 또 요청하면 if-modified-since 헤더를 붙여서 보낸다.
- 이 헤더는 클라이언트가 마지막으로 캐시를 업데이트한 시간을 말한다.
서버가 받았는데
요청한 자원이 헤더에 적힌 시간 이후에 바뀌었으면
- 응답 메세지 바디에 요청 데이터를 넣고
- 200번 응답을 한다.
바뀌지 않았다면
- 메세지 바디에 아무것도 넣지 않고
- 304 응답을 한다
- 메세지 바디가 없으니 훨씬 빠르다
- 클라이언트는 캐싱된 자원을 그대로 사용하면 된다.
