2019년 9월 30일

캐시의 개념과 장점

캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다. 웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면, 그 문서는 원서버가 아니라 캐시로부터 제공된다.

불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다.
캐시는 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 된다.
캐시는 원서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다.
캐시는 거리로 인한 지연을 줄여준다. 페이지를 먼 곳에서 불러올수록 시간이 많이 거린다.

1. 불필요한 데이터 전송

캐시를 이용하면, 첫번째 서버 응답은 캐시에 보관된다.
캐시된 사본이 뒤이은 요청들에 대한 응답으로 사용될 수 있기 때문에, 원서버가 중복해서 트래픽을 주고받는 낭비가 줄어들게된다.

2. 대역폭 병목

많은 네트워크가 원격 서버보다 로컬 네트워크 클라에 더 넓은 대역폭을 제공한다.
클라들이 서버에 접근할 때의 속도는, 그 경로에 있는 가장 느린 네트워크의 속도와 같다.
만약 클라가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 성능을 개선할 수 있을 것이다.

3. 갑작스런 요청 쇄도

갑작스런 요청 쇄도에 대처하기 위해 특히 중요하다.
트래픽 급증은 네트워크와 웹서버의 심각한 장애를 야기시킨다.

음?

4. 거리로 인한 지연

대역폭이 문제가 되지 않더라도, 거리가 문제될 수 있다.
기계실 근처에 캐시를 설치하여 문서가 전송되느 거리를 수천 킬로미터에 수십미터로 줄일 수 있다.

보스턴과 샌프란시스코 사이의 거리는 약 4,400km이다. 어떤 웹페이자가 20개의 작은 이미지를 포함하고 있는데, 모두가 샌프란시스코에 있는 한 서버에 들어있다고 가정해보자. 보스턴에 있는 클라가 서버로 동시에 4개의 커넥션을 열고, 그 커넥션을 유지한다면, 다운 받을 때의 빛의 속도로 인한 지연은 거의 1/4초가 된다.(240밀리초) 만약 서버가 보스턴에서 더 멀리 10,800km 떨어진 도쿄라면 600밀리초로 커진다.

5. 적중과 부적중

캐시가 모든 문서의 사본을 저장하지는 않는다.
캐시 요청이 도착했을때, 사본이 있다면: 요청이 처리될 수 있다. 캐시 적중 cache hit 사본이 없다면: 원서버로 전달되기만 한다. 캐시 부적중 cache miss

5.1 재검사 Revalidation (신선도 검사)

원서버 콘텐츠는 변경될 수 있기 때문에, 캐시는 반드시 그들이 갖고 있는 사본이 여전히 최신인지 서버를 통해 점검해야한다.!!
이러한 신선도 검사를 HTTP 재검사라 부른다.
1. HTTP는 서버로부터 전체 객체를 가져오지 않고도, 콘텐츠가 여전히 신선한지 빠르게 검사할 수 있는 특별한 요청을 정의했다.
대부분의 캐시는 클라가 사본을 요청하였으며, 그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 한다.
콘텐츠가 변경되지 않았다면, 서버는 아주 작은 304 Not Modified 응답을 보낸다.

재검사 적중 (느린 적중)

사본이 유효함을 알게된 캐시는 즉각 사본이 신선하다고 임시로 다시 표시한 뒤, 사본을 클라에게 제공한다.
순수 캐시 적중보다 느리다. 원 서버와 검사를 할 필요가 있기 때문이다.
캐시 부적중보다는 빠르다. 서버로부터 객체 데이터를 받아올 필요가 없기 때문이다.

`If-Modified-Since` 헤더

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

오늘은 9월 30일이다. 27일에 캐시되어있던 파일이며, 해당 시간 이후의 사본의 신선도를 확인한다.

If-Modified-Since 요청이 서버에 도착했을 때 일어날 수 있는 3가지 상황

서버 콘텐츠가 변경되지 않을 경우
서버 콘텐츠가 변경된 경우
객체가 삭제된 경우

재검사 적중: 만약 서버객체가 변경되지 않았다면, 서버는 클라에게 작은 HTTP 304 Not Modified 응답을 보낸다.

재검사 부적중: 만약 서버 객체가 캐시된 사본과 다르다면, 서버는 콘텐츠 전체와 함께 평범한 HTTP 200 OK 응답을 클라에게 보낸다.
객체 삭제: 404 Not Found 응답을 돌려보내며, 캐시는 사본을 삭제한다.

문서적중률과 바이트 단위 적중률은 둘다 캐시 성능에 대한 유용한 지표다.

문서 적중률은 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지 보여준다.
- 트랜잭션은 고정된 소요 시간을 포함하게 되는데, 시간이 길 수도 있기 때문에, 문서 적중률을 개선하면 전체 대기시간이 줄어든다.
바이트 단위 적중률은 얼마나 많은 바이트가 인터넷으로 나가지 않았는지 보여준다.
- 바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.

5.2 적중률 (문서 적중률)

캐시가 요청을 처리하는 비율을 캐시 적중률 혹은 문서 적중률이라고 부르기도 한다.

적중률은 0 ~ 1 값으로 되어 있다. 흔히 퍼센트로 표현된다.
캐시 부적중: 0% 캐시 적중: 100%
캐시 관리자는 캐시 적중률이 100%에 근접하게 되는 것을 좋아할 것이다.

실제 적중률은

캐시가 얼마나 큰지 캐시 사용자들의 관심사가 얼마나 비슷한지 캐시된 데이터가 얼마나 자주 변경되거나 개인화되는지 캐시가 어떻게 설정되어 있는지에 달려있다.
적중률은 예측하기 어려운 것으로, 악명이 높지만 오늘날 적중률 40%면 웹 캐시로 괜찮은 편이다.

5.3 바이트 적중률

바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현한다.
몇몇 큰 객체는 덜 접근되지만, 그 크기 때문에 전체 트래픽에는 더 크게 기여한다.
어떤사람은 이러한 이유로 바이트 단위 적중률 측정값을 더 선호한다.
- 특히 트래픽의 모든 바이트에 요금을 매기려는 사람들
이 측정값은 트래픽이 절감된 정도를 포착해낸다.
바이트 단위 적중률 100%는 모든 바이트가 캐시에서 왔으며, 어떤 트래픽도 인터넷으로 나가지 않았음을 의미한다.

5.4 적중과 부적중의 구별

1. HTTP는 클라에게 응답이 캐시적중이었는지, 원서버 접근인지 말해줄 수 있는 방법을 제공하지 않는다
두가지 경우 모도 200 OK가 될 것이다.
어떤 상용 프락시 캐시는 캐시에 무슨일이 일어났는지 설명하기 위해 Via 헤더에 추가 정보를 붙인다.

클라가 응답이 캐시에서 왔는지 알아내는 한가지 방법은 Date 헤더를 이용하는 것이다.

응답의 Date 헤더값을 현재 시각과 비교하여, 응답의 생성일이 더 오래되었다면, 클라는 응답이 캐시된 것임을 알아낼 수 있다.
클라가 캐시된 응답을 감지하는 또다른 방법은, 응답이 얼마나 오래되었는지 말해주는 Age 헤더를 이용하는 것이다.

6. 캐시 토폴로지

캐시는 한명의 사용자에게만 할당 될 수도 있고 수천명의 사용자들 간에 공유될 수도 있다.

토폴로지(영어: topology, 문화어: 망구성방식)는 컴퓨터 네트워크의 요소들(링크, 노드 등)을 물리적으로 연결해 놓은 것, 또는 그 연결 방식을 말한다. 로컬 영역 네트워크(LAN)은 물리적 토폴로지와 논리적 토폴로지 둘 다 보여 줄 수 있는 네트워크의 한 예이다. 출처

토폴로지 종류
- 버스 토폴로지
- 스타 토폴로지
- 링 토폴로지
- 트리 토폴로지

6.1 개인 전용 캐시

개인 전용 캐시는 작고 저렴할 수 있다.
웹 브라우저는 개인 전용 캐시를 내장하고 있다.
브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고 사용자가 캐시 사이즈의 설정을 수정할 수 있도록 허용한다.

6.2 공용 프락시 캐시

공용 캐시는 캐시 프락시 서버 혹은 더 흔한 프락시 캐시라고 불리는 특별한 종류의 공유된 프락시 서버다.
프락시 캐시는 로컬 캐시에서 문서를 제공하거나, 혹은 사용자 입장에서 서버에 접근한다.
공용캐시에는 여러 사용자가 접근하기 때문에, 불필요한 트래픽을 줄일 수 있는 더 많은 기회가 있다.
각 개인 전용 캐시는 같은 문서를 네트워크를 거쳐 여러번 가져온다.
공용 캐시에서, 캐시는 자주 찾는 객체를 단 한번만 가져와 모든 요청에 대해 공유된 사본을 제공함으로써 네트워크 트래픽을 줄인다.
수동 프락시를 지정하거나, 프락시 자동설정 파일을 설정함으로써, 브라우저가 프락시 캐시를 사용하도록 설정할 수 있다.
- 인터셉트 프락시를 사용함으로써 브라우저의 설정 없이 HTTP 요청이 캐시를 통하도록 강제할 수 있다.

6.3 프락시 캐시 계층들

작은 캐시에서 캐시 부적중이 발생했을 때, 더 큰 부모 캐시가 그 걸러 남겨진 트래픽을 처리하도록 하는 계층을 만드는 방식이 합리적이 경우가 많다.
클라 주위에는 작고 저렴한 캐시를 사용하고, 계층 상단에는 많은 사용자들에 의해 공유되는 문서를 유지하기 위해 더 크고 강력한 캐시를 사용하자는 것이다.
캐시 계층이 깊다면 프락시 연쇄가 길어지므로, 각 중간 프락시는 현저한 성능 저하가 발생할 것이다.

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

잘 모르겠다.

캐시망

캐시망의 프락시 캐시는 어떤 부모 캐시와 대화할 것인지, 아니면 요청이 캐시를 완전히 우회해서 원 서버로 바로 가도록 할 것인지에 대한 캐시 커뮤니케이션 결정을 동적으로 내린다.

콘텐츠 라우팅

캐시망 안에서의 콘텐츠 라우팅을 위해 설계된 캐시들은 다음에 나열된 일들을 모두 할 수 있을 것이다.

URL에 근거하여, 부모 캐시와 원서버 중 하나를 동적으로 선택한다.
URL에 근거하여, 특정 부모 캐시를 동적으로 선택한다.
부모 캐시에게 가기 전에, 캐시된 사본을 로컬에서 찾아본다.
다른 캐시들이 그들의 캐시된 콘텐츠에 부분으로 접근할 수 있도록 허용하되, 그들의 캐시를 통한 Internet transit은 허용하지 않는다.