13. Cache

13. Cache

Cache??

• Web Cache란 자주쓰는 문서의 사본으로 자동으로 보관하는 HTTP 장치이다.

• 불필요한 데이터 전송을 줄여, Cost를 줄여준다.

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

  • 병목

    → 전체 시스템의 성능이나 용량이 하나의 구성 요소로 인해 제한을 받는 것

• 대역폭을 늘리지 않아도 페이지를 빠르게 불러 올수 있게 된다.

• Origin Sever에 대한 요청을 줄여 Server의 부하를 줄여준다.

• Flash Crowds에 대응 할 수 있다.

  • Flash Crowds

    → 갑작스런 요청 쇄도

• Server와의 물리적 거리에 따라 지연시간이 발생하는데 이러한 현상을 줄여준다.

대역폭이 네트워크 속도와 문서 크기에 따라 전송시간에 미치는 영향

(단위 : sec)	큰 HTML(15KB)	JPEG(40KB)	큰 JPEG(150KB)	큰 File(5MB)
전화식 모뎀(56kb/sec)	2.19	5.85	21.94	748.98
DSL(256kb/sec)	0.48	1.28	4.80	163.84
T1(1.4Mb/sec)	0.9	0.23	0.85	29.13
느린 이더넷(10MB/sec)	0.01	0.03	0.12	4.19
DS3(45MB/sec)	0.00	0.01	0.03
빠른 이더넷(100MB/sec)	0.00	0.00	0.01	0.42

---

적중과 부적중

(캐시)적중

• Cache에 요청 도착 시 그에 대응하는 사본이 있다면 이를 이용하여 처리하는 현상

(캐시)부적중

• Cache에 요청 도착 시 그에 대응하는 사본이 없다면 Origin Sever로 전달되기만 할뿐인 현상

재검사(Revalidation)

• Origin Server의 컨텐츠의 수정가능성 때문에 Cache는 갖고있는 사본이 최신인지 신선도검사를 해야한다.

• Cache는 스스로 원한다면 언제든지 사본을 검사 할 수 있지만, 대부분의 Cache는 클라이언트가 사본을 요청하고 그 사본이 검사를 할 필요가 있을 정도로 오래된 경우에만 겸사를 시행한다.

• Cache가 재검사 요청을 보낸 후, 콘텐츠가 변경되지 않았다면 Server는 304 Not Modified응답을 보낸다.

• 사본이 유효함을 알게된 캐시는 클라이언트에게 그 사본을 제공한다.

• 이를 재검사 적중 or 느린 적중이이라고 부른다.

• 응답 속도

  → (캐시)적중 < 재검사 적중 < (캐시)부적중

• If-Modified-Since 헤더

  • Server에게 보내는 GET요청에 추가시 해당 캐시된 시간 이후에 변경된경우 사본을 보내달라는 의미
  • 해당 요청이 서버에 도착하면 일어날 수 있는 세가지 상황
    1. 재검사 적중
       • HTTP 304 Not Modified 상태코드를 보낸다.
    2. 재검사 부적중
       • HTTP 200 OK 상태코드를 보낸다.
    3. 삭제된 데이터
       • HTTP 404 Not Found 상태코드를 보낸다.

캐시 적중률(캐시 적중비)

• Cache가 요청을 처리하는 비율
• 보통 오늘날은 40%의 적중률을 보이면 웹 Cache로 괜찮은 편이다.

바이트 적중률

• Cache를 통해 제공된 모든 바이트의 비율
• 트래픽이 절감된 정도를 포착한다.

적중과 부적중의 구별

• Cache가 적중이던 부적중이던 클라이언트에게 응답은 HTTP 200 OK가 전달 된다.
• 어떤 상용 Proxy Cache는 무슨일이 일어났는지 설명하기 위해 Via 헤더에 추가 정보를 붙인다.
• Date 헤더
  • 응답이 Cache에서 왔는지 응답 생성일을 기준으로 확인하게 해주는 헤더
  • 응답의 생성일이 더 오래되었다면 캐시된 것임을 알아 낼 수 있다.
• Age 헤더
  • 응답이 얼마나 오래되었는지 알려주는 헤더
  • 해당 응답의 생성일을 알려준다.

---

Cache 토폴로지

• Cache는 한명 or 다수의 사용자에게 할당 할 수 있다.

private Cache

• 개인 전용 캐시
• 개인이 자주 접속하는 페이지 같이 개인적인 데이터를 담는다.
• 많은 저장공간이 필요하지 않다.
• 대부분의 브라우저 컴퓨터의 디스크나 메모리에 해당 캐시를 저장해두고 사용한다.
• Google은 URL인 about:cache를 통해 연결되는 페이지에서 캐시 콘텐츠의 목록을 볼 수 있다.

public Cache

• 공용캐시 ( Cache Proxy Server 또는 Proxy Cache )
• 사용자 집단이 자주 접속하는 페이지 같은 공통적인 데이터를 담는다.
• 불필요한 트래픽을 줄일 수 있는 더 많은 기회가 있다.

priavte Cache & public Cache

Proxy Cache 계층들

• Cache 계층이 존재한다면 적중시 바로 Cache에서, 부적중시 부모 Cache에서 처리하게 된다.
  • 이도저도 아닐 때에는 Origin Server에서 가져온다.
• 이 아이디어는 클라이언트 주위에는 작고 저렴한 캐시를 사용하고, 계층 상단에는 많은 사용자들에 의해 공유되는 문서를 유지하기 위해 더 크고 강력한 캐시를 사용하자는 것이다.
• 캐시계층이 깊다면 긴 연쇄를 따라 가기 때문에 중간 Proxy는 현저한 성능 저하가 발생할 것이다.

Cache망, Contents 라우팅, 피어링

• 몇몇 아키텍처는 복잡한 Cache망을 만든다.

• 캐시망의 Proxy캐시는 복잡한 방법으로 대화하며, 어떤 부모 or Origin Server(우회하여)와 대화할 것인지 캐시 커뮤니케이션을 동적으로 내린다.

• Cache망 안에서 Contents Routing이 설계된 Cache들은 다음과 같은 동작을 할 수 있다.

  1. URL에 근거하여, 부모 Cache와 Origin Server 중 하나를 동적으로 선택

  2. URL에 근거하여, 특정 부모 Cache를 동적으로 선택

  3. 부모 Cache에게 가기전에 Cache된 사본을 Local에서 탐색

  4. 다른 Cache들이 그들의 Cache에 부분적인 접근을 허용하되, 트랜짓은 허용하지 않는다.

     • 트랜짓

       → 트래픽이 다른 네트워크로 건너가는 것

• HTTP는 형제 Cache를 지원하지 않기 때문에 ICP, HTCP같은 프로토콜을 이용해 HTTP를 확장했다.

  • 형제 Cache

    → 선택적인 피어링을 지원하는 Cache

    • 피어링

      → 인터넷 서비스 제공자끼리 서로 네트워크를 연결하고 트래픽을 교환하는 것을 의미

---

Cache 처리 단계

단계 1 : 요청 받기

• Network Connenction 감지하고, 들어오는 Data를 읽어들인다.

단계 2 : 파싱

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

단계 3 : 검색

• URL을 알아내고 그에 해당하는 로컬 사본이 있는지 검사

단계 4 : 신선도 검사

• 요청이 발생하여 캐시에 접근할 때 해당 캐시가 너무 오래 되면 신선하지 않은 것으로 간주한다.
• 신선하지 않은 것으로 간주하면 서버는 해당 문서에 어떤 변경이 있었는지 서버와 재검사를 실시한다.
• HTTP의 신선도 검사 규칙은 매우 복잡하다.( 뒤에 더 설명할 예정)

단계 5 : 응답 생성

• 캐시된 응답 반환시 해당 응답은 Origin Server에서 보내온 것 처럼 하기 위해 캐시된 응답 헤더를 토대로 응답 헤더를 생성한다.
• Cache는 클라이언트의 HTTP Version에 맞게 반드시 헤더를 적절한게 번역해서 보내야 한다.
• Cache는 신선도 정보를 삽입하며(Cache-Control, Age, Expires 헤더), 종종 Via헤더를 포함시킨다.
• Cache가 Date 헤더를 조정해서는 안된다는 것 을 유의해야 한다.

단계 6 : 전송

• 응답헤더가 준비되면, Cache는 응답을 클라이언트에게 돌려준다.
• Proxy Cache는 클라이언트와의 커넥션을 유지할 필요가 있다.

단계 7 : 로깅

• 스퀴드 로그 포맷(Squid log format)
• 넷스케이프 확장 공용 로그 포멧(Netscape extended common log format)
• 위 두개를 가장 많이 사용하지만 많은 Cache 제품이 커스텀 로그 파일을 허용한다.

---

사본을 Fresh하게 유지하기

문서 만료

• Cache-Control과 Expires라는 특별한 헤더를 이용해 Origin Sever가 각 문서에 유효기간을 붙여 준다.

  • 해당 컨텐츠가 얼마나 오랫동안 신선한 상태로 보일 수 있는지를 나타내 준다.

  • Cache-Control

    → max-age값은 문서의 최대 나이를 정의 (단위: sec)

  • Expires

    → 절대 유효기간을 명시 (요일, 일 월 년, 시간)

    

서버 재검사

• Cache가 Origin Server에게 문서의 변경이 있었는지 물어보는 것을 의미
• 캐시된 문서의 만료 ≠ Origin Server의 Data
• HTTP는 Server가 다음 중 하나를 반환하는 요구를 한다.
  1. “충분히 신선한” 캐시된 사본
  2. Origin Server와 재검사를 했기에 충분히 신선하다고 확신할 수 있는 캐시된 사본
  3. 에러 메시지(재검사를 해야하는 Origin Server의 다운)
  4. 경고 메시지가 부착된 캐시된 사본(부정확시)

조건부 Method와 재검사

• 조건이 참인 경우에만 객체를 반환한다.

• if-Modified-Since: <data>

  

  • 문서가 주어진 날짜 이후로 수정되었다면
    • 요청 메서드를 처리
  • 문서가 주어진 날자 이후로 수정되지 않았다면
    • 304 Not Modified 응답 메시지를 클라이언트에게 반환
    • 효율을 위해 본문은 보내지 않는다.
    • 새 만료날짜는 보낸다.
  • 서버 응답 헤더의 Last-Modified 헤더와 함께 동작한다.

• if-None-Match: <data(ETag)>

  

  • 캐시된 태그가 Server에 있는 문서의 태그와 다를 때만 요청을 처리한다.

    • 문서의 태그 (ETag; Entity Tag)

      → 문서에 대한 일련번호와 같이 동작하는 특별한 태그

  • 만약 Etag가 “v3.0”이었다면 Server는 200 OK 응답으로 새 컨텐츠를 ETag와 함께 보냈을 것이다.

  • 여러개의 엔터티 ETag를 포함시킬 수 있다.

      If-None-Match: "v2.6", "v2.7", "v3.0"

  • 수시로 변경되는 데이터에 적합할듯??

약한 검사기(weak validator)

• 서버는 때때로 모든 캐시된 사본을 무효화시키지 않고 살짝 고치도록 허용 할 수 있다.
• HTTP/1.1은 컨텐츠가 조금 변경되었더라도 “그 정도면 같은 것”이라고 Server가 주장하도록 할 수 있다.
• “W/” 접두사로 약한 검사기를 구분한다.

강한 검사기(strong validator)

• 컨텐츠가 변경될 때마다 바뀐다.

When ETag?? Last-Modified??

• Server가 ETag를 반환한다면 반드시 ETag검사기를 사용해야 한다.
• Server가 Last-Modified를 반환한다면 If-Modified-Since 검사를 사용할 수 있다.

---

Cache-Control

• 문서가 만료되기 전까지 얼마나 오랫동안 유지하게 할지 우선순위대로 나열해보면 Server는,

    Cache-Control: no-store        #헤더를 응답에 첨부할 수 있다.
    Cache-Control: no-cache        #헤더를 응답에 첨부할 수 있다.
    Cache-Control: must-revalidate #헤더를 응답에 첨부할 수 있다.
    Cache-Control: max-age         #헤더를 응답에 첨부할 수 있다.
    Expires:                       #날짜 헤더를 응답에 첨부할 수 있다.
                                   #아무 만료정보도 주지않고, Cache 스스로 결정할 수 있다.

no-store

• 캐시가 검증되지 않은 캐시된 객체로 응답하는 것을 막는다.
• 캐시가 해당 응답 사본을 만드는 것을 금지한다.
• 캐시는 클라이언트에게 “no-store” 응답을 전달하고 나면 객체를 삭제할 것이다.

no-cache

• 캐시가 검증되지 않은 캐시된 객체로 응답하는 것을 막는다.
• “no-cache” 응답은 사실 로컬 캐시 저장소에 저장될 수 있다.
• 단! 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없다!!
• Do-Not-Serve-From-Cache-Without-Revalidation!!!!!!!! ← 이 이름이 더 적합할 것이다….

Pragma: no-cache

• HTTP/1.0+와의 하위호환성을 위해 HTTP/1.1에 포함되어 있다.
• HTTP/1.0애플리케이션에 대응해야 하는 경우가 아니라면 ”Cache-Control: no-cache”를 사용해야 한다.

Max-Age 응답 헤더

• Cache-Control: max-age=”${sec}”
• Cache-Control: s-maxage=”${sec}”
  • ‘ - ‘ 하이픈에 주의해야 한다.
  • max-age처럼 행동하지만 공유된(공용) Cache에만 적용된다.
• Server는 최대 나이먹음(maximum aging)을 0으로 설정함으로써, Cache가 매 접근마다 문서를 캐시하거나 리프레스하지 않도록 요청할 수 있다.

Expires 응답 헤더

• 실제 날짜를 입력하여 만료를 명시한다.

    Expires: "${요일}", "${일}" "${월(영어약자)}" "${년}", "${시간}" "${표준시}"
  
    #예시
    Expires: Fri, 05 Jul 2002, 05:00:00 GMT

• 몇몇 Server는 문서를 항상 만료시키기 위해 Expries: 0 을 넣지만, 문법 위반이며 문제를 야기할 수 있다.

  → 하면 안된다…!!!

Must-Revalidate 응답 헤더

• Cache는 성능 개선을 위해 신선하지 않은(만료된) 객체를 제공하도록 설정할 수 있다.
• Cache가 만료 정보를 엄격하게 따르길 원한다면 Cache-Control: must-revalidate를 명시하면 된다.
• must-revalidate 신선도 검사 시도 시 Origin Server가 사용할 수 없는 상태라면?!
  • 504 GateWay Timeout error를 반환해야 한다.

휴리스틱 만료(heuristic)

• max-age 또는 Expires 중 어느 것도 포함되어 있지 않다면, Cache는 경험적인 방법으로 만료를 계산한다.
• 계산 결과가 24시간보다 크다면, Heuristic Expiration경고(경고 13) 헤더가 응답 헤더에 추가되어야 한다.
• 계산할 수가 없으면 Cache 만료의 기본값을 정할 수 있는데, 신중하게 정해야 한다.

클라이언트 신서도 제약

• 웹 브라우저는 브라우저 or Proxy Cache의 신선하지 않은 컨텐츠를 강제로 갱신시켜 주는 기능이 있다.

• Cache-Control 요청 지시어 요약

  

주의 사항

• 문서 만료는 완벽한 시스템이 아니다!
• 유효기간을 너무 길게 잡아도 너무 짧게 잡아도 문제가 되므로 신중하게 정해야 한다!

---

Cache 제어 설정

Apache’s HTTP Header Control

• Cache Control header를 설정할 수 있는 여러가지 메커니즘을 제공하지만 디폴트는 사용할 수 없게 되어 있어 활성화를 시킬 필요가 있다(어떤 경우에는 Apache 확장 Module이 필요하다).

• mod_headers

  • 개별 헤더들을 설정할 수 있게 해준다.

  • 개별 HTTP 헤더를 설정 할 수 있는 지시어를 이용해 Apache 설정 파일에 설정을 추가 할 수 있다.

  • 개별 컨텐츠에 헤더들을 연결시키기 위해 Apache의 정규식과 필터를 조합하여 사용할 수 있다.

      #어떤 디렉터리의 모든 HTML파일을 캐시되지 않도록 설정하는 예시
      <File *.html>
       Header set Cache-control no-cache
      </File>

• mod_expires

  • Exprires 헤더를 자동으로 생성하는 프로그램 로직을 제공

  • 문서에 마지막으로 접근한 날 or 수정한 날 이후의 일정 시한으로 유효기간을 설정할 수 있게 해준다.

  • 파일 종류별로 따로 설정 할 수 있다.

  • “access plus 1 month”와 같은 편리한 기술 형식을 사용할 수도 있다.

      ExpiresDefault A360
      ExpiresDefault M86400
      ExpiresDefault "access plus 1 week"
      ExpiresByType text/html "modification plus 2 days 6 hours 12 minutes"

• mod_cern_meta

  • HTTP 헤더들의 파일을 특정 객체와 연결시켜준다.
  • 제어하고자 하는 파일에 각각 대응되는 메타파일들을 생성하고, 원하는 헤더를 추가 할 수 있다.

HTTP-EQUIV를 통한 HTML 캐시 제어

• HTML 문서에 HTTP 헤더 정보를 부여 하기 위해 HTML2.0은 태그를 정의 했다.

  
    <!--HTML문서를 Cache하지 않도록 설정-->
    <HTML>
      <HEAD>
        <TITLE>My Document</TITLE>
        <META HTTP-EQUIV="Cache-control" CONTENT="no-cache">
      </HEAD>
      ...
    </HTML>

• 불행히도 이 기능을 지원하는 Web Server나 Proxy는 거의 없다.

• 이 기능은 서버의 부하를 가중시키고, 설정값이 정적이며, HTML을 제외한 다른 타입의 파일은 미지원이니까!

---

Cache Page Exchange Algorithm

FIFO(First In First Out)

• 페이지가 가장 오랫동안 주기억장치에 적재된 시간을 기준으로 교체하는 방식

• 재사용의 가능성이 있지만, 단순히 오래 있었다는 이유만으로 교체하는 단점이 발생

• 그림 설명

  

LFU(Least Frequently Used)

• 가장 적은 횟수를 참조하는 페이지를 교체하는 방식
• 참조될 가능성이 있음에도 가장 적은 것을 교체하므로 최근에 갱신하였어도 교체되는 단점이 발생
  • 오버헤드가 발생할 수 있다는 단점이 발생

LRU(Least Recently Used)

• 가장 오랫동안 참조되지 않은 페이지를 교체하는 방식

• 빠른 액세스 : 최근에 사용한 아이템부터 가장 적게 사용된 아이템까지 정렬이 된다는 장점이 있다.

• 빠른 update : 하나의 아이템에 액세스할 때마다 업데이트되며 O(n)시간복잡도를 갖는 장점이 있다.

• 많은 공간을 차지 : 페이지가 기록될 때마다 주기억장치에 시간을 저장해 두어야하는 단점이 발생

  • n개의 아이템을 가지는 LinkedList(Queue)와 이를 추적하기 위한 HashMap이 필요하다.
  • 오베해드가 발생할 수 있다는 단점이 발생

• 그림 설명