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

---

2부.HTTP : HTTP 아키텍처

---

7장.캐시

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

---

7.1 불필요한 데이터 전송

• 복수의 클라이언트들은 자주 쓰이는 원 서버 페이지에 접근할 때, 서버는 같은 문서를 클라이언트들에게 각각 전송하게 된다.
• 이 불필요한 데이터 전송은 값비싼 네트워크 대역폭을 잡아먹고 전송을 느리게 만들며, 웹 서버에 부하를 준다.

7.2 대역폭 병목

• 캐시는 네트워크 병목을 줄여준다.

• 많은 네트워크가 원격 서버보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공한다.

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

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

  • LAN : Local Area Network의 약자로 사용자가 포함된 지역 네트워크를 의미하며, LAN은 이더넷이라는 프로토콜을 주로 사용

  • WAN : Wide Area Network 의 준말로써 LAN과 LAN 사이를 광범위한 지역 단위로 구성하는 네트워크를 의미하며,

      보통 ISP(Internet Service Provider => SK, KT, LG) 네트워크망을 통해 접속합니다.

    

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

• 갑작스러운 사건(코로나, 지진)으로 인해 많은 사람이 동시에 웹 문서를 접근할 때 발생
• 트래픽 급증은 웹 서버의 심각한 장애를 가져옴

7.4 거리로 인한 지연

• 모든 네트워크 라우터는 제각각 인터넷 트래픽을 지연시킴
• 클라이언트와 서버 사이에 라우터가 그다지많지 않더라도, 빛의 속도 그 자체가 유의미한 지연을 유발
• 캐시를 통해 문서가 전송되는 거리를 확연히 줄여서 해결 가능

7.5 적중과 부적중

• 캐시는 세상 모든 문서의 사본을 저장하지는 않는다.

• 요청이 왔을때 사본이 있다면 그것을 이용해 요청을 처리할 수 있고 이것을 캐시 적중(cache hit)라 부른다.

• 사본이 없다면 서버로 요청을 보내고 이것을 캐시 부적중(cache miss)라 부른다.

  1) 재검사

  • 캐시는 반드시 갖고 있는 사본이 최신인지 점검해야한다.

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

  • 효과적인 재검사를 위해, HTTP는 서버로부터 전체 객체를 가져오지 않고도 콘텐츠가 여전히 신선한지 검사 할 수 있도록 요청을 정의했다.

  • 콘텐츠에 변화가 없다면 서버는 304 Not Modified 응답을 보낸다. 이를 재검사 적중 혹은 느린 적중이라 한다.

  • 이것은 순수 캐시 적중보단 느리고, 캐시 부적중보다는 빠르다. (서버에서 객체를 받아와야할 유무)

  • HTTP는 캐시된 객체를 재확인하기 위해 If-Modified-Since 헤더를 제공하며, If-Modified-Since 요청이 왔을때 세가지 상황

    재검사 적중

    • 객체가 변경되지 않았다면 304 Not Modified 응답

    재검사 부적중

    • HTTP 200 Ok 응답

    객체 삭제

    • 404 Not Found 응답

2) 문서 적중률

• 캐시가 요청을 처리하는 비율을 나태난다.

• 0부터 1까지의 값으로 이루어져 있으며, 모든 요청이 캐시 부적중일 땐 0%, 모든 요청이 캐시 적중일 땐 100% 다.

• 문서 적중률을 개선하면 대기시간(지연)이 줄어든다

  3) 바이트 적중률

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

• 몇몇 객체는 덜 접근되지만 그 크기 때문에 전체 트래픽에 더 크게 기여할 수 있다.

• 트래픽의 절감정도를 포착해낸다.

• 바이트 단위 적중률 100%는 모든 바이트가 캐시에서 왔으며, 어떤 트래픽도 인터넷으로 나가지 않았음을 의미한다.

• 바이트 단위 적중률은 얼마나 많은 바이트가 인터넷으로 나가지 않았나를 보여준다.

  4) 적중과 부적중의 구별

• HTTP는 클라이언트에게 응답이 캐시 적중인지 원 서버 접근인지 알려주지 않는다.

• 두 경우 모두 응답은 HTTP 200 Ok가 된다.

• 어떤 사용 프락시는 Via 헤더에 추가 정보를 붙여줄 순 있다.

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

• 응답의 생성일이 오래되었다면 클라리언트는 응답이 캐시된 것임을 알 수 있다.

• 또 다른 방법은 Age 헤더를 이용하는 것이다.

7.6 캐시 토폴로지

• 한명에게 할당된 캐시는 개인 전용 캐시 (Private cache)

• 여러 클라이언트가 자주 찾는 객체가 할당된 캐시는 공유된 캐시는 (Public cache)

  1) 개인 전용 캐시 (Private cache)

  • 많은 에너지나 저장 공간이 필요치 않고 작고 져럼하며, 웹 브라우저는 개인 전용 캐시를 내장하고 있다.
  • 브라우저는 자주 쓰이는 문서를 개인 컴퓨터의 디스크 메모리에 캐시해 놓고, 사용자가 설정을 수정할 수 있도록 허용한다.
  • 캐시를 확인할 수 있도록 허용도 한다.

  2) 공유 프락시 캐시 (Public cache)

  • 프락시 캐시는 로컬 캐시에서 문서를 제공하거나, 혹은 사용자의 입장에서 서버에 접근한다.
  • 여러 사용자가 접근하기에 불필요한 트래픽을 줄일 수 있는 더 많은 기회가 있다.
  • 프락시 캐시는 수동 프락시를 지정하거나 프락시 자동설정 파일을 설정함으로써 브라우저가 프락시 캐시를 사용하도록 할 수 있다.
  • 인터셉트 프락시를 사용함으로써 브라우저의 설정 없이 HTTP 요청이 캐시를 통하도록 강제 할 수 있다.

  3) 프락시 캐시 계층

  • 작은 캐시에서 캐시 부적중이 일어나면 더 큰 부모 캐시가 그것을 이어받도록 하는 계층을 만드는 방식은 합리적이다.
  • 캐시의 계층이 깊다면 요청은 캐시의 긴 연쇄를 따라가고, 프락시 연쇄가 깊어질수록 각 중간 프락시는 현저한 성능 저하가 발생할 것이다.

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

  • 몇몇 네트워크 아키텍처는 단순한 캐시 계층 대신 복잡한 캐시망을 만든다.
  • 프락시 캐시는 복잡한 방법으로 서로 대화하여, 어떤 부모 캐시와 대화할 것인지 아니면 요청이 캐시를 우회할 것인지에 대한 결정을 동적 결정한다.

7.7 캐시 처리 단계

• 절차
  1. 요청받기 - 캐시는 네트워크로부터 도작한 요청 메시지를 읽는다.
  2. 파싱 - 캐시는 메시지를 파싱하여 URL과 헤더들을 추출한다.
  3. 검색 - 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아온다(후에 로컬에 저장)
  4. 신선도 검사 - 캐시는 캐시된 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지 서버에 확인한다.
  5. 응답 생성 - 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다.
  6. 발송 - 캐시는 네트워크를 통해 응답을 클라이언트에게 돌려준다.
  7. 로깅 - 선택적으로, 캐시는 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남긴다.

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

• 문서 만료와 서버 재검사를 통해 사본의 최신성을 유지

  1) 문서 만료

  • HTTP는 Cache-control과 Expires라는 특별한 헤더를 통해 문서에 유효기간을 붙인다.

  2) 유효기간과 나이

  • 서버는 응답 본문과 함께 하는 HTTP/1.0+ Expires나 HTTP/1.1 Cache-Control:max-age 응답 헤더를 통해 유효기간을 명시한다.
  • 두 헤더는 기본적으로 같은 일을 하지만, 절대 시간은 컴퓨터의 시계가 올바르게 맞추어져 있을 것을 요구한다.

헤더	설명	예
Cache-Control:max-age	max-age 값은 문서의 최대 나이를 정의한다. 최대 나이는 문서가 처음 생성된 이후부터, 제공하기엔 더 이상 신선하지 않다고 간주될 때까지 경과한 시간의 합법적인 최대값(초단위)이다.	Cache-Control:max-age=48200
Expires	절대 유효기간을 명시한다. 만약 유효기간이 경과했다면, 그 문서는 더 이상 신선하지 않다.	Expires: fri, 05 jul 2002, 05:00:00 GMT

3) 서버 재검사

• 캐시된 문서가 만료되었단 것은, 그 문서가 원 서버에 현재 존재하는 리소스와 실제로 다르다는건 아니며, 검사할 시간이 되었음을 뜻한다.

• 서버 트래픽을 절약하고 사용자 응답 시간을 개선한다.

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

• HTTP는 캐시가 서버에게 조건부 GET 요청을 보낼 수 있도록 해준다.

• 캐시의 문서와 서버의 문서가 다를 경우에만 보내달라는 것이다.

  조건부 헤더

헤더	설명
if-Modified-Since:	만약 문서가 주어진 날짜 이후로 수정되었다면 요청 메서드를 처리한다. 이것은 캐시된 버전으로부터 콘텐츠가 변경된 경우에만 콘텐츠를 가져오기 위해 Last-Modified 서버 응답 헤더와 함께 사용된다.
if-None-Match:	마지막 변경된 날짜를 맞춰보는 대신, 서버는 문서에 대한 일련번호와 같이 동작하는 특별한 태그를 제공한다. if-None-Match 헤더는 캐시된 태그가 서버에 있는 문서의 태그와 다를 때만 요청을 처리한다.

나머지는 생략한다.