[컴퓨터 네트워크] 10. Application Layer (3) : Web Cache

Web Cache (web proxy / proxy server)

웹 브라우저의 역할은 웹 서버로부터 웹 오브젝을 가져오는 것이다.

그런데 만약 서버가 클라이언트로부터 멀리 떨어져 있거나, 대역폭이 넓지 않아서 오브젝을 가져오는데 시간이 오래 걸린다면, 서버까지 가지 않고도 데이터를 얻어올 수 있는 웹 캐시 기법을 사용할 수 있다.

 

웹 캐시 기법은 클라이언트가 자주 요청할 법한 오브젝을 클라이언트 가까이에 두는 기법이다.

그래서 만약 사용자가 로컬 웹 캐시에 먼저 접근하도록 설정하면, 오브젝을 가져올 때 서버에 바로 요청을 보내는 것이 아니라, 웹 캐시에 데이터를 요청해서 받아온다.

만약 웹 캐시에 오브젝이 없다면 그때 서버에 오브젝을 요청해서 오브젝을 가져온 뒤, 캐시가 그 오브젝의 카피를 따로 저장해두고, 클라이언트에게 오브젝을 보내준다.

 

이렇게 구성하면 클라이언트 요청에 대한 response time 을 줄일 수 있고, origin server 로 가는 링크들의 트래픽을 줄이는 효과도 있다. 그리고 이렇게 웹 캐시가 클라이언트의 요청을 오리진 서버 앞에서 미리 받기 때문에 '프록시 서버' 라고도 한다.

웹 캐시는 클라이언트 요청을 받아 오브젝을 보내주므로 서버의 역할을 하는 동시에, 없는 오브젝을 오리진 서버에게 요청해야하기 때문에 클라이언트의 역할도 수행한다.

물론 이런 성능상 이점을 받으려면 클라이언트가 마침 캐싱된 데이터를 요청하는 비율인 hit ratio 가 높아야 한다.

 

만약 웹 캐시가 서버에게 캐싱할 데이터를 요청한다면, 서버는 response header 에 Cache-Control 헤더를 통해 이 데이터를 캐싱할 것인지, 캐싱한다면 얼마나 캐싱하도록 할 것인지 지정하여 웹 캐시가 적절한 기간동안 해당 오브젝을 캐싱하도록 할 수 있다.

 

Example

 

위 그림과 같은 구조로 네트워크가 형성되어 있다고 하자.

institutional network 에서 public Internet 에 있는 데이터를 가져올 때, 엑세스 링크의 대역폭이 1.54Mbps 이다.

그리고 RTT 는 2초라고 하자. (institutional router <-> server)

가져오는 웹 오브젝트의 크기는 100kbits 이다.

브라우저에서 origin server 로 요청을 보낼 때 평균 15개의 오브젝트를 요청한다고 하자.

 

그럼 하나의 오브젝트가 100kbits 이므로, 초당 평균 요청 bit 사이즈는 (100kbits / object) * (15 objects / sec) = 1500kbits / sec 이다. (단위를 바꾸면 1.50Mbps 라고 표현할 수 있다.)

 

그런데 엑세스링크의 대역폭은 1.54Mbps 로 초당 요청량이 대역폭의 거의 대부분을 차지한다.

이를 access link utilization 이라고 하여 구할 수 있는데, 1.50Mbps / 1.54Mbps = 0.97

즉 대역폭의 97%를 사용하고 있다.

그 경우, queueing 이론에서 정리했던 내용대로, 라우터의 queueing delay가 기하급수적으로 증가하게 된다.

반면 네트워크 사내 망의 대역폭은 1Gbps 이므로, LAN 내부의 unitilization 은 0.0015가 된다.

 

따라서 end to end delay 는 Internet delay + access link delay + LAN delay = 2sec + minutes + usec 의 시간이 걸린다.

(2초는 institutional router 에서 origin servers 로부터 데이터를 얻어오는 시간, minutes 엑세스 링크가 가득차서 그 링크를 통과하기까지 기다려야하는 queueing delay를 의미한다.  usec는 institution router 에 연결된 클라이언트와 라우터 사이 데이터 통신 delay 이다.)

따라서 중간에 있는 access link 하나의 대역폭이 좁은 문제 하나로 전체 end to end delay가 매우 증가하였음을 알 수 있다.

 

 

만약 중간에 있는 access link 의 대역폭을 100배 늘렸다고 하자.

그러면 access link를 통해 주고받는 access link utilization 은 100배 감소한 0.0097이 될 것이다.

이정도 시간은 msec 정도의 시간밖에 걸리지 않기 때문에 end to end delay 는 2sec + msecs + usecs = 2s 가 된다.

 

 

또 다른 대안으로는 웹 캐시를 institutional network에 추가하는 방법도 있다.

위 방법처럼 access link 의 대역폭을 늘리는 것은 확실한 해결방법이지만 돈이 많이 드는 방법이다.

 

이제 웹 캐시를 사용하는 경우, 시간이 얼마나 걸릴지 계산해보자.

이를 위해서는 클라이언트가 요청하는 웹 오브젝이 웹 캐시에 얼마나 저장되어있는지, 그 hit ratio가 중요하다.

이 hit rate 를 0.4 라고 하자.

그러면 40%의 오브젝트는 웹 캐시에서 가져오고, 나머지 60%의 데이터만 라우터를 거쳐 인터넷에서 얻어올 것이다.

 

그럼 기존 1.50Mbps 의 데이터 요청량이 0.6 * 1.50Mbps = 0.9Mbps 로 감소한다.

access link utilization 은 0.9 / 1.54 = 0.58 정도의 비율로 대폭 감소한다.

이 정도 비율이면 msec 시간 단위로 데이터를 얻어올 수 있다.

 

따라서 평균 end to end delay 는 0.6 * (delay from origin server) + 0.4 * (delay when satisfied at cache)

 = 0.6 * (2 sec) + 0.4 * (msec) = 1.2s

로컬 웹 캐시에서 데이터를 얻어오는 시간은 매우 빠르기 때문에 end to end 딜레이는 1.2초로 대폭 감소한다.

 

이 값은 대역폭을 확장하는 경우보다도 더 낮은 평균 딜레이값인 동시에 필요한 비용도 더 적다는 장점이 있다.

---

Browser Caching

이번엔 클라이언트인 브라우저가 자체적으로 캐싱하는 경우에 대해서 생각해보자.

이를 Conditional GET (조건부 GET) 이라고도 한다.

이 방식을 사용하면 클라이언트가 GET 요청을 보낼 때, 자신이 가진 오브젝트가 언제 갱신된 오브젝트인지 시간 정보를 If-modified-since 헤더에 포함해서 같이 보낸다. 이 헤더에 들어가는 값은 전에 응답받을 때 받았던 last-modified 헤더의 값을 통해 확인한 오브젝트 업데이트 시각 정보가 그대로 들어간다.

 

그러면 서버는 이 값을 보고 서버가 가진 오브젝트가 언제 마지막으로 갱신되었는지를 확인한 후에, 오브젝트가 갱신이 되었다면 그 때 바뀐 오브젝트를 다시 보내주고, 만약 갱신되지 않았다면 304 Not Modified 응답만 보낸다.

이 방식을 이용하면 브라우저가 최신 오브젝트를 갖고 있는 경우, 서버가 전체 오브젝트를 다시 보낼 필요가 없다.

따라서 네트워크 전체의 리소스가 절약되는 효과가 있다.