7.Caching

[Intro]

웹 캐시는 자주 쓰이는 문서의 사본을 자동 보관하는 HTTP 장치이다.

웹 요청이 캐시에 도착했을 때 캐시된 로컬 사본이 존재한다면 그 문서는 원서버가 아니라 캐시에서 제공된다.

1-4) 캐시가 주는 혜택

1. 불필요한 데이터 전송을 줄여, 네트워크 요금으로인한 비용을 줄인다.

2. 네트워크 병목을 줄인다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있다.

3. 원서버에 대한 요청을 줄인다. 서버는 부하를 줄일 수 있고 더 빨리 응답할 수 있다.

   (갑작스런 이벤트에 따른 대처에 중요. 많은 사람이 동시에 접근할 때 e.g 수강신청, 이벤트, 개표)

4. 거리로인한 지연을 줄여준다.

   캐시는 유용하지만, 모든 문서의 사본을 저장하지는 않는다. 웹에 있는 모든 문서를 보관할만큼 충분한 캐시를 살 능력이 있는 사람은 거의 없고, 살수 있다 하더라도 몇몇 문서는 자주 변경되어 신선한 상태를 유지하기 어렵다.

5) 캐시 적중, 부적중 (Hits and Misses)

캐시에 요청이 도착했을 때

• 대응하는 사본이 있을 때 ⇒ 캐시적중(cache hit)

• 대응하는 사본이 없을 때 ⇒ 캐시 부적중(cache miss), 원서버로 전달되기만 함.

① 재검사(revalidation)

원서버 콘텐츠는 변경될 수 있기 때문에 캐시는 반드시 가지고있는 사본이 여전히 최신인지 서버를 통해서 때때로 점검해야한다. 이런 '신선도 검사' 를 재검사라고 한다. 효과적인 재검사를 위해 서버에서 전체 객체를 가져오지 않고도 여전히 콘텐츠가 신선한지 빠르게 검사할 수 있는 특별한 요청을 정의했다.

캐시는 언제든 사본에 대해 재검사를 할 수 있지만 네트워크 대역폭이 문서량에 비해 부족하기 때문에 사본이 검사를 필요로 할 정도로 오래된 경우에만 재검사한다.

HTTP는 캐시된 객체 재확인을 위해 제공하는 도구중 If-Modified-Since 헤더를 가장 많이 사용한다. GET 요청에 이 헤더를 추가해두면 캐시된 시간 이후 변경된 경우에만 사본을 보내달라는 의미가 되고 3가지 상황 가능.

• 재검사 적중 (= 느린 적중)

  원서버에 작은 재검사 요청을 보내고 변경되지 않았으면 아주 작은 응답(304 not modified )을 보낸다. 여전히 신선하다고 임시표시하고 사본을 클라이언트에 보내준다. 순수 캐시 적중보다는 느리지만, 캐시 부적중보다는 빠르다. 서버에서 객체 데이터를 받을 필요가 없기 때문.

• 재검사 부적중

  캐시된 사본과 다른 경우 콘텐츠 전체와 함께 평범한 HTTP 200 ok 응답을 클라이언트에 보낸다.

• 객체 삭제

  서버 객체가 삭제된 경우 404 Not Found 응답을 보내고 캐시 사본을 삭제한다.

② 적중률

• 캐시가 요청을 처리하는 비율 (= 캐시 적중률, 캐시 적중비, 문서 적중률, 적중비...)

• 0~1 혹은 0~100% 로 표시하고 100%(1)가 모든 요청을 캐시에서 사본을 가져온 경우이다.

• 보통 40% 적중률이면 웹 캐시로 괜찮은 편이라고 한다.

• 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지 보여준다. 개선시 전체 대기시간을 줄일수있다.

③ 바이트 적중률

• 문서 크기가 다 다르기 때문에 문서 적중률이 모든걸 말하지 않는다. 그래서 나온 바이트 적중률.

• 캐시를 통해 제공된 모든 바이트의 비율을 표현

• 트래픽이 절감된 정도를 포착한다.

• 대역폭 절약을 최적화한다.

④ 적중 부적중 구별

응답이 캐시 적중이었는지, 원서버 접근이었는지 HTTP는 말해줄 방법이 없음.

두 경우 모두 응답 코드는 200ok (응답이 본문을 가지고 있다. 로 알려줌)

어떤 상용 프락시 캐시는 via 헤더에 추가정보를 붙이기도 한다.

Date 헤더를 이용해서 현재시간보다 응답의 생성일이 더 오래전이면 응답이 캐시 됬음을 유추할수있다.

응답이 얼마나 오래되었는지 age 헤더를 이용하기도한다.

6) 캐시 토폴로지(Cache Topologies)

① 개인 전용 캐시

한명의 사용자에게만 할당된 캐시로, 한명의 사용자가 자주 찾는 페이지를 담는다.

• 많은 에너지나 저장공간을 필요로 하지 않으므로 작고 저렴

• 웹 브라우저는 개인 전용 캐시를 내장하고있다.

대부분의 브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해두고 사용자가 캐시사이즈와 설정을 수정하도록 허용한다.

• 캐시에 어떤것들이 들어있는지 확인하기 위해 브라우저 안을 들여다보는것도 가능하다.

② 공용 프락시 캐시

공유된 캐시는 공용캐시라고 불리며, 사용자 집단에 자주쓰이는 페이지를 담는다.

• 공용캐시 ( = 캐시 프락시 서버 ,프락시 캐시 라고 불리는 특별한 종류의 공유된 프락시서버)

• 프락시 캐시는 로컬 캐시에서 문서를 제공하거나 사용자 입장에서 서버에 접근한다.

• 공용 캐시에는 여러 사용자가 접근하므로 불필요한 트래픽을 줄일수 있는 더 많은 기회가 있다.

• 프락시 캐시는 6장에서 배운 프락시 규칙을 따른다. (수동, 자동설정파일 ...)

• 인터셉트 프락시를 사용해서 브라우저 설정없이 HTTP 요청이 캐시를 통하도록 강제할수있다.

③ 프락시 캐시 계층들

작은 캐시에서 캐시 부적중이 발생하면 더 큰 부모캐시가 걸러 남겨진 트래픽을 처리하도록 하는 계층을 만드는 방식이 합리적인 경우가 많다. 클라이언트 주위에는 작고 저렴한 캐시를 사용하고, 계층 상단에는 많은 사용자들에 의해 공유되는 문서를 유지하기 위해 더 크고 강력한 캐시를 사용하자는 것.

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

몇몇 네트워크 아키텍처는 단순한 캐시 계층 대신 복잡한 캐시망을 만든다.

캐시 커뮤니케이션을 동적으로 결정한다. [어떤 부모캐시와 대화할지, 요청이 캐시를 완전 우회해서 원서버와 대화할지 등]

캐시망 내에서 콘텐츠 라우팅을 위해 설계된 캐시들은 아래 일을 수행할 수 있다.

• URL에 근거하여, 부모 캐시와 원서버 중 하나를 동적으로 선택한다.

• URL에 근거하여, 특정 부모 캐시를 동적으로 선택한다.

• 부모 캐시에게 가기 전에, 캐시된 사본을 로컬에서 찾아본다.

• 다른 캐시들이 그들의 캐시된 콘텐츠에 부분으로 접근할 수 있도록 허용하되,그들의 캐시를 통한 Internet transit은 허용하지 않는다.

형제캐시: 선택적인 피어링을 지원하는 캐시. HTTP에서는 형제캐시를 지원하지 않아서 인터넷캐시프로토콜(ICP), 하이퍼텍스트캐시프로토콜(HTCP)을 이용해 HTTP를 확장했다.

7) 캐시처리단계

웹 캐시의 기본적인 동작 (HTTP GET 메시지 하나를 처리하는 기본 캐시 처리 절차)

1. 요청받기: 캐시는 네트워크로부터 도착한 요청메시지를 읽는다.

2. 파싱: 캐시는 메시지를 파싱하여 URL과 헤더를 추출한다.

3. 검색: 캐시는 로컬사본이 있는지 검사하고 사본이 없다면 사본을 받아온다. (그리고 로컬에 저장)

4. 신선도 검사: 캐시된 사본이 충분히 신선한지, 신선하지 않다면 변경사항이 있는지 서버에 물어본다.

5. 응답생성: 캐시는 새로운 헤더와 캐시된 본문으로 응답메세지를 만든다.

6. 발송: 캐시는 네트워크를 통해 응답을 클라이언트에게 돌려준다.

7. 로깅: 선택적으로 캐시는 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남긴다.

8) 사본 신선하게 유지하기

오래된 데이터를 제공하는 캐시는 불필요하다. 캐시된 데이터는 서버의 데이터와 일치되도록 관리되야한다.

캐시된 사본과 서버가 일치하도록 유지할 수 있는 단순한 매커니즘을 확인한다.

① 문서만료

Cache-Control 과 Expires라는 특별한 헤더들을 이용해 원서버가 각 문서에 유효기간을 붙일 수 있게 한다.

이 헤더들은 얼마나 오랫동안 신선한 상태로 보일 수 있는지 좌우한다.

캐시 문서가 만료되기 전에 캐시는 필요하면 서버 접촉없이 사본제공이 가능. [캐시됬거나, 검증되지 않은 리소스 제공을 거부하는 헤더가 클라이언트 요청에 없는경우에만]

캐시된 문서가 만료되면 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야하고 그렇다면 신선한 사본을 가져와야한다.

응답 헤더 추가 예시) Expires: Fri, 05 Jul 2021, 05:00:00 GMT

Cache-Control: max-age=48200 (초)

② 서버 재검사

캐시 문서가 만료되었다는 의미가 원서버에 현재존재하는 것과 실제로 다르다는 의미는 아니다.

단지 검사할 시간이 되었음을 뜻하며, 이 검사를 캐시가 원서버에게 문서가 변경됬는지 여부를 물어볼 필요가 있음을 의미하는 '서버 재검사' 라고 부른다.

매 요청마다 검증하는게 아니라 문서가 만료되었을 때에 한번만 서버와 재검사를 하면된다.

따라서 신선한 콘텐츠를 제공하면서 서버 트래픽을 절약하고 사용자 응답시간을 개선할 수 있다.

• 조건부 메서드와의 재검사

  • 조건부 GET 요청: 서버가 가진 문서가 캐시가 갖고 있는 것과 다른 경우에만 객체 본문을 달라고 한다.

  • GET 요청메세지에 특별한 조건부 헤더를 추가함으로써 시작됨.(조건이 참인경우에만 반환)

  • 5가지 조건부 요청이 있고, 주로 조건부 헤더는 If- 접두어로 시작한다.

    • 캐시 재검사 헤더 중 2가지가 가장 유용하게 쓰인다.

      • If-Modified-Since: <date> (= IMS 요청)

        • 만약 문서가 주어진 날짜 이후로 수정이 되었다면 요청메서드를 처리한다. (200 ok )

        • 캐시된 버전으로부터 콘텐츠가 변경된 경우에만 콘텐츠를 가져오기위해 Last-Modified 서버 응답헤더와 함께 쓰인다.

        • 만약 문서가 주어진 날짜 이후로 수정이 없었다면 조건은 거짓이고, 304 Not modified 응답메세지를 클라이언트에게 보낸다. 효율을 위해 본문은 보내지 않고, 갱신이 필요한 부분만 보낸다. (예: 새로운 만료 날짜만 보낸다던가)

      • If-None-Match: <tags>

        • 최근 변경 일시 재검사가 적절히 행해지기 어려운 상황에 사용

        • 앤터티 태그 변경시, 캐시는 새 문서의 사본을 얻기(GET) 위해 사용할 수 있다.

    • 약한 검사기와 강한 검사기

      • 강한 검사기는 콘텐츠가 변경될때마다 바뀌고, 약한 검사기는 어느정도 콘텐츠 변경을 허용한다.

9) 캐시 제어

문서가 만료되기 전까지 얼마나 오래 캐쉬될수 있게 할것인지 서버가 설정하는 여러가지 방법.

• Cache-Control: no-store 헤더를 응답헤더에 첨부

• Cache-Control: no-cache 헤더를 응답헤더에 첨부

• Cache-Control: must-revalidate 헤더를 응답헤더에 첨부

• Cache-Control: max-age 헤더를 응답헤더에 첨부

• Expires 날짜 헤더를 응답에 첨부

• 아무런 만료 정보 없이 캐시가 스스로 체험적인(휴리스틱) 방법으로 결정

10) 캐시 제어 설정

아파치 웹 서버가 캐시를 어떻게 지원하는지 간단히 본다.