HTTP 완벽 가이드 - 캐시

캐시

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

캐시로부터 제공된다.

 - 불필요한 데이터 전송 감소

 - 네트워크 병목 감소시킴으로써, 대역폭을 늘리지 않고도 페이지를 빠르게 로딩

 - 웹 서버에 대한 요청을 감소시킴으로써 서버는 부하를 감소시킬 수 있고, 빠르게 응답 가능

 - 물리적인 거리로 인한 지연 감소

1. 불필요한 데이터 전송 감소

자주 사용하는 페이지에 대해 여러 클라이언트에서 요청이 온다고 하자. 캐시가 없다면 각각의 클라이언트에게 페이지를 모두 제공해야만 한다. 하지만 캐시가 존재한다면

첫번째 클라이언트의 요청이 올때, 페이지를 캐시에 저장하고, 뒤이은 요청에 대해서는 캐시에 저장된 페이지를 제공하면 된다. 그렇게 되면 웹 서버에 대한 부하 감소 및

불필요한 데이터 전송으로 대역폭을 낭비할 필요가 없다. 

 * 대역폭 : 네트워크에서 전송되는 데이터의 범위로서 동시 접속자를 의미, 단위시간당 전송 가능한 데이터의 양을 의미

2. 대역폭 병목 감소

3. 갑작스러온 요청 쇄도 (Flash Crowds)

 캐싱은 갑작스러운 요청 쇄도 대처 가능하다. 갑작스러운 사고로 인해 많은 클라이언트가 동시에 접근할 때, 클라이언트들이 자주 요청했던 페이지에 대해 캐시를 통해 

 웹 서버에 대한 접근없이 빠르게 전달할 수 있기 때문에 트래픽 급증에 의한 네트워크 웹 서버의 심각한 장애를 극복할 수 있다.

  * 트래픽 : 데이터 전송량, 트래픽의 급증은 데이터 전송량의 급증이라고 해석 가능

4. 거리로 인한 지연

5. 캐시 적중과 부적중, 재검사, 적중률

 캐시에 요청이 왔을 때, 그에 대응하는 사본이 존재한다면 이 사본을 통해 요청을 처리할 수 있는데, 이를 캐시 적중이라 하고, 사본이 없다면 캐시 부적중이라고 한다.

 웹 서버의 콘텐츠는 변화 가능성이 있기 떄문에 캐시는 사본이 최신판인지 주기적으로 확인을 하는데 이러한 신선도 검사를 재검사고 한다. 

 캐시는 언제든지 재검사를 할 수 있지만 재검사를 하는 것만으로도 많은 대역폭을 소진할 가능성이 있기 때문에 충분히 오래된 경우에만 재검사를 시행한다.

 캐시는 사본의 재검사가 필요할 때 서버를 이용해서 재검사 요청을 보내고, 서버는 304 Not modified 응답을 보내면 최신이라고 인식하고, 클라이언트에게 전달한다.

 이를 재검사 적중 혹은 느린 적중이라고 한다. 느린 적중은 부적중보다는 빠르다. (서버로부터 받아오는 것보다는 검사가 빠르기 때문이다)

 HTTP 캐시된 객체를 재확인하기 위한 방법은 다양하지만, 그중에서 가장 많이 사용되는 방법이 If-Modified-Since 헤더이다. 이 헤더는 GET 요청에 대해 캐시된 이후에 

 변경된 경우에만 사본을 보내달라는 의미이다.  만약 서버에 객체가 변경되지 않았다면 서버는 재적중 검사에 대해 HTTP 304 Not Modified 응답을 보낸다.

 서버 객체가 캐시된 사본과 다르면 서버는 콘텐츠 전체와 함께 HTTP 200 OK 응답을 보낸다. 그리고 객체가 삭제되었을 때,  404 Not Found 응답을 보낸다.

캐시가 요청을 처리하는 비율을 캐시 문서 적중률이라고 부른다. 예를들어 10개의 요청중에서 8개를 캐시를 통해 처리를 했다면 적중률은 80%이다.

적중률은 예측하기 어렵지만, 40%이상이면 괜찮은 캐시이다. 그러나 요청하는 페이지마다 용량이 동일하지 않기 때문에 문서 적중률만으로는 평가가 불가능하다.

그렇기 떄문에 바이트 적중률도 사용한다. 캐시가 아닌 서버를 통해 문서를 내보내려면 서버와의 커넥션을 맺어야 하기 때문에 이를 통한 지연이 발생할 수 있다.

그렇기 떄문에 문서 적중률을 개선하면, 연결로 인한 지연을 감소시킬 수 있다. 바이트 적중률을 개선하면, 대역폭 절약이 가능하다.

캐시의 적중과 부적중을 구별하기 위해서는 응답온 데이터의 헤더를 보면 알 수 있다. 헤더의 생성일이 현재 시간보다 더 오래되었다면(많이) 이것은 캐시를 통해 

전달받은 문서이고, 그렇지 않으면 서버로부터 응답받은 문서이다. 응답이 얼마나 오래되었는지 말해주는 이것을 Age헤더 라고 한다.

6. 캐시 토폴로지

한명의 사용자가 자주 접근하는 문서에 대한 정보를 가지고 있으며, 오직 개인만 접근 가능한 캐시를 전용 캐시라 부른다. 전용 캐시는 용량이 작고, 웹 브라우저에 내장

되어있다. 

여러 사용자가 공유해서 사용하는 캐시를 공용 캐시라고 부르고, 특별한 프락시 서버이다.

프락시 서버를 잠시 살펴보자면, 프락시 서버는 클라이언트와 서버 사이에 위치하여 그들 사이의 HTTP 메세지를 정리하는 중개인 역할 수행한다.

프락시는 클라이언트 입장에서는 클라이언트의 요청에 대해 응답을 하기 때문에 웹 서버 역할을 수행하고, 클라이언트의 요청을 웹 서버에 전달하기 때문에 웹 서버 입장에서는

클라이언트의 역할을 한다. 프락시가 없다면 클라이언트는 곧바로 서버가 통신을 해야 할 것이다. 프락시는 개인 프락시, 공용 프락시로 나눠지고, 대부분이 공용 프락시다.

공용 프락시는 클라이언트들이 공통된 요청을 통해 이득을 취할 수 있기 때문에 클라이언트가 많을 수록 유리하다. 

공용 캐시 또한 클라이언트가 많을 수록 유리하다. 그 이유는 클라이언트 집단의 공통적인 관심사를 캐시하기 때문에 공유된 문서를 제공할 수 있어 트래픽을 감소시킬 수 있다.

 

프락시 캐시는 계층을 통해 관리가 된다. 클라이언트 주변에는 작은 용량의 저렴한 캐시들이 있고, 상단에는 여러 클라이언트들이 공유하는 문서를 저장하는 캐시가 있다.

만약 1단계에서 부적중한다면, 2차 캐시에서 요청을 처리할 것이다. 이러한 캐시의 계층구조가 많아진다면, 프락시 연쇄로 이한 성능이 저하될 것이다. (2단계 캐시)

(클라이어트 브라우저 - 1차캐시 - LAN - 2차 캐시 - WAN - 서버 형태로 구성)

7. 캐시 처리 단계

 (1) 요청 받기 : 캐시는 네트워크 커넥션에서 활동을 감지하고, 도착한 요청 메세지를 읽는다.

 (2) 파싱 : 캐시는 요청 메세지를 파싱하여, URL과 헤더들을 추출한다.

 (3) 검색 : 캐시는 URL 알아내고 그에 해당하는 로컬 사본이 있는지 검사한다. 사본이 없다면 서버를 통해 받아오고 캐시에 저장한다.

 (4) 신선도 검사 : 캐시된 사본의 신선도 한계를 넘은 사본은 제공하기 전에 변경이 있었는지 서버를 통해 검사를 한후 제공된다.

 (5) 응답생성 : 캐시는 마치 서버로부터 응답이 온 것처럼 클라이언트에게 응답을 전달하기 위해 서버 응답 헤더를 바탕으로 헤더를 생성한다.

                      캐시는 신선도 정보(Cache-Controll, Age, Expires 헤더)와 프라시 캐시를 거쳐서 왔다는 Via 헤더를 포함시킨다.

                      캐시는 데이터 헤더는 절대 조정해서는 안된다. 데이터 헤더는 서버로부터 최초로 생겨난 날짜를 의미하기 때문에 수정불가

 (6) 전송 : 응답 헤더가 준비되면, 캐시는 읍답을 클라이언트에게 전달한다.

 (7) 로깅 : 로그 파일을 통해 캐시에 대한 통계를 보관한다. 적중, 부적중, 요청종류, URL, 정보를 저장한다.

8. 사본을 신선하게 유지하기

캐시된 사본 모두가 서버의 문서와 항상 일치하지 않는다. 왜냐면, 캐시된 이후에 서버의 문서가 편집될 수 있기 때문이다. HTTP는 어떤 캐시가 사본을 갖고 있는지

서버가 기억하지 않더라도 캐시된 사본이 서버와 일치하도록 유지할 수 있는 메커니즘을 가지고 있다. 이 메커니즘을 문서만료, 서버 재검사라고 부른다.

 (1) 문서만료

  HTTP는 Cache-Control과 Expires라는 특별한 헤더를 이용해서 서버가 문서에 유효한 기간을 설정해준다. 캐시 문서가 만료되기 전에, 캐시는 서버 접근없이 사본을

  제공할 수 있다. 그러나 일단 캐시된 문서가 만료되면 캐시는 반드시 서버에 문서가 변경되었는지 검사해야한다. 

  변경내역이 있다면 새로운 사본과 함께 새로운 유효시간도 가져와야 한다.

 (2) 유효기간(Expires)  과 나이(Age)

  서버는 응답 본문과 함께 HTTP/1.0+Expires 또는  HTTP/1.1 Cache-Control : max age 응답 헤더를 이용해서 유효기간을 명시한다.

  Cache-Cotrol : max age 헤더에서 max age 값은 문서의 최대 유효 나이를 의미하며, 최대 나이는 문서가 처음 생성된 이후부터, 제공하기엔 더이상 신선하지 않다고

  간주될 때까지 경과한 시간의 합법적인 최대시간(단위 : 초)이다. 결국은, 검사를 통해 신선하다고 계속 했을 때, 사본이 가질 수 있는 최대 신선 시간이라고 생각하면 된다.

  (예 : Cache-Control : max age : 4444444) 

  Expires는 절대 유효기간을 명시한다. 만약 유효기간이 경과했다면, 그 문서는 더이상 신선하지 않을 것이다. (예 : Expires : Fri 05 June 2002, 04:44:44 GMT)

 (3) 서버 재검사

  캐시된 문서가 만료되었다는 것은, 그 문서가 서버와 다른 문서라는 것이 아닌, 다시 검사가 필요하다는 것을 의미한다. (만료되었다고, 무조건 바뀐건 아니다.)

  문서가 만료된 이후에, 여전히 유효한 문서인지, 아니면 만료된 문서인지 확인하는 것이 서버 재검사라고 한다. (마치 그대의 머리에 마구니가 가득한지 그렇지 않는지를

  확인하는 관심법과 같다) 

  - 재검사 이후, 변경된 문서라면 서버로부터 변경된 문서를 전달받아 캐시에 저장하고, 클라이언트에게 변경된 문서를 전달한다.

  - 재검사 이후, 변경되지 않았다면 만료일을 포함하고 있는 헤더의 날짜를 갱신한다.

  위와 같은 메커니즘이 존재하기 때문에 문서의 신선도를 클라이언트의 요청마다 검증할 필요가 없고, 문서가 만료되었을 때 한번만 검사하면 된다.

 (4) 조건부 메서드와의 재검사

  HTTP 조건부 메소드는 재검사의 효율성을 증가시킨다. HTTP는 캐시가 서버에게 '조건부 GET' 요청을 보낼 수 있게 해준다. 이 요청은 서버가 갖고 있는 문서와 캐시가 

  갖고 있는 문서와 다를때만 본문 데이터를 보내달라는 요청이다. 이런식으로 신선도 검사와 객체를 받아오는 것을 조건부 GET 하나로 해결할 수 있다.

  서버는 오직 문서가 변경되었을때만 새로운 문서를 반환하도록 되어 있다. HTTP는 다섯가지의 조건부 요청 헤더를 제공하고 있다.

   - If-Modified-Since <data> (IMS)

    만약 문서가 주어진 날짜 이후 수정되었다면 요청 메소드 처리한다. 캐시된 버전으로부터 문서가 변경된 경우에만 문서를 가져오기 위해 Last-Modified 서버 응답 헤더와 

    함께 사용한다. 만약 문서가 주어진 날짜 이후에 변경되었다면 조건이 참이기 때문에 새로운 문서에 새로운 만료날짜를 헤더에 싣어서 캐시에게 전달한다.

    캐시는 새 문서를 저장하고, 클라이언트에게 전달한다. 그리고 만약 문서가 주어진 날짜 이후 변경되지 않아 조건이 거짓이라면, 서버는 304 Not Modified 응답 메세지를

    클라이언트에게 전달한다. (단, 문서는 보내지 않고  새로운 만료날짜를 보낸다) If-Modified-Since는 캐시된 마지막 수정일을 저장한다. 

    웹 서버는 If-moidified-Since 를 비교할 때, 문자열 비교를 통해 확인한다. 정확히 이 문자열이 맞는지를 확인한다. 

   - If-None-Match <tags>  

   마지막 변경된 날짜를 맞춰보는 대신, 서버는 문서에 대한 일련번호와 같이 동작하는 특별한 태그(Etag : 리소스 식별)를 제공할 수 있다.

   헤더는 캐시된 태그가 서버에 있는 문서의 태그와 다를때만 처리한다. 최근에 변경일시를 재검사하기 어려운 상황이 존재한다.

   - 어떤 문서는 일정 시간 간격으로 다시 쓰여지지지만, 실제로는 같은 데이터를 포함하고 있다. 내용에는 변화가 없지만, 변경시각은 계속 변경 가능하다.

   - 새로운 문서로 갱신될 떄, 사소한 변화(한글자 수정)이기 때문에 다시 읽는 것이 불필요할 수 있다.

   - 1초보다 작은 간격으로 계속 갱신하는 문서를 제공하는 서버는 정밀도가 충분하지 않을 수 있다.

  이럴때는 If-None-Math 사용 가능하다. 개발자는 문서를 변경했을 때 엔터티 태그를 새로운 버전으로 변경할 수 있다. 엔터티 태그가 변경되었다면 캐시는 서버로부터

  새로운 사본을 요청하기 위해 IF-None-Match 조건부 헤더 사용할 수 있다. 문서의 엔터티 버전이 변경되면 변경된 문서를 그렇지 않으면 NBot Modified 응답을 반환한다.

9. 캐시 제어

HTTP 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있다.

 (1) Max-Age 응답헤더

  - Cache-Control : max-age 헤더는 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간이고, 단위가 초이다. s-maxage 헤더는 공유 캐시에만 적용된다.

 

 (2) Expires 응답헤더

  - 더이상 사용하지 않기를 권하는 Expires 헤더는 초단위의 시간이 아닌, 절대적인 실제 만료 날짜가 명시되있다. 많은 서버가 부정확하게 조금씩 차이가 나는 시계를 가질 수 있기

    때문에, 만료를 절대적인 날짜가 아닌, 경과된 시간으로 표현하는 것이 좋다고 판단했다. 그렇다는건 Max-Age가 더 좋다는게 아닐까?!

 (3) Must-Revalidate  응답헤더

  - Cache-controll : must-revalidate캐시는 성능 개선을 위해 만료된 문서를 제공할 수 있도록 설정할 수 있다. 그러나 만약에 엄격하게 만료되지 않는 문서만을 제공하고
    싶다면  이 응답헤더를 사용해라.

 (4)  휴리스틱 만료

  - 만약 응답이 Cache-Control : max-age 헤더나 Expires 헤더 중 어느것도 포함하지 않으면 캐시는 경험적인 기반으로 최대 나이를 계산한다. 계산을 위해서는 다양한 

     알고리즘이 사용되고 있고, LM 알고리즘을 알아보려고 한다. LM 알고리즘은 문서가 최근 변경 일시를 포함하고 있다면 사용할 수 있다. LM 알고리즘은 캐시된 문서의 

     변경일자가 매우 예전이라면, 아마 안정적인 문서이고 크게 변경되지 않을거라 판단하고 캐시에 더 오래 보관하고 있어도 안전하다. 그러나 만약 캐시된 문서가 최근에 

     변경되었다면 자주 변경이 되는 문서로 판단하고 서버와 재검사하기 전까지 짧은 기간동안만 캐시해야 한다. 

     캐시는 일반적으로 신선도에 대한 아무런 단서가 없는 문서에 대해 기본 신선도 유지기간을 하루로 설정한다.