2-2. Application-layer protocols(Web & HTTP)(2)

Web caches

 

 

Problem: HTTP 소통이 진행되다 보면 클라이언트에서 서버까지 갔다 오는 데 시간이 많이 걸릴 뿐더러 original server에게 많은 load가 부담될 수 있다.

 

Solution: institution들이 자신의 local site에 web cache(proxy server)를 두면, client가 보낸 request가 original server까지 전달되는 수고를 덜어준다. 

 

브라우저는 일단 original server가 아니라 web cache(proxy server)에 HTTP 요청을 보낸다.

if> 클라이언트의 브라우저가 요청한 object가 cache에 존재하면 클라이언트에게 바로 보내지만(server 역할)

else> cache에 존재하지 않는다면 origin server에게 object 요청해서 받은 후에 클라이언트에게 보내준다.(client 역할)

 

 

 

<Benefits>

- client와 proxy server의 거리가 가깝기 때문에 빠른 응답 가능

- original server에 연결되는 회선이 줄어 load 줄일 수 있음

=> 인터넷 성능 향상

 

<Drawbacks>

- 웹페이지가 변경되면, wep cache의 웹페이지와 original server의 웹페이지 내용이 달라져요..

 

 

Caching Motivation

 

다음과 같은 시나리오를 생각해보자.

 

- institutional network의 LAN 속도: 1Gbps

- Access link rate: 1.54Mbps

- RTT(Internet router에서 origin server까지): 2 sec

- Web object 평균 size: 100K bits

- 브라우저에서 origin server까지의 평균 요청 속도: 15/sec

- 브라우저까지의 평균 데이터 속도: 1.5Mbps(100K * 15/sec = 1500bps = 1.5Mbps)

 

다음과 같이 계산하면 된다.

 

- LAN 사용률: 0.0015(0.15%)

=> 데이터 속도/LAN 속도 = 1.5Mbps/1000Mbps = 0.0015

 

- Access link 사용률: 0.97(97%)

=> 데이터 속도/access link 속도 = 1.5Mbps/1.54Mbps = 0.97

 

- end-to-end delay

=> Internet delay + Access link delay(압도적으로 많은 비중 차지) + LAN delay

 

**Internet delay는 2초,

access link는 사용률이 높으므로 access link delay는 몇 분이 걸릴 것이고

LAN은 사용률이 낮으므로 LAN delay는 거의 없을 것이다.

=> Problem: access link delay가 주 원인이고, 이 delay는 access link를 건너는 데 걸리는 시간이 길기 때문에 발생한다.

 

 

(Solution 1) 더 빠른 속도의 access link로 교체한다.

 

access link 속도를 100배 해 1.54Mbps에서 154Mbps로 늘리면

access link delay는 0.97에서 0.0097로 줄어 거의 msec 단위가 된다.

 

 

 

하지만 비싸다.

 

(Solution 2) web cache를 두어 access link delay를 줄일 수 있다.

 

 

web cache는 값이 그렇게 비싸지 않기 때문에 좋은 대안이 될 수 있다.

 

패킷의 40%가 cache에 있고, 60%는 cache에 없어서 original server에서 가져와야 한다면

60%가 access link를 사용할 것이다.

 

**Total delay = 0.6 * (original server로부터의 delay) + 0.4 * (cache쓸 때의 delay)

= 0.6 * 2 + 0.4 * msec(무시 가능) = ~1.2 secs

 

이렇게 cache를 두면 더 적은 비용으로 access link delay를 더 많이 줄일 수 있다.

 

 

Conditional GET

 

하지만 웹페이지가 업데이트됐을 때 web cache와 origin server 간 차이가 문제가 된다고 언급한 바 있다.

그래서 클라이언트에게 cache에 있는 모든 객체가 업데이트 완료된 것이라고 확인시켜주는데 

이때 사용되는 것이 conditional GET이다.

 

conditional GET는 다음 두 가지 조건을 충족한다.

1. GET 방식 사용

2. 'If-modified-since <date>' 헤더라인 포함

 

 

과정

 

1. proxy server가 web(original) server로 요청 메시지를 보냄

GET /fruit/kifi.gif HTTP/1.1
Host: www.exotiquecuisine.com

 

 

2. web server가 객체를 가진 응답 메시지 보냄

HTTP/1.1 200 OK
Date: Sun, 13 Oct 2024 15:39:29
Server: Apache/1.3.0(Unix)
Last-modified: Sat, 12 Oct 2024 09:23:24
Content-type: image/gif

 

 

3. proxy server가 client에게 객체 보내주고 자신에게도 객체 및 마지막 수정 날짜 저장

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com 
If-modified-since: Sat, 12 Oct 2024 09:23:24

 

Last-modified의 시간과 If-modified-since의 시간이 같다는 것에 주목해야 한다.

3번 의 내용은.. Last-modified의 시간 이후에 수정된 것이 있을 경우에만 4번에서 그 객체를 보내라는 것이다.

 

4. 웹서버가 클라이언트에게 응답 메시지 보냄

 

<수정된 것이 없을 경우> => 웹페이지를 보내지 않는다.

HTTP/1.1 304 Not Modified
Date: Sat, 
Server: Apache/1.3.0 (Unix)

 

 

<수정된 것이 있을 경우> => <data>부분에 웹페이지 관련 정보 넣어줌

HTTP/1.0 200 OK
<data>

 

 

proxy 서버는 client에게는 server역할을, origin server에게는 client역할을 하기 때문에

client <-> proxy server

proxy server <-> origin server 

 

HTTP 버전 변화

 

HTTP 1.1

하나의 TCP 연결에서 다수의 GET이 가능하다.

Problem: Head-of-line(HOL)-작은 object이지만 큰 object 뒤에서 기다려야 함(FCFS: First-come-first-served)

 

=> O1->O2->O3->O4 순차적으로 처리하는데

O1 때문에 O2, O3, O4 모두 block 돼있음

 

 

HTTP/2

methods, status codes, 대부분의 header fields들은 변하지 않음

client-specified object priority 명시됐다면 그에 따라 처리해줌

object를 frame단위로 잘라서 스케쥴링

 

 

=> O1같이 큰 object들을 잘라 frame들을 만들고 frame단위로 처리

O2, O3, O4는 빠르게 전달되고 O1도 약간의 delay만이 존재하게 되므로 효율적

 

 

HTTP/3

 

HTTP/2에서 delay를 더 감소시킴

 

loss가 발생한다면 loss가 발생한 object 이후의 object들도 stall된다는 문제가 있다.

TCP 연결 시 낮은 security도 문제다.

 

<변경사항>

1. security를 추가하고,

2. UDP를 사용하되, UDP의 특성을 고려하여 pipelining을 통해 내보내는 속도를 높였다.

** UDP는 object별로 독립적으로 내보내기 때문에 reliable transmission 불가능 => HTTP 자체에서 error 검사 시행