Web Cache

상위 문서: Application Layer

개요

Clients requesting objects through a Web cache

FIgure 1. Clients requesting objects through a Web cache

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는 다음과 같이 작동한다.

1. browser는 Web cache와 TCP 연결을 설정하고 해당 객체에 대한 HTTP 요청을 Web cache에 보낸다.
2. 유저가 request한 object가 해당 cache의 저장공간에 존재한다면 cache는 request받은 object를 client에 전송한다.
3. .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에 보낸다.
4. .2. Web cache는 object를 받고, 해당 object를 자신의 data storage space에 저장하고 HTTP response message를 통해서 browser에 object를 전송한다.

작동 과정에서 알 수 있듯이, Web cache는 client와 server의 기능을 동시에 수행한다. 또한 이러한 web cache는 보통 ISP에 의해서 설치된다.

Web cache의 장점

Bottleneck between an institutional network and the Internet

Figure 2. Bottleneck between an institutional network and the Internet

ISP가 추가적인 비용을 들여서 web cache를 설치하는 이유는 다음과 같다.

1. client request에 대한 응답 시간을 상당히 줄일 수 있다.
2. server와 전체 네트워크에 가해지는 traffic을 상당히 줄일 수 있다.
3. 무엇보다, 비용이 저렴하다.

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의 bandwidth는 단 15%만 사용된다. 하지만, access link의 bandwidth는 99%가 사용된다. 이러한 경우, 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% 정도이다. 따라서 약 40%의 request는 cache에서 처리되며, 약 60%의 request는 origin server에서 처리된다. 이 경우에, access link의 bandwidth는 평소의 약 60%만 사용된다. 이러한 경우, total delay는 다음과 같이 결정된다.

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로 확장했을 때보다 더욱 빠를 뿐만 아니라, 더욱 싸다는 결론을 내릴 수 있다.

Conditional Get

Cache의 가장 큰 문제는 cache coherence이다. 이는 web cache에 저장된 정보가 origin server에서 바뀌더라도 web cache에 저장된 정보가 바뀌지 않을 수 있기 때문에 발생한다. 이렇게 바뀌지 않고 origin server와는 다른 정보는 out-of-date되었다고 한다. 이러한 문제를 해결하는 방식 중 하나는 일정 시간 마다, web cache에 저장된 정보를 통째로 모두 origin server에서 update하는 것이다. 이는 과거에 실제로 수행되었던 해결책이지만 너무 비효율적이라는 문제가 있다. 현재는 web cache가 저장한 객체가 out-of-date되었는지 확인하고, 만약 그럴 경우에만 update하는 식으로 이를 해결한다. 이때, HTTP에서 cache가 저장한 object가 최신 상태인지 확인하는 메커니즘을 Conditional GET이라고 한다.

HTTP request message가 Conditional GET message라고 불리기 위해서는 다음 두 가지 조건을 충족해야 한다:

• request message가 GET method를 사용해야 한다.
• request message에 'If-Modified-Since:' header line이 포함되어야 한다.

cache는 HTTP request를 통해서 object를 수신하고 이를 저장할 때, 그 정확한 시점(date)를 저장한다. cache는 다음과 같은 request 메시지를 보내서 확인하고자 하는 object가 out-of-date되었는지 확인한다.

GET /fruit/kiwi.gif HTTP/1.1  
Host: www.exotiquecuisine.com  
If-Modified-Since: Wed, 9 Sep 2015 09:23:24

위는 /fruit 파일에 저장된 kiwi.gif 파일이 저장된 origin server에 Wed, 9 Sep 2015 09:23:24 이후로 수정이 이루어졌는지를 물어보는 request message이다. origin server는 해당 object가 해당 date 이후로 변경되지 않았다면 다음과 같은 response message를 보낸다.

HTTP/1.1 304 Not Modified

위는 단순히 해당 object가 cache에 저장된 이후로 수정되지 않았음을 알려준다. 또한 origin server는 해당 object가 해당 date 이후로 변경되었다면 다음과 같은 response message를 보낸다.

HTTP/1.1 200 
<new data>

즉, 해당 객체가 out-of-date되었다면 server는 00 응답과 함께 새로운 Last-modified 정보가 담긴 객체를 전해준다.