[HTTP 완벽 가이드 7장] 캐시

• 웹 캐시는 자주 쓰이는 문서의 사본은 자동으로 보관하는 HTTP 장치
• 캐시가 주는 혜택
  1. 캐시는 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다.
  2. 캐시는 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 된다.
  3. 캐시는 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다.
  4. 페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다.

7.1 불필요한 데이터 전송

• 복수의 클라이언트가 자주 쓰이는 원 서버 페이지에 접근할 때, 서버는 같은 문서를 클라이언트들에게 각각 한 번씩 전송한다.
• 똑같은 바이트들이 네트워크를 통해 계속 반복해서 이동한다.
• 이 불필요한 데이터는 네트워크 대역폭을 잡아먹고, 전송을 느리게 만들며, 웹 서버에 부하를 준다.
• 첫 번째 응답을 캐시에 보관하여 다음에 오는 요청을에 대한 응답으로 사용할 수 있다.

7.2 대역폭 병목

• 캐시는 네트워크의 병목을 줄여준다.

• 만약 클라이언트가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 캐싱은 성능을 대폭 개선할 수 있을 것이다.

  LAN (Local Area Network)란?

  • 사용자가 포함된 지역 네트워크를 의미
  • 쉽게 말하면 학교, 회사, 집에서 컴퓨터, IP 전화기, 프린터 등의 장비를 서로 연결한 것
  • LAN은 구성할 때 드는 비용과 전기세를 빼고는 유지보수비가 들지 않음
  • LAN은 이더넷 이라는 프로토콜을 주로 사용
    

  WAN (Wide Area Network)란?

  • LAN과 LAN 사이를 광범위한 지역 단위로 구성하는 네트워크
  • ISP(Internet Service Provider: SK, KT, LG) 네트워크망을 통해 LAN과 LAN을 연결
  • 우리가 사용하는 네트워크는 작은 네트워크들이 서로 합쳐져서 커지고 또 합쳐져서 하나의 큰 네트워크가 됨
    

  이더넷 (Ethernet)이란?

  • 사무실, 학교, PC방 등의 LAN 환경에서 거의 절대 다수를 차지하는 네트워크 구성 방식
  • 네트워킹의 한 방식이며, 네트워크를 만드는 방법 중 하나라고 생각하면 됨
  • 이더넥의 가장 큰 특징은 CSMA/CD라는 프로토콜을 사용해서 통신하는 것

  CSMA/CS (Carrier Sense Multiple Access / Collision Detection)란?

  • 이더넷 환경에서 통신을 하고 싶은 PC나 서버는 먼저 지금 네트워크 상에 통신이 일어나고 있는지 확인(Carrier Sense), 있다면 자기가 보낼 정보를 가지고 기다리다가 네트워크에서 통신이 없어지면 자신의 데이터를 네트워크 상에 실어서 보냄
  • 만약 두 대의 PC나 서버가 기다리다가 동시에 보내는 경우(Multiple Access)가 발생
  • 통신은 이렇게 두 개의 장비들이 데이터를 동시에 보내려다가 부딪치는 경우를 충돌(Collision)이 발생했다고 말함
  • 충돌이 발생하게 되면 데이터를 전송했던 PC들은 랜덤한 시간동안 기다린 다음 다시 데이터를 전송함
  • 그래서 이더넷에서는 너무 많은 충돌이 발생하면 통신 자체가 불가능해지는 경우도 발생

• 샌프란시스코 지사에서 애틀란티스 본사로부터 5MB 크기의 문서를 받는다면 30초가 걸릴 수 있지만, 샌프란시스코 지사 사무실에 캐시되어 있다면 1초 미만이 걸릴 것이다.

7.3 갑작스런 요청 쇄도 (Flash Crowds)

• 캐싱은 갑작스런 사건으로 인해 트래픽이 몰릴 때 대처하기 위해 중요하다.
• 1998년 클린턴 미 대통령의 조사에 대한 내용이 담긴 보고서가 인터넷을 통해 공개되었는데 이 웹 사이트는 한 시간 동안 3백만 건이 넘는 요청을 받았다.

7.4 거리로 인한 지연

• 대역폭이 문제가 되지 않더라도, 거리가 문제 될 수 있다. 모든 네트워크 라우터는 제각각 인터넷 트래픽을 지연시킨다.
• 클라이언트와 서버 사이에 라우터가 많지 않더라도, 빛의 속도 그 자체가 유의미한 지연을 유발한다.

7.5 적중과 부적중

• 캐시가 세상 모든 문서의 사본을 저장하지는 않는다. (용량 부족)
• 캐시에 요청이 도착했을 때, 사본이 있다면 그것을 이용해 요청을 처리 (적중)
• 사본이 없다면 그냥 원 서버로 전달 (부적중)

1) 재검사 (Revalidation)

• 서버의 콘텐츠가 변경될 수 있기 때문에 캐시는 사본이 최신인지 서버를 통해 점검해야한다.

• HTTP는 캐시된 객체를 재확인하기 위해 몇 가지 도구를 제공하는데 가장 많이 쓰이는 것은 If-Modified-Since 헤더이다.

• 서버에게 보내는 GET 요청에 이 헤더를 추가하면 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미가 된다.

• GET If-Modified-Sice 요청이 서버에 도착했을 때 세 가지 상황

  1. 재검사 적중
     서버 객체가 변경되지 않았다면, 서버는 클라이언트에게 작은 HTTP 304 Not Modified 응답을 보낸다.
  2. 재검사 부적중
     서버 객체가 캐시된 사본과 다르다면, 서버는 콘텐츠 전체와 함께 HTTP 200 OK 응답을 클라이언트에게 보낸다.
  3. 객체 삭제
     서버 객체가 삭제되었다면, 서버는 404 Not Fount 응답을 돌려보내며, 캐시는 사본을 삭제한다.

2) 적중률

• 캐시가 요청을 처리하는 비율을 캐시 적중률 혹은 문서 적중률이라고 부른다.
• 오늘날 적중률 40%면 웹 캐시로 괜찮은 편이다.

3) 바이트 적중률

• 문서들의 크기가 모두 다르기 때문에 캐시 적중률이 모든 것을 말해주지 않는다. 몇몇 큰 객체는 덜 접근되지만 그 크기 때문에 전체 트래픽에는 더 크게 기여한다.
• 바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현한다.

4) 적중과 부적중 구별

• 클라이언트는 응답의 Date 헤더나 Age 헤더를 통해 응답이 캐시로부터 온 것인지 서버로부터 온 것인지 구별할 수 있다. (캐시 응답의 경우 현재 시각과 비교할 때 더 오래되었다)

7.6 캐시 토폴로지

• 한 명에게만 할당된 캐시를 개인 전용 캐시(private cache)라 부르고 수천 명이 공유하는 캐시를 공용 캐시(public cache)라고 부른다.

1) 개인 전용 캐시

• 개인 전용 캐시는 많은 저장 공간을 필요로 하지 않으므로, 작고 저렴할 수 있다.
• 웹 브라우저는 개인 전용 캐시를 내장하고 있다.

2) 공용 프락시 캐시

• 공용 캐시는 캐시 프락시 서버 혹은 더 흔히 프락시 캐시라고 불리는 특별한 종류의 공유된 프락시 서버다.

3) 프락시 캐시 계층들

• 작은 캐시에서 캐시 부적중이 발생했을 때 더 큰 부모 캐시가 그 '걸러 남겨진' 트래픽을 처리하도록 하는 계층을 만드는 방식이 합리적인 경우가 많다.

  나의 생각
  개인 컴퓨터의 웹 브라우저에는 나만의 캐시가 있다.
  그 캐시에서 캐시 부적중이 발생한다면 LAN 단위의 캐시(공용 캐시)가 그 요청을 처리할 수 있다.

4) 캐시망, 콘텐츠 라우팅, 피어링

• 캐시망의 프락시 캐시는 서로 대화하여, 어떤 부모 캐시와 대화할 것인지, 아니면 요청이 캐시를 우회하여 원 서버로 가도록 할 것인지 동적으로 결정한다.
• 캐시망 안에서의 콘텐츠 라우팅을 위해 설계된 캐시들은 다음의 일을 할 수 있다.
  1. URL에 근거하여, 부모 캐시와 원 서버 중 하나를 동적으로 선택한다.
  2. URL에 근거하여 특정 부모 캐시를 동적으로 선택한다.
  3. 부모 캐시에게 가기 전에, 캐시된 사본을 로컬에서 찾아본다.
  4. 다른 캐시들이 그들의 캐시된 콘텐츠에 부분적으로 접근할 수 있도록 허용하되,
     그들의 캐시를 통한 인터넷 트랜짓(Internet Transit: 트래픽이 다른 네트워크로 건너감)은 허용하지 않는다.

7.7 캐시 처리 단계

HTTP GET 메시지 하나를 처리하는 기본적인 캐시 처리 절차 7단계

1. 요청 받기 - 캐시는 네트워크로 부터 도착한 요청 메시지를 읽는다.
2. 파싱 - 캐시는 메시지를 파싱하여 URL과 헤더들을 추출한다.
3. 검색 - 캐시는 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아온다(그리고 로컬에 저장한다).
4. 신선도 검사 - 캐시는 캐시된 사본이 충분히 신선한지 검사하고, 신선하지 않다면 서버에게 변경사항이 있는지 물어본다.
5. 응답 생성 - 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다.
6. 발송 - 캐시는 네트워크를 통해 응답을 클라이언트에게 돌려준다.
7. 로깅 - 선택적으로, 캐시는 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남긴다.

1) 단계 1: 요청 받기

• 네트워크 커넥션에서의 활동을 감지하여 들어오는 데이터를 읽어들인다.
• 고성능 캐시는 여러 개의 커넥션에서 들어오는 데이터를 한번에 읽어들이고 메시지 전체가 도착하기 전 트랜잭션 처리를 시작한다.

2) 단계 2: 파싱

• 캐시는 요청 메시지를 여러 부분으로 파싱하여 헤더 부분을 조작하기 쉬운 자료 구조에 담는다.

3) 단계 3: 검색

• 캐시는 URL을 알아내고 그에 해당하는 로컬 사본이 있는지 검사한다.
• 로컬 복사본은 메모리나 디스크, 심지어 근처의 다른 컴퓨터에 있을 수도 있다.

4) 단계 4: 신선도 검사

• 캐시된 사본을 너무 오래 갖고 있었다면 그 객체는 '신선하지 않은' 것으로 간주되며, 캐시는 그 문서를 제공하기 전에 변경이 있었는지 서버를 통해 검사해야 한다.

5) 단계 5: 응답 생성

• 캐시는 캐시된 서버 응답 헤더를 토대로 응답 헤더를 생성한다.
• 클라이언트가 HTTP/1.1 응답을 기대하는 상황에서 서버가 HTTP/1.0 응답을 반환했다면, 캐시는 반드시 헤더를 적절하게 번역해야 한다.
• 또한 캐시 신선도 정보(Cache-Control, Age, Expires헤더)를 삽입하며, 요청이 프락시 캐시를 거쳐갔음을 알려주기 위해 종종 Via 헤더를 포합시킨다.
• 캐시는 Date 헤더를 조정해서는 안된다. Date 헤더는 그 객체가 원 서버에서 최초로 생성된 일시를 표현한 것이다.

6) 단계 6: 전송

• 일단 응답 헤더가 준비되면, 캐시는 응답을 클라이언트에게 돌려준다.
• 모든 프락시 서버들과 마찬가지로, 프락시 캐시는 클라이언트와의 커넥션을 유지할 필요가 있다.

7) 단계 7: 로깅

• 대부분의 캐시는 로그 파일과 캐시 사용에 대한 통계를 유지한다.

8) 캐시 처리 플로 차트

7.8 사본을 신선하게 유지하기

• 캐시된 사본과 서버의 문서가 항상 일치할 수 없다. (서버의 문서는 바뀔 수 있기 때문)
• 캐시된 데이터는 서버의 데이터와 일치하도록 관리되어야 한다.

1) 문서 만료

• HTTP는 Cache-Control과 Expires라는 특별한 헤더들을 이용해서 원 서버가 각 문서에 유효기간을 붙일 수 있게 해준다.
• 캐시 문서가 만료되기 전에, 캐시는 필요하다면 서버와의 접촉 없이 사본을 제공할 수 있다.
• 그러나 일단 캐시된 문서가 만료되면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 하며, 만약 그렇다면 사본을 얻어 와야 한다(새 유효기간과 함께).

2) 유효기간과 나이

• 서버는 응답 본문과 함께 하는, Expiressk Cache-Control: max-age 응답 헤더를 이용해서 유효기간을 명시한다.

  Cache-Control: max-age=484200
  max-age 값은 문서의 최대 나이를 정의한다. 최대 나이는 문서가 처음 생성된 이후부터, 더 이상 신선하지 않다고 간주될 때 까지의 시간이다. (초)
  Expires: Fri, 05 Jul 2002, 05:00:00 GMT
  절대 유효기간은 명시한다. 만약 유효기간이 경과했다면, 그 문서는 더 이상 신선하지 않다.

3) 서버 재검사

• 캐시된 문서가 만료되었다는 것은, 원 서버의 문서와 다르다는 것을 의미하는 것이 아니라 검사할 시간이 되었다는 의미이다.
• 재검사 결과 콘텐츠가 변경되었으면, 캐시는 그 문서의 사본을 가져와 저장하고 클라이언트에게도 보내준다.
• 재겸사 결과 콘텐츠가 변경되지 않았으면, 캐시는 새 만료일을 포함한 새 헤더들만 가져와서 캐시 안의 헤더들을 갱신한다.

4) 조건부 메서드와의 재검사

• HTTP는 캐시가 서버에게 '조건부 GET'이라는 요청을 보낼 수 있도록 해준다.
• HTTP는 다섯 가지 요청 헤더를 정의하는데, 그 중 둘은 캐시 재검사를 할 때 가장 유용한 If-Modified-Since와 If-None-Match이다.

5) If-Modified-Since: 날짜 재검사

• 가장 흔히 쓰이는 재검사 헤더는 If-Modified-Since이며, 흔히 'IMS' 요청으로 불린다.
• IMS 요청은 서버에게 리소스가 특정 날짜 이후로 변경된 경우에만 요청 본문을 보내달라고 한다.
• IMS 헤더는 서버 응답 헤더의 Last-Modified 헤더와 함께 동작한다.
• 캐시는 문서가 캐시된 날짜를 IMS에 보관하고, 원 서버는 제공하는 문서의 최근 변경 일시를 LM에 붙인다.
• IMS와 LM을 비교해서 IMS 날짜 이후에 서버의 문서가 변경되었다면, 원 서버는 새 문서를 주고 그렇지 않다면, 304 Not Modified 응답을 돌려줄 것이다.

6) If-None-Match: 엔터티 태그 재검사

• 어떤 문서는 내용에 아무런 변화가 없더라도 변경시각은 바뀔 수 있다.
• 어떤 문서들의 변경은 전 시계의 캐시들이 그 데이터를 다시 읽어들이기엔 사소한 것일 수도 있다. (철자나 주석 변경)
• 퍼블리셔가 문서를 변경했을 때, 그는 문서의 엔터티 태그를 새로운 버젼으로 표현할 수 있다.
• 캐시는 엔터티 태그 'v2.6'인 문서를 갖고 있고, 원 서버에게 태그가 더 이상 'v2.6'이 아닌 경우에만 새 객체를 달라고 요청한다.

  요청: If-None-Match: "v2.6"
  응답: 304 Not Modified, ETag: "v2.6"

• 만약 서버의 엔터티 태그가 변경되었다면, 서버는 200 OK 응답으로 새 콘텐츠를 새 ETag와 함께 반환했을 것이다.