HTTP 박살내기 프로젝트 - 6 | 캐시

* 본 게시글은 <HTTP 완벽 가이드> 책을 읽고 정리한 글입니다.

 

# 캐시

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

- 웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다.

 

<캐시 사용의 이점>

1. 불필요한 데이터 전송을 줄인다.

2. 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지 로딩 속도 개선

3. 캐시는 원 서버에 대한 요청을 줄여준다

4. 거리로 인한 지연을 줄여준다

 

 

[#1. 불필요한 데이터 전송을 줄인다]

복수의 클라이언트가 자주 쓰이는 원 서버 페이지에 접근할 때, 서버는 같은 문서를 클라이언트에게 각각 전송하게 된다

- 똑같은 바이트, 똑같은 데이터가 네트워크를 통해 반복적으로 이동한다.

-> 불필요한 중복 전송은 네트워크 대역폭을 잡아먹고 전송을 느리게 만들며 웹 서버에 부하를 준다.

=> 캐시를 사용하면, 캐시된 사본이 요청에 대한 응답으로 사용됨으로써 원 서버의 트래픽 낭비를 줄인다.

 

[#2. 네트워크 병목을 줄인다]

LAN(이더넷) 속도에 비해 WAN의 속도가 떨어진다.

-> 원 서버까지 가지 않고 이더넷 내부에 있는 캐시로부터 데이터를 가져온다면 성능향상에 큰 도움이 된다.

 

[#3. 갑작스런 요청 쇄도에 유연한 대처]

똑같은 페이지 요청이 원 서버로 갑자기 쏟아져 들어올때, 해당 페이지를 캐시에 보관해두면 원 서버까지 요청이 가지않고 캐시 선에서 처리할 수 있기때문에 요청 쇄도에 대처가 가능하다.

 

[#4. 거리로 인한 지연 감소]

상식적으로 태평양 넘어 대륙 넘어 직접 갖고오는 것보다 근처에서 가져오는게 훨씬 더 빠르다

 

 

# 캐시 적중과 부적중

캐시 적중(Cache-hit) - 캐시 내부에 요청에 대응하는 사본이 딱 있다! 아싸! -> 그거 바로 전달해주고 땡

캐시 부적중(Cache-miss) - 캐시 내부에 요청에 대응하는 사본이 없다. 꽝 -> 요청을 서버로 넘긴다

 

<캐시 재검사, Revalidation>

원 서버의 콘텐츠가 변경될 수 있기 때문에, 캐시는 반드시 캐싱된 사본이 최신 파일을 유지하고 있는지 체크해야한다.

- 이러한 신선도 검사를 "HTTP 재검사"라 부른다.

- HTTP는 서버로부터 전체 파일을 다 가져오지 않고도 콘텐츠가 최신을 유지하고 있는지 확인할 수 있는 방법이 있다.

 

대부분의 캐시는 클라이언트가 사본을 요청하였을때, 그 사본이 재검사가 필요할 정도로 오래되었을 경우에만 재검사를 수행한다.

- 재검사가 필요할 때, 캐시는 원 서버에 작은 재검사 요청을 보낸다. (If-Modified-Since 헤더)

-> 콘텐츠가 변경되지 않았을 경우(신선한 경우)에는 "304, Not Modified" 응답을 보낸다

-> 캐시는 자기 사본이 신선하다는 것을 확인, 클라이언트에게 바로 사본을 보낸다.

=> 이를 "재검사 적중", "느린 적중"이라 부르며, 순수 캐시 적중보다는 약간 느리다.

 

* If-Modified-Since 헤더

- 서버에게 보내는 GET 요청에 추가. 

- 캐시된 시간 이후에 변경된 경우에만 사본을 보내주세요

 

#1. 재검사 적중하는 경우 - 304, Not Modified 응답을 받는다

#2. 재검사 부적중하는 경우 - 200, OK 응답을 받고 원 서버로부터 콘텐츠 전체를 내려받는다.

#3. 객체가 존재하지 않는 경우 - 404, Not Found 응답을 받고 캐시는 사본을 삭제한다.

 

(a) hit  (b) miss

캐시가 요청을 처리해내는 비율을 "캐시 적중률"이라고 한다. (0: 모두 miss ~ 1: 모두 hit)

- 캐시 적중률이 1에 도달하는건 현실적으로 불가능하다. (적중률 40%면 양반이다)

- 문서들이 크기가 모두 같은 것이 아니기때문에, 캐시를 통해 제공된 바이트의 비율을 고려한 "바이트 단위 적중률"도 평가에 사용한다.

 

* HTTP는 응답이 캐시에게 받아온건지, 원 서버에게 받아온건지 구분할 수 있는 방법이 없다.

(모두 200 OK 헤더만 전송될 뿐)

이를 알아내기 위해서, Date 헤더를 이용하는 방법이 있다. (Age 헤더를 이용하는 방법도 있다)

- 현재 시간보다 응답 메시지의 Date 헤더값이 더 오래됐다면 응답이 캐시된 것임을 알아낼 수 있다.

 

# 캐시 토폴로지

* 토폴로지(Topology)?

토폴로지는 컴퓨터 네트워크의 요소들(링크, 노드 등)을 물리적으로 연결해 놓은 것, 또는 그 연결 방식을 말한다.
로컬 영역 네트워크 (LAN)은 물리적 토폴로지와 논리적 토폴로지 둘 다 보여 줄 수 있는 네트워크의 한 예이다.
<위키피디아>

 

뭔 소린가 싶은데 그냥 네트워크에서 망형, 스타형, 트리형 이런 배치구조를 의미한다. (네트워크의 구성 형태, 형상)

<개인 전용 캐시> 

- 작고 저렴한 개인 전용 캐시, 웹브라우저에 내장하여 사용된다

개인 전용 캐시

 

<공용 프록시 캐시>

캐시 프록시 서버를 이용한 공용 프록시 캐시. 여러 사용자가 접근하기 때문에 불필요한 트래픽을 줄일 수 있는 기회가 더 많이 있다.

 

캐시는 일반적으로 계층적 구조로 구성한다. (브라우저 캐시 -> 레벨 1 캐시 -> 레벨 2 캐시 -> 원 서버)

- 브라우저 캐시에서 미적중이 났다 -> 레벨 1 캐시로 토스

- 레벨 1 캐시에서 미적중이 났다 -> 레벨 2 캐시로 토스

- 레벨 2 캐시에서 미적중이 났다 -> 원 서버로 토스

(상위 캐시(1->2->...)로 갈수록 더 크고 빵빵함)

 

* 계층적 구조 이외에 복잡한 캐시망 구조를 사용하는 경우도 있음. 

 

# 캐시 처리 단계

 

직접 찍음;;

 

1. 요청 받기 - 캐시는 네트워크로부터 도착한 요청 메시지를 읽는다

2. 파싱 - 메시지를 파싱하여 URL과 헤더를 추출한다

3. 검색 - 로컬 사본이 있는지 검사하고, 없다면 원 서버로부터 받아온다

4. 신선도 검사 - 캐시된 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지 서버에게 물어본다

5. 응답 생성 - 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다

6. 발송 - 캐시는 네트워크를 통해 응답을 클라이언트에게 돌려준다

7. 로깅 - (선택적으로) 로그파일에 트랜잭션 기록을 남긴다.

 

 

# 기타

1. 오래된 캐시는 필요가 없다.

따라서 캐시는 "Cache-Control", "Expires" 헤더를 사용해서 문서에 유효기간을 지정한다.

Cache-Control: max-age ) 문서의 최대 나이를 정의한다. (Cache-Control: max-age=484200) (초)

Expires ) 절대 유효기간을 명시한다 ...  (Expires: Fri, 05 Jul 2002, 05:00:00 GMT)

 

-> 캐시는 매번 신선도 검사를 할 필요 없이 문서가 만료된 경우에만 재검사를 해주면 된다.

 

* 서버의 시간은 각자 살짝 제각각일 수 있기때문에 절대 기간보다는 경과시간을 사용하는 것을 권장한다.

 

 

2. 캐시 무력화 - 객체를 캐싱하는 것을 제한하거나 제공하지 않는다

Cache-Control: no-store
Cache-Control: no-cache
Pragma: no-cache

no-store -> 캐시가 응답의 사본을 만드는 것을 금지한다

no-cache -> 재검사 없이는 캐시에서 클라이언트에게 사본을 제공하지 마라 (HTTP/1.1 이상)

Pragma: no-cache -> HTTP/1.0 호환성을 위해 추가.

 

 

3. 광고와 캐시와의 관계

광고는 대게 사용자가 광고를 볼 때마다 수익이 나는 구조이다.

그런데 캐시가 광고를 캐싱해버려서 원 서버의 광고화면 HTTP 요청을 아예 빨아먹어버리면?

그럼 수익이 안나는걸까?

->

1. 캐시가 광고 시청 수를 가로채지 못하도록 모든 종류의 캐시 무력화 기법을 사용한다

2. 매 접근마다 광고 URL을 고쳐씀으로써 원 서버로 요청이 가게한다

->

이는 결국 광고를 위해 캐싱의 긍정적인 효과를 감소시키는 부작용을 불러온다 -> 결국 돈이 문제다

 

 

뭔가 이거 관련해서 좀 찾아보고싶은데 마땅한 자료가 없는 것 같다 아쉽