[HTTP] 캐시

[TOC]

07 캐시

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

• 캐시를 사용하는 이유
  • 불필요한데이터 전송을 줄여서, 네트워크 요금으로 이한 비용을 줄여줌
  • 네트워크 병목을 줄여줌. 대역폭을 늘리지 않고도 페이지를 빨리 불러 올 수 있게됨
  • 원 서버에 대한 요청을 줄여줌, 서버에 대한 부담을 줄여준다.
  • 거리로 인한 지연을 줄여줌

• 이번장 주요 쟁점
  • 캐시의 성능을 개선하고 비용을 줄이는 법
  • 캐시 효과 극대화를 위한 위치 선청
  • HTTP가 캐시된 사본을 어떻게 유지하는지
  • 캐시가 다른 캐시나 서버와 상호작용하는 방법

 

 

7.1 불필요한 데이터 전송

• 캐시는 웹 서버의 불필요한 비용을 줄여준다.
• 서버 응답이 캐시에 보관되어 원 서버가 중복해서 트래픽을 주고받는 낭비가 줄어들게 된다.

 

 

7.2 대역폭 병목

• 캐시는 네트워크 병목을 줄여준다.
• 많은 네트워크가 원격 서버보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공함
• 클라이언트가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면 캐시을 성능을 대폭 할 수 있다.

 

 

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

• 많은 사람들이 동시에 웹 문서에 접근할 때 Flash Crowds가 생긴다.
  • 이 결과로 초래된 불필요한 트래픽 급증을 네트워크와 웹 서버의 심각한 장애를 야기함
  • 트래픽 = 서버와 스위치 등 네트워크 장치에서 일정한 시간내에 흐르는데이터의 양
• 캐싱은 이와 같은 현상을 완화시키는데 도움이 된다.

 

 

7.4 거리로 인한 지연

• 대역폭이 문제가 되지 않더라도 거리가 문제가 될 수 있음
  • 모든 네트워크 라우터는 제각각 인터넷 트래픽을 지연시킨다.

• 캐싱으로 문서 전솔 거리를 줄일 수 있다.

 

 

7.5 적중과 부적중

• 이렇게 많은 역할을 하지만 캐시가 세상 모든 문서의 사본을 저장하지는 않는다.
  • 캐시에 요청이 왔을 때 해당하는 문서가 있는것을 캐시 적중(cache hit)이라 한다.
  • 대응하는 사본이 없으면 캐시 부적중(cache miss)라고 부른다.

7.5.1 재검사 (Revalidation)

• 캐시가 가지고 있는 사본이 최신인지 서버를 통해 때때로 점검해야 한다.
  • 이러한 신선도 검사를 HTTP 재검사라 한다.

• 캐시는 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 한다.

• 캐시는 캐시된 사본의 재검사가 필요할 때 원서버에 작은 재검사 요청을 보냄
  • 콘텐츠가 변경되지 않았다면 304 Not Modified 응답을 보냄
  • 이를 재검사 적중 혹은 느린 적중이라 함

• If-Modified-Since 헤더를 통해 캐시된 시간 이후에 변경된 경우에만 사본을 받을 수 있다.
  • 서버 콘텐츠가 변경되지 않은경우
    • 서버는 클라이언트에 304 Not Modified를 보냄
  • 서버 콘텐츠가 변경된 경우
    • 캐시된 사본과 다르면 콘텐츠 전체와 함께 HTTP 200 OK 응답을 보낸다.
  • 객체가 삭제된 경우
    • 404 Not Found 응답과 함께 캐시의 사본을 삭제함

7.5.2 적중률

• 캐시가 요청을 처리하는 비율
• 적중률은 0부터 1까지의 값 혹은 퍼센트로 표현한다.
• 40% 정도면 웹 캐시로 괜찮은 편이다.

7.5.3 바이트 적중률

• 캐시를 통해 제공된 모든 바이트의 비율을 표현함
• 이 측정값은 트래픽이 절감된 정도를 포착해낸다.
• 바이트 단위 적중률은 얼마나 많은 바이트가 인터넷으로 나가지 않았는지 보여줌
  • 바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.

7.5.4 적중과 부적중의 구별

• HTTP는 클라이언트에 캐시 적중인지 원서버 접근인지 알려줄 수 없음
• Date 헤더값을 통해 응답의 생성일이 더 오래되었다면 클라이언트는 응답이 캐시된 것임을 알 수 있다.

 

 

7.6 캐시 토폴로지

• 한 명에게만 할당된 캐시를 개인 전용 캐시라 부른다.
• 공유된 캐시는 공욕 캐시라고 불린다.

7.6.1 개인 전용 캐시

• 혼자 쓰는거니까 작고 저렴할 수 있다.
• 웹브라우저는 개인 전용 캐시를 내장하고 있음
• 대부분의 브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시 해놓음

7.6.2 공용 프록시 캐시

• 공용 캐시는 캐시 프록시 서버 혹은 더 흔히 프록시 캐시라고 불리는 특별한 종류의 공유된 프록시 서버다.
• 프록시 캐시는 로컬 캐시에서 문서를 제공하거나, 혹은 사용자의 입장에서 서버에 접근함
• 여러 사용자가 접근하므로 불필요한 트래픽을 줄일 수 있는 더 많은 기회가 있음

7.6.3 프록시 캐시 계층들

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

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

• 몇몇 네트워크 아키텍처는 단순한 캐시 계층 대신 복잡한 캐시망을 만듦
• 캐시망 안에서의 콘텐츠 라우팅을 위해 설계된 캐시들은 다음의 일을 한다.
  • URL에 근거하여 부모 캐시와 원 서버중 하나를 동적으로 선택
  • URL에 근거하여 특정 부모 캐시를 동적으로 선택
  • 부모 캐시에게 가기 전에, 캐시된 사본을 로컬에서 찾음
  • 다른 캐시들이 그들의 캐시된 콘텐츠에 부분적으로 접근할 수 있도록 허용하되, 캐시를 통한 인터넷 트랜짓은 허용하지 않음

 

 

7.7 캐시 처리 단계

• 총 일곱단계로 이루어져 있음

• 1. 요청 받기 : 네트워크로부터 도착한 요청 메시지 읽음
  2. 파싱 : 메시지를 파싱하여 URL과 헤더들을 추출
  3. 검색 : 로컬 복사본이 있는지 검사하고 사본이 없으면 사본을 받아옴
  4. 신선도 검사 : 신선하지 않으면 서버에 물어봄
  5. 응답 생성 : 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지 만듦
  6. 발송 : 네트워크를 통해 응답을 클라이언트에게 돌려줌
  7. 로깅 : 선택적으로 캐시는 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남김

• 신선도를 검사하는 방법은

 

 

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

• 캐시된 사본 모두가 서버의 문서와 항상 일치하는 것은 아님
• HTTP는 어떤 캐시가 사본을 갖고 있는지 서버가 기억하지 않더라도, 캐시된 사본이 서버와 충분히 일치하도록 유지할 수 있게 해주는 단순한 메커니즘이 있음
  • 문서 만료와 서버 재검사라 부름

7.8.1 문서 만료

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

7.8.2 유효기간과 나이

• 서버는 응답 본문과 함께 하는 Expires나 Cache-control : max age 헤더를 이용해 유효기간을 명시함
• 두개는 기본적으로같은 일을 하지만 절대 시간은 컴퓨터의 시계가 올바르게 맞추어져 있을 것을 요구함

7.8.3 서버 재검사

• 캐시된 문서의 만료는 원 서버와 다르다는 의미가 아니라 검사할 시간이 되었다는 의미이다.
• 이 검사를 캐시가 원 서버에게 문서가 변경되었는지 여부를 물어볼 필요가 있음을 의미하는 '서버 재검사' 라고 한다.
• 재검사 결과
  • 콘텐츠 변경 -> 새로운 사본을 가져와 저장하고 클라이언트에게 전송
  • 콘텐츠 미변경 -> 새 만료일 + 새 헤더를 통해 갱신

• HTTP 프로토콜은 캐시가 다음 중 하나를 반환하는 적절한 행동을 할 것을 요구함
  • 충분히 신선한 캐시된 사본
  • 원 서버와 재검사되었기 때문에 충분히 신선하다고 확신할 수 있는 캐시된 사본
  • 에러 메시지
  • 경고 메시지가 부착된 캐시된 사본

7.8.4 조건부 메소드와의 재검사

• HTTP의 조건부 메소드는 재검사를 효율적으로 만들어줌
  • 캐시가 서버에게 조건부 GET 요청을 보낼 수 있게 해줌
  • If-Modified_Since : <date>
    • 날짜 재검사 헤더
    • 흔히 IMS 요청으로 불림
    • 서버 응답 헤더의 Last-Modified 헤더와 함께 동작한다.
  • If-None-Match : <tags>
    • 엔티티 태그 재검사
    • 업데이트가 되지만 데이터는 같은 경우(변경시간만 바뀔 경우)
    • 캐시는 엔티티 태그 v2.6을 가지고 있으면 이 태그로 새 객체인지 확인한다.

7.8.7 약한 검사기와 강한 검사기

• 캐시는 캐시된 버전이 서버가 갖고 있는 것에 대해 최신인지 확인하기 위해 엔티티 태그를 사용함
• 이 경우 최근 변경일시와 엔티티 태그 모두 캐시 검사기다
• 약한 검사기
  • 모든 캐시된 사본을 무효화시키지 않고 문서를 살짝 고칠수 있도록 허용하는 경우
  • W/ 가 붙으면 약한 검사기

• 강한 검사기
  • 콘텐츠가 바뀔 때 마다 바뀜

7.8.8 언제 엔티티 태그를 사용하고 언제 Last-Modified 일시를 사용하는가

• HTTP/1.1 클라이언트는 만약 서버가 엔티티 태그를 반환했다면, 반드시 엔티티 태그 검사기를 사용해야 함
• 만약 서버가 Last-Modified 값만을 반환했다면 클라이언트는 If-Modified-Since 검사를 사용할 수 있음
• 두개 다 사용하는 게 좋다.

 

 

7.9 캐시 제어

• HTTP는 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있는 여러 가지 방법을 정의한다.
  • Cache-Control : no -store
  • Cache-Control : no -cache
  • Cache-Control : must-revalidate
  • Cache-Control : max-age
  • Expires
  • 아무 만료 정보도 주지 않고, 캐시가 스스로 휴리스틱한 방법으로 결정하게 할 수 있음

• 이번 절은 캐시를 제어하는 헤더에 대해 설명함

7.9.1 no-cache와 no-store 응답 헤더

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

• no-cache로 표시된 응답은 사실 로컬 캐시 저장소에 저장될 수 있다.
  • 다만 먼저 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없을 뿐이다.
  • 즉 재검사를 하고 클라이언트로 제공해야한다는 것이다.

7.9.2 Max-Age 응답 헤더

• Cache-Control : max-age 헤더는 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간이고, 초로 나타낸다.
• s-maxage 헤더는 공용 캐시에만 적용된다.
• 0으로 설정하면 캐시가 매 접근마다 문서를 캐시하거나 리프레시 하지 않도록 요청 할 수 있음

7.9.3 Expires 응답 헤더

• 초 단위의 시간 대신 실제 만료 날짜를 명시한다.

7.9.4 Must-Revalidate 응답 헤더

• 캐시가 무조건 원 서버와 비교 후 제공하라는 의미이다.
• must-realidate 검사 시 원 서버가 사용할 수 없는 상태면 504 GateWay Timeout Error 반환

7.9.5 휴리스틱 만료

• 응답에 Expires나 max-age 헤더가 없다면 캐시는 경험적인 방법(휴리스틱)으로 최대 나이를 계산함
• 계산 결과 얻은 최대 나이 값이 24시간보다 크다면 Heuristic Expiration 경고 헤더가 응답 헤더에 추가되어야 한다.
• LM 인자 알고리즘
  • 문서가 최근 변경 일시를 포함하고 있다면 사용 가능
  • 최근 변경 일시가 얼마나 자주 바뀌는지에 대한 추정에 사용됨
  • 변경한지 오래됨 -> 자주 안바꿔도 된다.
  • 변경한게 최근임 -> 자주 바꿔줘야함

• 일반적으로 휴리스틱 신서도 유지기간에 상한을 설정하여 지나치게 커지는 것을 막음
  • 보통 1주일이지만 보수적인 사이트는 하루로 설정함

7.9.6 클라이언트 신선도 제약

• 웹 브라우저는 브라우저나 프록시 캐시의 신선하지 않은 콘텐츠를 강제로 갱신시켜주는 리프레시나 리로드 버튼을 갖고 있음
• 클라이언트는 Cache-Control 요청 헤더를 사용하여 만료 제약을 엄격하게 하거나 느슨하게 할 수 있음

7.9.7 주의할 점

• 만약 개발자가 잘못해서 유효기간을 까마득한 미래로 설정해버린다면, 만료되기 전까지는 그 문서에 대한 어떤 변경도 캐시에 반영되지 않을 것이다.

 

 

7.10 캐시 제어 설정

• 웹 서버들은 캐시 제어 만료 HTTP 헤더들을 설정하는 서로 다른 메커니즘을 제공한다.

7.10.1 아파치로 HTTP 헤더 제어하기

• 아파치 웹 서버는 HTTP 캐시 제어 헤더를 설정할 수 있는 여러 가지 메커니즘을 제공한다.

• mod_headers
  • 이 모듈은 개별 헤더들을 설정할 수 있게 해줌
  • 이 모듈이 로드되면, 개별 HTTP 헤더를 설정할 수 있는 지시어를 이용해 아파치 설정 파일에 설정을 추가 할 수 있음
  • 개별 콘텐츠에 헤더들을 연결시키기 위해 아파치의 정규식과 필터를 조합하여 사용할 수 있음
  • <-- 어떤 디렉토리의 모든 HTML 파일을 캐시되지 않도록 설정하는 예 /--> <Files *.html> Headers set Cache-control no-cahce </Files>

• mod-expires
  • mod_expires 모듈은 적절한 만료 날짜가 담긴 Expires 헤더를 자동으로 생성하는 프로그램 로직을 제공
  • 이 모듈은 문서에 마지막으로 접근한 날 혹은 수정한 날 이후의 일정 시한으로 유효기간을 설정하게 해줌
  • 파일 종류별로 다른 만료 날짜로 설정 가능

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

• mod_cern_meta
  • HTTP 헤더들의 파일을 특정 객체와 연결시켜주는 모듈이다.
  • 메타파일에 원하는 헤더를 추가하면 됨

 

 

7.12 캐시와 광고

• 캐시는 사용자를 도와 더 좋은 경험을 제공하고, 또한 네트워크 사업자들이 트래픽을 줄일 수 있도록 도와준다.

7.12.1 광고 회사의 딜레마

• 콘텐츠 제공자들은 아마 캐시를 좋아할 것이다.
• 캐시가 모든 곳에 있으면 콘텐츠 제공자는 수요를 견디기 위해 대용량 멀티프로세서 웹 서버를 살 필요가 없을 것이다
• 그러나 캐싱이 완벽하게 작용하면 원 서버는 HTTP 접근을 전혀 수신하지 않기 때문에 광고를 얼마나 많이 봤는지 광고 회사는 알 수 없게 된다.

7.12.2 퍼블리셔의 응답

• 광고회사들은 캐시가 광고 시청 수를 가로채지 못하도록 모든 종류의 '캐시 무력화' 기법을 사용함
• 그들은 광고를 CGI 게이트웨이를 통해 제공함
  • 매 접근마다 광고URL을 고쳐 슴

• 이상적으로는, 콘텐츠 제공자는 캐시가 그들의 트래픽을 흡수하도록 하고, 캐시는 광고를 얼마나 봤는지 알려주어야 한다.
  • 모든 접근에 대해 원 서버와 재검사 하도록 캐시를 설정하면 가능하다.
  • 캐시 적중만 확인하고 본문 데이터는 건들지 않는다.
  • 물론 이는 트랜잭션을 느리게 한다.

7.12.3 로그 마이그레이션

• 이상 적인 해결책 하나는 서버로 요청이 가지 않도록 하는것
• 캐시는 모든 적중의 로그를 유지할 수 있다.
• 그러나 적중 로그는 크기 때문에 옮기기 어려움
• 콘텐츠 제공자별로 구분도 되지 않음

 

쿠키가 광고에 미치는 영향

https://brunch.co.kr/@99101204/28