캐시

ngh·2022년 12월 12일
0

HTTP

목록 보기
2/3

캐시의 장점

불필요한 데이터 전송 방지

  • 캐시가 없는경우, 여러 클라이언트가 서버에 데이터를 요청하면, 서버는 똑같은 데이터를 여러번 전송한다.
    캐시를 사용하면, 서버가 캐시에 데이터를 한번만 전송하고 클라이언트들은 캐시에서 데이터를 가져가기 때문에 서버에서 전송하는 데이터 횟수가 줄어든다.

대역폭 병목 해결

  • 일반적으로 로컬 네트워크 대역폭이 WAN 보다 넓다.
    원격 서버에서 데이터를 가져올때, 최종 속도는 대역폭이 좁은 WAN의 속도가 된다.
    캐시를 사용하여 데이터를 로컬 네트워크쪽에 저장하면, WAN을 사용하지 않고 LAN의 넓은 대역폭을 사용할 수 있다.

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

  • 갑작스런 사건 (뉴스 속보, 스팸 메일 등) 으로 인해 트래픽이 급증하면 서버와 네트워크에 장애가 발생한다.
    캐시를 사용하면, 웹 서버에 직접 트래픽이 몰리지 않기 때문에 갑작스런 트래픽 급증에 대처할 수 있다.

거리로 인한 지연을 줄임

  • 거리가 멀면 지연이 발생한다.
    빛의 속도(300000km/s)로 20개의 이미지가 있는 웹 페이지를 커넥션 4개로 미국에서 일본으로 데이터를 전송하면 약 10800km에 600ms가 걸린다.
    캐시로 거리를 줄이면 거리에 의한 지연이 줄어든다.

캐시 처리 방식

적중

  • 캐시에 사본이 있을때, 캐시에서 클라이언트에게 사본 전달

부적중

  • 캐시에 사본이 없을때, 서버에서 클라이언트에게 데이터 전달

재검사

  • 캐시에 저장된 사본이 최신 버전인지 서버에 물어봄
  • 일반적으로 사본이 충분히 오래되었을 경우, 재검사를 함
  • 서버에서 사본이 변경되지 않았다고 판단하면, 304 Not Modified 응답 리턴
  • 서버에서 사본이 변경되었다고 판단하면, 서버가 데이터 전달
  • 서버에서 사본이 삭제되었다고 판단하면, 404 Not Found 전달 후 캐시의 사본 삭제

적중률

적중률 (문서 적중률)

  • 캐시가 요청을 처리하는 비율
  • 0%~100%
  • 데이터가 얼마나 자주 변경되거나 개인화 되는지, 캐시 사용자들의 관심사 등에 의해 적중률이 변경된다.
  • 40%면 웹 캐시로 괜찮은 수준
  • 외부로 나가는 트랜잭션을 얼마나 감소시켰는지 확인 가능
    -> 문서 적중률을 개선하면 전체 대기시간(지연)을 줄일 수 있다.

바이트 적중률

  • 캐시를 통해 제공된 모든 바이트의 비율
  • 문서의 크기가 각각 다르기 때문에, 큰 문서가 적중이 많이 될수록 트래픽 감소에 더 기여한다.
    바이트 적중률로 트래픽이 절감된 정도를 알 수 있다.
    -> 바이트 적중률을 개선하면 대역폭을 절약할 수 있다.

클라이언트에서 적중, 부적중 판별 방법

  • 서버는 클라이언트에게 응답이 캐시 적중인지 부적중인지를 알려주지 않는다.
  • 클라이언트는 아래 두가지 방법으로 캐시 적중인지, 부적중인지를 추정해야 한다.
1. Date 헤더 값을 현재 시각과 비교하여 응답 생성일이 오래되었는지 확인 (서버가 설정하는 헤더)
2. Age 헤더 값으로 응답이 얼마나 오래되었는지 확인 (캐시가 설정하는 헤더)

캐시 토폴로지

개인 전용 캐시

  • 웹 브라우저가 내장
  • 개인용 컴퓨터의 디스크와 메모리에 저장

공용 프락시 캐시

  • 캐시 프락시 서버에 저장
  • 여러 클라이언트가 공용으로 사용
  • 여러 클라이언트의 관심사를 캐시

프락시 캐시 계층

  • 캐시를 계층적으로 만들어서 자식계층이 처리하지 못한 캐시를 부모가 처리

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

복잡한 캐시망을 만들어서 아래 조건들로 캐시를 가져오도록 할 수 있다.

  • URL에 따라 부모 캐시, 원 서버 중 하나를 동적으로 선택
  • URL에 따라 부모 캐시 동적으로 선택
  • 부모 캐시로 가기 전, 사본을 로컬에서 검색
  • 다른 캐시들이 그들의 캐시된 콘텐츠에 부분적으로 접근할 수 있게 허용
    그들의 캐시를 통한 인터넷 트랜짓(트래픽이 다른 네트워크로 건너감)은 불허
  • 선택적인 피어링을 지원하는 캐시를 형제 캐시라고 부른다.

캐시 처리 단계

  1. 요청 받기

    • 네트워크에서 도착한 요청 메시지를 받는다
  2. 파싱

    • 요청 메시지를 파싱한다.
      헤더를 파싱하여 조작하기 쉬운 자료구조에 담는다.
  3. 검색

    • URL로 사본이 어디에 있는지 검사한다.
      로컬 메모리, 디스크, 근처의 다른 컴퓨터에서 찾는다.
      사본이 없으면 원서버나 부모 프락시에서 가져온다.
  4. 신선도 검사

    • 사본이 너무 오래되었는지 검사한다.
      너무 오래되었다면, 원서버에 재검사를 요청한다.
  5. 응답 생성

    • 응답 헤더를 생성한다.
    • 캐시 신선도 정보(Cache-control, Age, Expires 헤더), via 를 추가한다.
    • 클라이언트가 HTTP/1.1 응답을 원하는데 서버가 HTTP/1.0 응답을 줬다면, 캐시서버에서 HTTP/1.1로 맞춰서 변환을 해준다.
  6. 전송

    • 응답을 클라이언트에게 돌려준다.
  7. 로깅

    • 적중, 부정중 횟수등 캐시 사용에 대한 통계를 저장
    • URL, 요청 종류 등의 로그 파일 저장

사본의 신선도 관리

문서 만료

  • Cache-Control, Expires 헤더로 원 서버가 각 문서에 유효기간을 붙일 수 있다.
Expires: Wed, 21 Oct 2015 07:28:00 GMT
Cache-control: no-cache
  • 유효기간이 만료됬으면, 무조건 원 서버에 재검사 요청을 해야한다.

유효기간, 나이

HTTP 버전헤더설명
HTTP/1.0+ExpiresExpires: Wed, 21 Oct 2015 07:28:00 GMT
만료일
HTTP/1.1Cache-ControlCache-Control: max-age=1000
처음 생성된 시각부터 유효시간(초)
  • 위 두 헤더로 유효기간을 설정할 수 있다
    유효기간이 지나면 재검사를 해야한다.

서버 재검사

  • 문서가 만료되었을 경우, 원 서버에게 문서가 변경되었는지 여부를 물어보는것을 재검사 라고 한다.
  • 컨텐츠가 변경된 경우, 캐시의 사본 교체
  • 컨텐츠가 동일한 경우, 캐시의 헤더 교체(만료일 등)

조건부 메서드로 재검사

  • 조건부 GET 요청으로 신선도 검사와 객체를 받는것을 동시에 처리할 수 있다.
  • 조건부 GET 요청의 헤더로 아래 값들을 설정해서 어떤 조건일 때, 객체를 받는지 설정할 수 있다.
헤더설명
If-Modified-Since: <date>date 이후로 변경된 적이 있으면 객체 본문을 전송
변경 안됬으면, 304 Not Modified 리턴
If-None-Match: <Tag>tag가 서버 문서의 태그와 다르면 객체 본문을 전송
변경 안됬으면, 304 Not Modified 리턴
변경된 내용이 사소한 것(주석)이거나 동일한 데이터로 새로고침된 문서의 경우,
서버에서 최근 변경일시를 모르는경우,
1초 간격으로 갱신되는 문서인 경우 If-Modified-Since 보다 If-None-Match가 더 적절하다.

캐시 제어

서버가 응답 헤더를 설정해서 제어하는 방법

헤더설명
Cache-Control: no-store캐시가 사본을 만드는것을 금지
Cache-Control: no-cache캐시가 무조건 재검사를 해야함
Pragma: no-cacheHTTP/1.0 대응용 헤더
대응할 필요 없으면 Cache-Control: no-cache 사용
Cache-Control: max-age=1000서버에서 문서를 받은지 설정된 시간만큼 경과했으면 재검사
Cache-Control: s-maxage=1000max-age와 동일하나 공용 캐시에만 적용됨
Expires: Wed, 21 Oct 2015 07:28:00 GMT사본 만료 날짜 (deprecated됨)
Cache-Control: must-revalidate캐시가 만료일이 지났다면 무조건 재검사를 해야함

휴리스틱 만료

  • Cache-Control: max-age, Expires 둘 다 없는 경우 캐시는 휴리스틱 방법으로 수명을 계산한다.
  • LM인자 알고리즘: 문서가 변경된지 오래됬으면, 갑자기 바뀔 가능성이 없다고 보고 캐시에 더 오래 보관.
    문서가 최근에 변경되었으면, 자주 변경될 것으로 보고 짧은 기간만 캐시에 보관
  • 휴리스틱 신선도 유지기간의 상한은 보통 1일 ~ 1주일

클라이언트가 요청 헤더를 설정해서 제어하는 방법

헤더설명
Cache-Control: max-stale
Cache-Control: max-stale = <s>
캐시가 신선하지 않은 문서를 자유롭게 제공할수 있게 함
클라이언트는 <s> 만큼 지난 문서도 받아들임
Cache-Control: min-fresh = <s>클라이언트는 지금부터 <s> 초 후까지 신선한 문서만 받음
Cache-Control: max-age=<s>캐시는 <s> 초보다 오랫동안 캐시된 문서를 반환할 수 없음
Cache-Control: no-cache
Pragma: no-cache
캐시가 무조건 재검사를 해야함
Cache-Control: no-store캐시가 사본을 삭제해야함
Cache-Control: only-if-cached클라이언트는 사본만 받음

Reference

  • 데이빗 고울리, 브라이언 토티, 마조리 세이어, 세일루 레디, 안슈 아가왈, ⌜HTTP 완벽 가이드⌟, 756p
profile
Java/Kotlin Back-end Developer

0개의 댓글