[Network] 웹 캐싱(Web Caching)과 조건부 GET

웹 캐싱

웹 캐시(web cache)
- 기점 웹 서버(origin Web server)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체
- 프록시 서버(proxy server)라고도 함
- 웹 캐시는 자체의 저장 디스크를 가지고 있음
  → 최근 호출된 객체의 사본을 저장 및 보존

브라우저는 웹 캐시와 TCP 연결을 설정하고, 웹 캐시에 있는 객체에 대한 HTTP 요청 보냄
웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인
- 저장되어 있는 경우
  → 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체 전송
웹 캐시에 객체가 없다면, 웹 캐시는 기점 서버로 TCP 연결 설정
이후, 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보냄
이러한 요청을 받은 후 기점 서버는 웹 캐시로 HTTP 응답 메시지와 함께 객체를 보낸다.
웹 캐시의 객체를 수신할 때
1. 객체를 지역 저장장치에 복사
2. 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본을 보냄

웹 캐시는 ISP가 구입하고 설치한다.
- 대학교는 캠퍼스 네트워크에 웹 캐시를 설치하고
  모든 캠퍼스의 브라우저가 이 캐시로 요청을 보내도록 설정
  웹 캐시를 통한 클라이언트의 객체 요청
컴캐스트(Comcast) 같은 주요 가정 ISP는 하나 이상의 캐시를 네트워크 상에 설치 후,
설치된 캐시를 가리키도록 브라우저를 미리 설정

웹 캐시는 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다.
- 클라이언트와 기점 서버 사이의 병목 대역폭 < 클라이언트와 캐시 사이의 병목 대역폭일 때 효과적
- 캐시가 요청된 객체를 가지고 있다면, 캐시는 그 객체를 클라이언트로 신속하게 전달 가능
웹 캐시는 한 기관에서 인터넷으로의 접속하는 링크상의 웹 트래픽을 대폭 줄일 수 있다.
- 트래픽을 줄이면 대역폭 개선에 필요한 비용을 줄일 수 있다.
- 웹 캐시는 인터넷 전체의 웹 트래픽을 줄임으로써 모든 애플리케이션을 위한 성능 개선

가정
- 기관 네트워크에 있는 라우터와 인터넷에 있는 라우터는 15 Mbps 회선에 연결
- 평균 객체의 크기가 1Mb
- 기관 브라우저로부터 기점 서버에 대한 평균 요청 비율은 초당 15 요청
- 인터넷 지연 시간은 평균 2초라고 가정
  - 인터넷 지연 : 접속 회선의 인터넷 부분 라우터가 HTTP 요청을 전달 후 응답까지 걸리는 시간
  - 총 응답시간 : 브라우저의 요청으로부터 객체 수신까지 걸리는 시간
    - LAN 지연 + 접속 지연(라우터 간의 지연) + 인터넷 지연 = 총 응답시간
해당 예시에서 LAN의 트래픽 강도
→ 15 요청/초 x 1Mb/요청 / 100 Mbps = 0.15
접속 회선(인터넷 라우터에서 기관 라우터 사이)의 트래픽 강도
→ 15 요청/초 x 1Mb/요청 / 15 Mbps = 1
- 트래픽 강도가 1에 가까워지면 회선의 지연은 매우 커지고 한없이 증가
  → 기관 사용자에게 적합하지 않으므로 해결되어야 하는 문제

두 가지 해결 방법
1. 접속률은 15 Mbps에서 100 Mbps로 늘린다.
  - 0.15까지 접속 회선의 트래픽 강도를 낮추게 된다.
    - 0.15 → 두 라우터 간의 전송 지연을 무시할 수 있는 수준의 트래픽 강도
  - 해당 경우 총 응답 지연은 대략 2초
  - 접속 회선을 15 → 100 Mbps로 개선해야 하므로 많은 비용이 듦
2. 기관 네트워크에 웹 캐시를 설치한다.
  기관 네트워크에 기관 캐시 추가
- 가정
  - 적중률(캐시가 만족시킨 요청 비율)을 0.4라고 가정
- 캐시와 클라이언트가 고속 LAN에 연결되어 있으므로 요청의 40%는 캐시가 처리
  → 즉시 처리되어 10ms 이내에 만족
- 요청된 객체의 60%만 접속 회선을 통과 → 트래픽 강도는 1.0에서 0.6으로 감소
  - 일반적으로 0.8 미만의 트래픽 강도는 작은 지연에 속함
- 해당 방식의 장점
  - 첫 번째 방법보다 낮은 응답시간을 가진다
  - 기관이 인터넷을 위한 회선을 증설할 필요가 없음
    - 캐시 구입 및 설치 비용이 훨씬 저렴함

웹 캐싱을 할 때 문제점 → 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수 있음
- 복사본이 클라이언트에 캐싱된 이후에 웹 서버에 있는 객체가 갱신됐을 수도 있음
조건부 GET
- 클라이언트가 브라우저로 전달되는 모든 객체가 최신임을 확인하면서 캐싱하는 방식
- HTTP 요청 메시지가 GET 방식을 사용하고 If-Modified-Since 헤더라인 포함

브라우저의 요청을 대신해 프록시 캐시는 요청 메시지를 웹 서버로 보냄
웹 서버는 캐시에게 객체를 가진 응답 메시지를 보낸다.
- 중요한 것은 캐시와 객체와 더불어 마지막으로 수정된 날짜와 함께 저장됨
- 이후, 다른 브라우저가 같은 객체를 캐시에게 요청하면 객체는 여전히 저장되어 있음
저장된 객체가 수정된 경우 → 브라우저는 조건부 GET으로 갱신 조사 수행
- 이때 내용에 If-modified-since 포함
  → 이 헤더 라인의 값이 이전에 보낸 Last-Modified: 헤더라인과 일치하는지 확인
서버에게 그 객체가 명시된 날짜 이후 수정된 경우에만 그 객체를 보냄
- 객체를 요청할 때는 클라이언트가 웹 캐싱이 아니라 서버로 보냄
  - 서버로 보내고 객체가 수정되지 않은 경우
    → 서버가 객체를 웹캐싱에서 가져가라고 지시
- 객체가 수정되지 않은 경우
  - 웹서버가 응답 메시지를 보내지만 응답 메시지에는 요청된 객체 포함 X
    ← 요청 메시지를 포함하는 것은 대역폭 낭비이기 때문
    - 이게 HEAD 방식
- 마지막 응답 메시지는 304 Not Modified 상태 라인을 가지고 있음
  - 304 Not Modified : 클라이언트에게 요청 객체의 캐싱된 복사본을 사용해라.