캐시의 개념과 장점

캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 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 재검사라 부른다.

• HTTP는 서버로부터 전체 객체를 가져오지 않고도, 콘텐츠가 여전히 신선한지 빠르게 검사할 수 있는 특별한 요청을 정의했다.

• 대부분의 캐시는 클라가 사본을 요청하였으며,
  그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 한다.

• 콘텐츠가 변경되지 않았다면, 서버는 아주 작은 304 Not Modified 응답을 보낸다.

재검사 적중 (느린 적중)

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

If-Modified-Since 헤더

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

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

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

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

---

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

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

---

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

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

5.2 적중률 (문서 적중률)

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

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

실제 적중률은

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

5.3 바이트 적중률

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

---

5.4 적중과 부적중의 구별

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

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

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

---

6. 캐시 토폴로지

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

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

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

6.1 개인 전용 캐시

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

6.2 공용 프락시 캐시

• 공용 캐시는 캐시 프락시 서버 혹은 더 흔한 프락시 캐시라고 불리는 특별한 종류의 공유된 프락시 서버다.

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

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

• 각 개인 전용 캐시는 같은 문서를 네트워크를 거쳐 여러번 가져온다.

• 공용 캐시에서, 캐시는 자주 찾는 객체를 단 한번만 가져와
  모든 요청에 대해 공유된 사본을 제공함으로써 네트워크 트래픽을 줄인다.

• 수동 프락시를 지정하거나, 프락시 자동설정 파일을 설정함으로써, 브라우저가 프락시 캐시를 사용하도록 설정할 수 있다.

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

6.3 프락시 캐시 계층들

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

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

잘 모르겠다.

캐시망

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

콘텐츠 라우팅

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

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

형제 캐시

• 선택적인 피어링을 지원하는 캐시는 형제 캐시라고 불린다.
• HTTP는 형재 캐시를 지원하지 않기 때문에, 사람들은 인터넷 캐시 프로토콜(ICP)이나
  하이퍼텍스트 캐시 프로토콜 HTCP같은 프로토콜을 이용해 HTTP를 확장했다.

---

• HTTP 완벽가이드 책을 보고 이해한 내용을 정리 한 글입니다.

---

참고자료

1. 네트워크 토폴리지