Web Cache: 두 판 사이의 차이
| 40번째 줄: | 40번째 줄: | ||
<pre> | <pre> | ||
total delay = Internet delay + access delay + LAN delay | total delay = Internet delay + access delay + LAN delay | ||
= 2sec + msecs + usecs < | = 2sec + msecs + usecs</pre> | ||
즉, access link의 bandwidth 확장은 이를 해결할 수 있는 해결책 중 하나이다. 몇 분간의 딜레이가 약 2초 정도로 줄어들었기 때문이다. 하지만 이러한 해결책은 자금이 천문학적으로 많이 든다는 문제가 있다. | |||
2. Local Cache의 설치 | |||
보수적으로, cache hit rate를 잡으면 약 40% 정도이다. | |||
<ref>cache hit rate란 client가 web cache에 object를 요청했을 때 해당 object가 web cache에 저장되어 있을 확률이다.</ref> | |||
따라서 약 40%의 request는 cache에서 처리되며, 약 60%의 request는 origin server에서 처리된다. 이 경우에, access link의 bandwidth는 평소의 약 60%만 사용된다. | |||
<ref>traffic intensity = 0.6*(15requests/sec)*(1Mbits/requests)/(15Mbps) = 60%</ref> | |||
이러한 경우, total delay는 다음과 같이 결정된다.<ref>약간의 delay는 0.01초로 간주한다.</ref> | |||
<pre> | |||
total delay = 0.6 * (delay from origin server) + 0.4 * (delay when satisfied at cache) | |||
= 0.6 * 2.01 + 0.4(msecs) = 약 1.2secs</pre> | |||
이를 통해서 ISP가 access link의 bandwidth를 150Mbps로 확장했을 때보다 더욱 빠를 뿐만 아니라, 더욱 싸다는 결론을 내릴 수 있다. | |||
==각주== | ==각주== | ||
[[분류:컴퓨터 네트워크]] | [[분류:컴퓨터 네트워크]] | ||
2025년 3월 21일 (금) 15:54 판
상위 문서: Application Layer
개요
Web Cache(Proxy server라고도 한다.)는 origin web server를 거치지 않고로 client의 HTTP request를 처리하기 위해서 사용된다. 유저는 기본적으로 Web에 cache를 통해서 접근한다. 이때 Web cache는 자체적인 data storage space를 가지고 있어 최근에 요청된 object들의 복사본들을 해당 space에 저장한다. 사용자는 모든 request를 기본적으로 Web cache가 존재한다면 origin server가 아닌 web cache에 전송한다. 이때 Web cache는 다음과 같이 작동한다.
- browser는 Web cache와 TCP 연결을 설정하고 해당 객체에 대한 HTTP 요청을 Web cache에 보낸다.
- 유저가 request한 object가 해당 cache의 저장공간에 존재한다면 cache는 request받은 object를 client에 전송한다.
- .1. 만약 cache에 request받은 object가 존재하지 않는다면, cache는 origin server와 TCP 연결을 설정한다. 해당 연결을 통해 web cache는 origin server에 해당 object에 대한 HTTP request message를 보낸다. origin server는 해당 request를 받고 HTTP response message를 통해서 object를 web cache에 보낸다.
- .2. Web cache는 object를 받고, 해당 object를 자신의 data storage space에 저장하고 HTTP response message를 통해서 browser에 object를 전송한다.
작동 과정에서 알 수 있듯이, Web cache는 client와 server의 기능을 동시에 수행한다. 또한 이러한 web cache는 보통 ISP에 의해서 설치된다.
Web cache의 장점
ISP가 추가적인 비용을 들여서 web cache를 설치하는 이유는 다음과 같다.
- client request에 대한 응답 시간을 상당히 줄일 수 있다.
- server와 전체 네트워크에 가해지는 traffic을 상당히 줄일 수 있다.
- 무엇보다, 비용이 저렴하다.
Web cache 예시
다음과 같은 상황을 가정해보자.
- request하는 평균 object 크기: 1Mbits
- LAN의 bandwidth: 100Mbps
- browser에서 origin server로의 평균 request rate: 15requests/sec
- institutional router에서 origin server까지의 RTT: 2sec
- access link rate: 15Mbps
이러한 경우, LAN[1]의 bandwidth는 단 15%만 사용된다. [2] 하지만, access link의 bandwidth는 99%가 사용된다. [3] 이러한 경우, total delay는 다음과 같이 결정된다.
total delay = Internet delay + access delay + LAN delay
= 2sec + minutes + usecs
이 경우, RTT에 의해서 생기는 Internet delay나 LAN에서 발생하는 delay는 사실상 무시되고 total delay는 거의 access delay에 의해서 결정된다. access delay는 institutional router와 origin server를 연결하는 access link가 bottleneck link로 작동하기 때문에 발생한다. 이러한 문제를 해결하는 방법은 두가지가 있다.
1. ISP가 access link의 bandwidth를 150Mbps로 확장한다. 이 경우, access link의 bandwidth는 10%가 사용된다. 따라서 total delay는 다음과 같이 결정된다.
total delay = Internet delay + access delay + LAN delay
= 2sec + msecs + usecs
즉, access link의 bandwidth 확장은 이를 해결할 수 있는 해결책 중 하나이다. 몇 분간의 딜레이가 약 2초 정도로 줄어들었기 때문이다. 하지만 이러한 해결책은 자금이 천문학적으로 많이 든다는 문제가 있다.
2. Local Cache의 설치 보수적으로, cache hit rate를 잡으면 약 40% 정도이다. [4] 따라서 약 40%의 request는 cache에서 처리되며, 약 60%의 request는 origin server에서 처리된다. 이 경우에, access link의 bandwidth는 평소의 약 60%만 사용된다. [5] 이러한 경우, total delay는 다음과 같이 결정된다.[6]
total delay = 0.6 * (delay from origin server) + 0.4 * (delay when satisfied at cache)
= 0.6 * 2.01 + 0.4(msecs) = 약 1.2secs
이를 통해서 ISP가 access link의 bandwidth를 150Mbps로 확장했을 때보다 더욱 빠를 뿐만 아니라, 더욱 싸다는 결론을 내릴 수 있다.
각주
- ↑ 근거리 네트워크를 의미한다.
- ↑ traffic intensity = (15requests/sec)*(1Mbits/requests)/(100Mbps) = 15%
- ↑ traffic intensity = (15requests/sec)*(1Mbits/requests)/(15Mbps) = 100%
- ↑ cache hit rate란 client가 web cache에 object를 요청했을 때 해당 object가 web cache에 저장되어 있을 확률이다.
- ↑ traffic intensity = 0.6*(15requests/sec)*(1Mbits/requests)/(15Mbps) = 60%
- ↑ 약간의 delay는 0.01초로 간주한다.
