[HTTP 완벽 가이드] 7장. 캐시

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

(이 책은 목표를 정해줘서 그나마 읽는데 도움이 되는듯 ㅜㅜ)

목표

- 캐시는 불필요한 데이터 전송을 줄여서 네트워크 요금으로 인한 비용을 줄여줌을 안다.

- 캐시는 네트워크 병목을 줄여주고, 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 함을 안다.

- 캐시는 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 없게함을 안다.

- 페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여줌을 안다.

 

 

7.1 불필요한 데이터 전송

여러개 클라이언트가 자주 쓰이는 하나의 서버 페이지에 접근할때 서버는 같은 문서를 클라이언트에게 각각 한번씩 전송한다.

똑같은 요청들이 네트워크를 통해 계속 반복해서 이동한다.

데이터 전송은 값비싼 네트워크 대역폭을 잡아먹고 전송을 느리게 만들며, 웹 서버에 부하를 준다.

 

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

 

 

7.2 대역폭 방문

캐시는 네트워크 병목을 줄여주는데, 많은 네트워크가 원격 서버보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공한다.

클라이언트들이 서버에 접근할 때의 속도는 그 경로에 있는 가장 느린 네트워크의 속도와 같다.

만약 클라이언트가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 캐싱은 성능을 대폭 개선할 수 있을 것이다.

 

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

캐싱은 갑작스런 요청쇄도에 대처하기 위해서 중요하다.

많은 사람이 거의 동시에 웹 문서에 접근할때 이런 일이 발생한다.

이런 불필요한 트래픽 급증은 네트워크와 웹 서버의 심각한 장애를 야기한다.

 

7.4 거리로 인한 지연

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

물리적인 빛의 속도 그 자체가 유의미한 지연을 유발하는 것이다.

 

7.5 적중과 부적중

이렇게 캐시는 유용한데, 그러나 캐시가 세상 모든 문서의 사본을 저장하지는 않는다.

캐시에 요청이 도착했을 때, 만약 그에 대응하는 사본이 있다면 캐시를 이용해서 요청이 처리될 수 있다.

이것을 "적중"이라고 한다.

대응하는 사본이 없다면 "부적중"이다.

 

7.5.1 재검사

서버 컨텐츠가 변경될 수 있기 때문에, 캐시는 반드시 그들이 갖고 있는 사본이 여전히 최신인지 서버를 통해 때때로 점검해야한다.

이런 신선도 검사를 http 재검사라고 부른다.

캐시는 캐시된 사본의 재검사가 필요할때, 원 서버에 작은 재검사 요청을 보낸다.

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

그 사본이 여전히 유효함을 알게 될 캐시는 즉각 사본이 신선하다고 임시로 다시 표시한 뒤 그 사본을 클라이언트에 제공한다.

 

7.5.2 적중률

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

적중률이 100%이라 함은 모든 요청이 캐시적중에서 사본을 가져온 경우임을 의미한다.

 

7.5.3 바이트 적중률

문서들이 모두 같은 크기인 것은 아니기 때문에 문서 적중률이 모든 것을 말해주지는 않는다.

몇몇 큰 객체는 덜 접근되지만, 그 크기 때문에 전체 트래픽에는 더 크게 기여한다.

어떤 사람들은 바이트 단위 적중률 측정값을 더 선호한다.

바이트 단위 적중률은 문서 적중률보다 요금이랑 관련이 깊다.

 

7.5.4 적중과 부적중의 구별

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

응답의 생성일이 더 오래되었다면 응답이 캐시된 것임을 알 수 있다.

 

7.6 캐시 토폴로지

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

한명에게만 할당된 캐시를 개인 전용 캐시라고 하고, 공유된 캐시는 공용캐시라고 한다.

 

7.6.1 개인 전용 캐시

개인 전용 캐시는 많은 에너지나 저장공간을 필요로 하지 않으므로, 작고 저렴할 수 있다.

사용자가 브라우저의 캐시 사이즈와 설정을 수정할 수 있도록 허용한다.

 

7.6.2 공용 프록시 캐시

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

 

7.6.3 프록시 캐시 계층들

작은 캐시에서 캐시 부적중이 발생했을때 더 큰 부모 캐시가 걸러 남겨진 트래픽을 처리하도록 하는 계층을 마느는 방식이 합리적인 경우가 많다.

 

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

 

7.6.5 캐시처리 단계

[GET 요청 기준]

1). 요청받기

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

 

2). 파싱

캐시는 메시지를 파싱하여 URI와 헤더들을 추천한다.

 

3). 검색

캐시는 로컬 복사본이 있는지 검사하고, 자본이 없다면 사본을 받아온다. (그리고 로컬에 저장)

 

4). 신선도 검사

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

 

5). 응답 생성

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

 

6). 발송

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

 

7). 로깅

선택적으로, 캐시는 로그파일에 트랜잭션에 대해서 서술한 로그 하나를 남긴다.

 

7.7.1 단계1. 요청받기

네트워크 연결에서 활동을 감지하고, 들어오는 데이터를 읽는다.

여러개의 커넥션에서 데이터를 동시에 읽고 메시지 전체가 도착하기전에 처리한다.

 

7.7.2 단계2. 파싱

캐시는 요청 메시지를 파싱해서 헤더부분을 조작하기 쉬운 자료구조에 담는다.

 

7,7.3 단계3. 검색

캐시는 URL 알아내고, 이미 로컬 사본이 존재하는지 검사한다.

캐시된 객체는 서버응답본문과 원서버 응답헤더를 포함하고 있으므로 캐시적중동안 올바른 서버헤더가 반환될 수 있는지 검사한다.

있으면 캐시적중이다.

캐시에는 얼마나 저장되어있었는지에 대한 메타데이터도 있다. :)

 

7.7.4 단계4. 신선도 검사

http는 캐시가 일정 기간동안 서버 문서의 사본을 보유할 수 있도록 해준다.

이 기간동안 문서는 신선한 것으로 간주되고, 캐시는 서버와의 접촉없이 이 문서를 제공가능하다.(적중한것)

 

캐시사본을 신선도 한계를 넘어서면 신선하지 않은 것이며, (당연하지..)

캐시는 그 문서를 제공하기 전에 문서에 어떤 변경이 있었는지 확인하려고 -> 서버한테 재검사를 해야함.

 

이 계산방법이 복잡하다고 한다. (추후 다룬다.)

 

7.7.5 단계5. 응답 생성

캐시가 적중되어도 그 응답이 원 서버에서 온 것처럼 보이게 하려고 하고 싶기 때문에,

캐시된 서버응답 헤더를 토대로 응답 헤더를 생성함.

 

즉, 캐시는 클라이언트에 맞게 이 헤더를 조정해야하는 책임이 있다.

클라이언트가 http1.1응답을 기대하는 상황에서, 서버가 http1.0 응답을 줬다면 캐시는 그에 맞게 번역해야함 :ㄷㄷ:

 

7.7.6 단계6. 전송

응답 헤더가 준비되면, 캐시는 클라이언트에게 응답을 돌려준다 ㅇㅇ

 

7.7.7 단계7. 로깅

대부분 캐시는 로그파일과 캐시사용에 대한 통계를 유지한다.

캐시 트랜잭션이 완료되면, 적중률 같은 지표들을 갱신한다.

 

 

7.7.8 캐시처리 flow chart

 

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

캐시도니 사본 모두가 서버의 문서와 항상 일치하는 것은 아니다.

그래서 캐시된 데이터는 서버의 데이터와 일치하도록 관리되어야 한다.

http는 어떤 캐시가 사본을 갖고 있는지 기억안해도 캐시된 사본이 서버와 일치하도록 유지할 수 있게 해주는 단순한 매커니즘을 가지고 있다.

(이것을 문서만료와 서버재검사라고 부른다.)

 

7.8.1 문서만료

http에서는 Cache-Control, Expires 라는 헤더들을 이용해서 서버가 문서에 유효기간을 붙일 수 있게 해준다.

(식품에 붙어있는 유효기간 같은거임!)

 

캐시문서가 만료되기전에, 캐시는 필요하다면 서버와의 접촉없이 사본을 제공할 수 있다.

 

7.8.2 유효기간과 나이

서버는 응답본문과 함께하는

http1.0의 Expires나

http1.1의 Cache-Control: max-age 응답헤더를 이용해서 유효기간을 명시할 수 있다.

 

Expires와 Cache-Control: max-age의 차이는 아래표를 참고하자.

 

Cache-control: max-age는 문서의 최대나이, 문서가 처음 생성된 이후부터 더이상 신선하지 않다고 간주할떄까지 경과한 기간을 말한다.(초단위)

Expires는 절대유효기간.

 

7.8.3 서버 재검사

캐시가 서버에게 문서가 변경되었는지의 여부를 물어보는 것을 "서버 재검사"라고 한다.

- 컨텐츠가 변경되었다면?

그 문서의 새로운 사본을 가져와서 오래된 데이터를 저장한뒤 클라이언트에게도 보내준다.

- 변경되지 않았다면?
새 만료일을 포함한 헤더만 가져와서 헤더를 갱신함.

 

7.8.4 조건부 메서드와 재검사

http는 조건부 GET이라는 요청을 보낼 수 있다.

서버에 있는 문서가 캐시의 문서와 다른 경우에만 문서 데이터를 보내달라고 하는 것이다.

이렇게 신선도 검사와 객체를 받아오는 것을 하나의 조건부 GET으로 처리가능.

가장 유용한것은 위 If-Modified-Since, If-None-Match이다.

이것 이외에도 다른 조건부 요청 헤더들도 If로 시작한다.

 

7.8.5 If-Modified-Since: 날짜 재검사

만약 문서가 주어진 날짜 이후에 변경되었다면, true가 되고 GET 요청이 평범하게 성공한다.

그렇게 새로운 만료날짜 등등이 포함된 새로운 문서응답이 캐시에 업데이트 된다.

 

문서가 주어진 날짜 이후에 변경된게 아니면 false이고,

서버는 304 Not Modified 응답 메시지를 클라이언트에게 돌려준다. (본문은 안보냄)

헤더에서 갱신되어야할것만 캐시에게 반환하여 업데이트한다. (새로운 만료날짜 같은거)

 

7.8.6 If-None-Match: 엔티티 태그 재검사

이거는 If-Modified-Since를 사용했을때 최근 변경 일시 재검사가 적절하게 행해지기 어려운 상황때문에 쓰인다.

- 어떤 문서는 일정 시간 간껴으로 쓰여지는데, 실제로 같은 데이터를 포함하는경우 (즉, 내용은 아무런 변화가 없는데 변경시각이 주기적으로 업데이트 되는 경우)

- 새로운 문서를 받아오기에 별로 이득이 아닌경우 (철자수정이나 주석수정인 경우에.. 굳이 새 문서를 받아와야하는지?)

- 어떤 서버에서는 최근 변경 일시를 정확하게 판별할 수 없을 수도 있다.

- 1초보다 작은 간격으로 갱신되는 문서는 정밀성이 보장되지 않음.

 

if-None-Match는 문서를 변경할때 새로운 버전으로 엔티티태그를 변경할 수 있음. ex) 2.6v

따라서 서버에서 유효한 변경이 있을시에만 엔티티태그를 변경하여, 

각 클라이언트의 캐시를 업데이트하도록 유도할 수 있음

 

7.8.7 약한 검사기, 강한 검사기

위 방법에서 엔티티태그나 최근변경일시는 둘다 캐시검사기이다.

 

서버는 캐시된 사본을 무효화시키지 않고 문서를 아주 살짝만 고치고 싶어할 수 있는데,

이때 위 조건들에 "w/"가 붙어있으면 약한검사기가되어서 어느정도의 컨텐츠 변경을 허용한다. (Q. 어떤부분이 허용되는 걸까..)

 

강한검사기는 그냥 변경이 있으면 무조건 다르다고 판단하여 새로운 문서를 받아온다.

 

서로 다든 두 엔터티에 대해 강한 엔터티 태그 값을 재활용해서는 안 되며， 약한 엔터티 태그 값이라고 할지라도 서로 의미가 다른 두 엔터티에 대해서 는 재활용해서는 안 된다는 것에 주의하라. 유효기간에 상관없이 캐시 항목은 임의 의 긴 기간동안계속될수 있다.따라서 캐시가과거의 특정 시점에서 얻은검사기 를 사용해서 캐시 항목을 다시 검사하려 시도하지 않을 것이라는 예상은 틀릴 수 있다

(Q. 이거 말이 좀 어렵다.)

 

7.8.8 언제 엔티티태그, 언제 최근변경일 일시를 사용하는가

서버가 반환한 조건에 따라서 대응하면된다.

(복잡)

 

 

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-cache는 로컬 캐시저장소에 저장될 수는 없지만 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공할 수 없을 뿐이다.

(재검사해야 캐시->클라이언트가 가능하다는 옵션)

 

7.9.2 Max-Age 응답헤더

Cache-Control: max-age는 신선하다고 간주되었던 문서가 서버로부터 받은 이후로 흐른 시간이고 초단위이다.

 

7.9.3 Expires 응답헤더

deprecated됨.

초단위 시간대신에 실제 절대 만료날짜를 설정함.

=> 많은 서버가 부정확한 시계를 갖고 있어서 없어짐.

 

7.9.4 Must-Revalidate 헤더

Cache-control: must-revalidate 헤더는 신선하지 않은 사본을 서버와의 재검사 없이는 제공해서는 안됨을 의미.

신선도 검사 수행했을때 서버가 사용할 수 없는 상태면 504 Gatewat Timeout을 반환해야한다. (Q. 왜 하필 Timeout일까)

 

7.9.5 휴리스틱 만료

응답이 max-age나 Expires를 포함하지 않고 있다면

휴리스티갛게 LM인자 알고리즘을 통해서 설정한다. (알고리즘은 자세히 안봄)

 

7.9.6 클라이언트 신선도 제약

웹 브라우저는 신선하지 않은 캐시 컨텐츠를 강제로 갱신시켜주는 강한새로고침이있다.

또한 브라우저에서는 신선도 요구사항을 엄격하게 하거나 느슨하게 할 수 있다.

 

7.9.7 주의할 점

캐시 만료는 완벽한 시스템이 아니다. 만료일자가 너무 길어지지 않게 조심하자.

 

7.10 캐시 제어 설정

아파치 웹서버가 캐시제어를 어떻게 하는지 설명하는 부분임

캐시 알고리즘과 캐시와 광고사이의 최적화나 제약사항을 제시함.