HTTP : 캐싱 , Web Cache

웹 캐시 ( Web Cache ) = 프록시 서버( Proxy Server )
。HTTP Server의 역할을 대신하는 중계서버
▶ 브라우저와 HTTP Server 중간에서 통신을 대리로 수행
▶ 기억장치의 Cache Memory와 유사한 Logic

。Origin Server에 접근할 필요없이 Local Server에 객체를 보관하여 접근하는 원리
▶ 자체 저장소를 가지고있어 최근 호출한 객체의 사본을 저장 및 보존
▶ 브라우저는 객체 요청 시 반드시 웹 캐시로 HTTP Request를 송신하도록 설정

。일반적으로 ISP가 웹캐시를 구입 및 설치하여 모든 캠퍼스의 브라우저가 해당 웹 캐시로 요청을 보내도록 설정

。웹 캐시는 자체저장소에 저장된 객체 사본이 Origin Server 내 객체보다 Outdated 될 수 있는 문제점을 Conditional GET을 통해 검증하여 해결

웹캐시 사용목적

• Client의 HTTP Request에 대한 Response Time 감소
  。Origin Server까지 요청할 필요없이 중간의 중계서버인 웹캐시를 통해 객체를 요청하므로
  
  
• 다수의 End System으로 구성된 특정 기관으로부터의 인터넷으로 접속하는 Access Link의 Traffic을 상당수 감소
  。기관 네트워크에서 인터넷으로 진입하는 비율이 감소하면서 비용 감소
  
  。인터넷 전체의 트래픽을 감소시키면서 네트워크 어플리케이션의 성능 증진
  
  
• P2P 또는 Content Provider 입장에서 유리
  。Network상에 분포된 Web Cache에 사전에 Content에 대한 사본을 저장하여 Share가 유리해짐
  ▶ 브라우저가 Content를 요청 시 Content Provider의 Server가 아닌 Web Cache로부터 Content를 응답받도록 설정

웹캐시 원리
。웹 캐시는 HTTP Server이면서 동시에 HTTP Client 역할을 수행
▶ Client 프로세스와 Server 프로세스를 동시 실행

。브라우저가 객체를 요청하는 HTTP Request Message를 웹캐시에 전송하는 경우
▶ 웹캐시가 해당 객체를 포함하는 경우 즉시 응답하여 반환
▶ 웹캐시가 해당 객체를 포함하지 않는 경우 웹캐시에서 HTTP Server로 해당 객체를 요청 후 브라우저로 반환

• 브라우저는 웹캐시와 TCP Connection을 구축 후 객체에 대한 HTTP Request 송신
  
  
• 웹캐시는 객체의 사본이 자체저장소에 저장되어있는지 확인
  。객체의 사본이 자체저장소에 저장되어있는 경우 브라우저로 HTTP Response Message에 객체를 캡슐화한 후 응답
  
  
• 웹캐시가 객체의 사본이 없는 경우 Origin Server( = HTTP Server )에 TCP Connection을 설정 후 객체에 대한 HTTP Request 송신
  。HTTP Server는 HTTP Response Message에 객체를 캡슐화한 후 웹캐시로 응답
  
  
• Origin Server로부터 HTTP Response 수신 후 객체를 자체저장소에 사본으로서 저장 및 브라우저에 HTTP Response Message에 객체를 캡슐화한 후 응답
  。객체 사본 저장 시 Last-Modified Header Line도 함께 저장
  ▶ 향후 Conditional GET을 통한 객체가 Outdated 되었는지 확인

웹 캐싱 예시

• 특정 기관 네트워크의 브라우저에서 인터넷의 Origin Server간 HTTP Transaction 수행 시
  
  。기관 네트워크와 인터넷은 각각 Access Link를 통해 기관의 라우터와 ISP의 POP를 통해 연결됨

  • 가정
    。Access Link : 초당 전송률 15.4 Mbps의 통신링크
    。LAN : 초당 전송률 100 Mbps의 통신링크
    
    。평균 데이터객체 크기 : 1 Mbits
    
    。Origin Server와 ISP의 POP 간 RTT : 2 sec
    ▶ Internet Delay
    
    。기관 브라우저에서 Origin Server에 대한 초당 평균 요청비율 : 15 / sec번
    
    
  • 소요시간( delay ) 계산 : Traffic Intensity
    。 초당 Traffic의 총량 : 초당 요청수 * 객체 크기 = 15 Mbits/sec = 15 Mbps
    
    。 LAN Traffic Intensity = $\displaystyle \frac{15 Mbps}{100 Mbps}=0.15$
    ▶ LAN Utilization은 약 15%에 육박
    ▶ Traffic Intensity = 0.15는 최대 msec Delay를 야기하므로 해당 지연을 무시가능.
    
    。Access Link Traffic Intensity = $\displaystyle \frac{15 Mbps}{15.4 Mbps}=0.97$
    ▶ Access Link Utilization은 약 97%에 육박
    ▶ Traffic Intensity가 0.78을 초과하는지점에서 큐잉지연이 급격하게 증가하여 few minute Delay가 발생
    
    Total Delay = Internet delay + Access delay + LAN delay
    ▶ 2 sec + minute + msec = minute
    
    。 최종적으로 전송률이 낮은 Access Link 때문에 대략 몇분 수준의 Delay가 발생.

• 
  
  
• 해결책 1 : fatter Access Link
  
  。Access Link를 Bandwidth가 더 큰 fatter Access Link로 교체하여 Bandwidth가 154 Mbps이 될 경우
  
  。 Access Link Traffic Intensity = $\displaystyle \frac{15 Mbps}{154 Mbps}=0.09$
  ▶ Access Link Utilization은 약 9.9%에 육박하여 최대 msec delay가 발생.
  ▶ 2 sec + msec + msec = 2 sec
  
  。그러나 해당 방식은 fatter Access Link로 인한 비용증가 문제와 Web Cache 방식보다 Delay가 다소 큰 문제가 존재.
• 
  
  
• 해결책2.: 기관 네트워크에 로컬 웹 캐시를 추가하여 인터넷의 Origin Server간 HTTP Transaction 수행 시
  
  。기관 네트워크의 모든 브라우저가 Origin Server가 아닌 Local Web Cache에 HTTP Request를 전송하여 중계하도록함.
  ▶ Web Cache에 저장된 객체를 요청하는 HTTP Request까지는 Access Link를 통해서 Origin Server에 접근할 필요없이 LAN 내부 Local Web Cache가 대신 처리
  
  。LAN 내부의 Local Web Cache에서 일정부분의 HTTP Request를 Origin Server 대신 처리하므로 Access Link의 Utilization이 감소.

  • 가정
    。기관네트워크의 브라우저에서 웹캐시로 요청한 HTTP Request의 Cache Hit Rate = 0.4
    
    
  • 소요시간 ( delay ) 계산
    
    。HTTP Request의 40%는 웹 캐시에 의해LAN 내부에서 즉시 응답
    ▶ 약 10 ms delay 발생
    
    。HTTP Request의 60%는 웹 캐시에서 Origin Server로 HTTP Request 전송
    ▶ HTTP Request 중 약 60%만 Access Link를 통과
    
    Access Link Traffic Intensity = $\displaystyle \frac{15 Mbps}{15.4 Mbps}*0.6=0.6$
    
    。기존 0.97 대비 0.6으로 Access Link Utilization이 감소하면서 Congestion이 감소
    ▶ 일반적으로 0.78 미만의 traffic intensity는 큐잉 지연이 낮으므로 msec delay를 발생
    
    Total Delay = Internet delay + Access delay + LAN delay
    ▶ ( 2 sec * 0.6 ) + ( 0.6 * msec ) + ( 0.4 * msec ) = 1.2 sec
    
    。웹캐시를 사용하지 않고 Fatter Access Link를 사용한 Total Delay ( 2 sec )보다 훨씬 감소한 것을 확인가능
    ▶ 또한 웹캐시 비용도 Fatter Access Link에 비해 저렴

Conditional GET [RFC 7232]
。HTTP Request Message 전송 시 GET Method와 If-Modified-Since Header Line을 포함하는 방식

。 웹 캐시는 자체저장소에 저장된 객체 사본이 Origin Server 내 객체보다 Outdated 될 수 있는 문제점이 존재
▶ Conditional GET을 통해 브라우저로 전달되는 객체가 Up to date인지 확인하면서 캐싱을 수행

• Conditional GET 원리
  

  • 브라우저의 HTTP Request를 수신하여 웹캐시에서 Origin Server로 HTTP Request를 요청( GET )

  GET /fruit/kiwi.gif HTTP/1.1
  Host: www.example.com

  • Origin Server는 웹 캐시에 객체를 캡슐화한 HTTP Response Message를 응답

  HTTP/1.1 200 OK
  Date: Sat, 3 Oct 2015 15:39:29
  Server: Apache/1.3.0 (Unix)
  Last-Modified: Wed, 9 Sep 2015 09:23:24
  Content-Type: image/gif
        // 
        HTTP Response Body
        //

  。웹캐시는 해당 객체 사본과 Last-Modified의 Date를 함께 자체저장소에 저장 및 브라우저로 전달
  
  

  • 일정기간이 소요된 후 브라우저가 웹 캐시에 동일 객체를 HTTP Request하여 요청( GET )
    。브라우저가 웹 캐시에 동일 객체를 요청

  GET /fruit/kiwi.gif HTTP/1.1
  Host: www.example.com

  • 웹 캐시에서 Origin Server로 Conditional GET 수행
    。웹 캐시가 저장한 객체 사본의 Last-Modified의 Date를 HTTP Request Message의 If-modified-since : Header Line에 포함하여 Origin Server로 HTTP Request를 요청

  GET /fruit/kiwi.gif HTTP/1.1
  Host: www.example.com
  If-modified-since: Wed, 9 Sep 2015 09:23:24

  ▶ 객체 사본이 Up to date한지 검증을 위해 Origin Server로 전송
  
  

  • Origin Server에서 HTTP Request Message에 포함된 If-modified-since : Header Line을 검증 후 응답
    。Origin Server의 객체의 Last-Modified와 웹 캐시에서 전송한 If-modified-since의 시점을 비교 후 응답에 객체 포함 결정

    • If-modified-since : 시점의 명시된 시점 이후에 객체가 수정되지 않은 경우
      。객체가 Up to date한 상태이므로, 빈 객체를 웹 캐시로 반환
      ▶ 비어있는 Message Body를 응답하므로 Response Time이 적음

    HTTP/1.1 304 Not Modified
    Date: 전송시각
    Server: Apache/1.3.0 (Unix)
          // 
          객체 없음
          //

    。 Status Code : 304를 Client에 응답하여 웹캐시에 저장된 객체 사본을 사용하도록 지시
    
    

    • If-modified-since : 시점의 명시된 시점 이후에 객체가 수정된 경우
      。웹 캐시에 객체 사본이 저장된 이후 Origin Server에서 해당 객체를 수정하여 객체 사본이 Outdated된 경우 ( ex : Wed, 9 Sep 2015 09:23:24 이후에 수정된 경우 )

    HTTP/1.1 200 OK
    Date: 전송시각
    Server: Apache/1.3.0 (Unix)
    Last-Modified: 객체가 마지막으로 수정된 Date
    Content-Type: image/gif
          // 
          HTTP Response Body
          //

    。수정된 객체와 Last-Modified를 웹 캐시에 응답
    ▶ 웹 캐시는 자체저장소에 해당 객체 사본으로 교체하여 Last-Modified와 함께 저장 후 클라이언트로 반환

프록시 종류

• Forward Proxy :
  。Client-side에서 Client 대신 Proxy Server가 목적서버(Web server)에 대리로 통신해주는 역할을 수행하는 프록시 서버
  ▶ Proxy Server가 외부 웹서버와 통신을 수행하면서 Client는 Proxy Server만을 이용하여 정보를 획득하고 웹서버는 Proxy Server를 통한 Access log가 남는다.
  
  。Client가 어떤 Proxy Server를 경유할지 설정 가능.
  
  
• Reverse Proxy :
  。Server-side에서 Client의 Http Request를 처리하는데 적합한 웹서버를 선택허여 배분하는 역할을 수행하는 프록시 서버
  ▶ Client의 각 url에 따른 Http Request를 Proxy Server에 집중한 후 url에 따라서 각 HttpRequest를 수신할 웹서버를 설정.
  
  。Client 입장에서는 Proxy Server가 웹서버와 동일한 동작을 수행하므로, 서버 측에서 웹서버가 여러개 존재하는것을 은폐 가능.
  
  。주로 nginx가 존재