[Web] HTTP 캐시(Cache)

1. 매번 요청에 따른 웹 브라우저와 웹 서버의 부하

웹의 본질은 요청을 보내고 결과를 받는 행위들이다.
웹 브라우저는 매번 웹 서버에게 요청해서 결과를 받아와야 하고, 웹 서버는 매번 웹 브라우저의 요청에 대해 결과를 만들고, 반환해야 한다.

그래서, 웹 브라우저와 웹 서버는 너무 힘들다

• 웹 브라우저 : 웹 페이지 로드 결과가 똑같다면, 웹 브라우저는 매번 웹 서버에게 받아올 필요가 없다.
  • 이전에 받았던 결과를 저장 후, 매번 요청할시 저장해놓은 결과를 재사용(웹 브라우저의 캐시)하면 되지 않을까?
    
    • 반복 : 웹 브라우저는 매번 똑같은 100MB 짜리 고양이 영상을 웹 서버로부터 받아온다.
      1. 네트워크 트래픽 및 비용 발생 문제
      2. 100MB 다운로드 완료까지 긴 대기시간 후에야 시청 가능 문제
    • 이전에 받았던 100MB 짜리 고양이 영상을 재사용한다면?
      1. 네트워크 트래픽 및 비용 감소
      2. 100MB 다운로드 완료의 긴 대기시간 없이 바로 시청 가능 = 유저 경험 증진

• 웹 서버 : 웹 페이지 로드 결과가 똑같다면, 웹 서버는 매번 웹 브라우저에게 만들어 반환할 필요가 없다.
  • 이전에 반환한 결과를 저장 후, 매번 요청받을시 저장해놓은 결과를 재사용(웹 서버 캐시)하면 되지 않을까?
    
    • 반복 : 웹 서버는 매번 똑같은 100MB 짜리 고양이 영상을 만들어서 웹 브라우저에게 만들어준다.
      1. 반복적인 서버자원(CPU, Memory) 소비 문제 = 모든 유저의 요청에 대한 반복 연산
    • 이전에 만들어놓았던 100MB 짜리 고양이 영상을 재사용한다면?
      1. 반복적인 서버자원(CPU, Memory) 여유 = 반복되는 모든 유저의 요청 간단히 처리 가능
      2. 불특정 다수의 웹 브라우저에게도 캐시된 자원 제공 가능
         • 웹 브라우저 캐시는 웹 브라우저 유저만 캐시된 자원을 활용할 수 있었음

2. 캐시(Cache)?

사전적 정의는 다음과 같다.

컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. - 위키백과

일반적으로 일시적인 특징이 있는 데이터 하위 집합을 저장하는 고속 데이터 스토리지 계층 - AWS

일반적으로 캐시는 자주 사용되는 데이터를 임시로 복사해두는 임의의 장소를 말한다. 그리고 데이터를 캐시에 저장하는 행위를 캐싱이라고 한다.

⚠️ Cache 캐시 용어의 범용성
“클라이언트와 서버” 처럼 문맥에 따라 워낙 다양하게 사용되니 짚고가자

• 캐시 (명사) : 임시 (단기적 : 기간 설정 or 알고리즘 설정) 로 재사용할 내용을 저장
  • CPU 캐시 : CPU 연산을 위해 메모리에서 값 가져와 사용 후 폐기 (칩셋)
  • HTTP 캐시 : 웹 요청에 따른 결과를 임시 저장 후
  • 서버 캐시 : LRU-Cache ‘로컬 캐시’ 혹은 인메모리 DB 인 Redis ‘글로벌 캐시’
    
    
• 캐시 (동사) : “임시 저장해” 의 의미 (Default 와 같은 개발자 용어)

3. HTTP Cache?

이미지 혹은 JS, CSS와 같은 파일들은 자주 변하지 않는다. 캐시를 사용하지 않으면 자주 변하지 않는 데이터라도 요청마다 새롭게 다운로드 해야한다. 이는 불필요한 네트워크 비용 발생을 야기하고, 서버에 추가적인 부담을 준다. 이는 곧 느린 웹페이지 로딩 속도로 직결되고, 좋지 않은 사용자 경험을 낳을 것 이다.

따라서 웹사이트나 앱 서비스에 사용되는 이미지, HTML, 파일 등의 재사용 가능한 HTTP 리소스를 임시로 저장하는 공간이 필요한데 이를 HTTP Cache라고 한다.

4. HTTP Cache의 종류

크게 (1)Private와 (2)Shared로 나뉜다.

4.1 Private Cache

개인 사용자의 브라우저에 저장되는 캐시로, 해당 사용자만 접근할 수 있어 다른 사람이 접근할 수 없다.

• 브라우저 캐시: 웹 서버 HTTP Cache 헤더 (Cache-control) 를 통한 제어 (웹 브라우저에 저장하라)

4.2 Shared Cache

임시 중간 저장소가 웹 브라우저와 웹 서버 사이에 있다면, 모든 웹 브라우저 유저 다수를 위한 것이다.

• 프록시 캐시(Proxy Cache) : 웹 서버 HTTP Cache 헤더 (Cache-control) 를 통한 제어 (프록시 서버에 저장하라)
• 관리형 캐시(Managed Cache) : 서비스 개발자가 직접 정책 제어, 배포, 캐싱할 데이터 직접 업로드 등이 가능
  • CDN(Content Delivery Network) 캐시: 지리적인 제약 없이 전 세계 사용자에게 빠르고 안전하게 컨텐츠 전송을 할 수 있는 기술을 말한다. 이를 통해서 컨텐츠의 병목현상을 피할 수 있다.
    

5. HTTP Cache 동작 원리

• 캐시 사용 여부: 실시간성이 매우 중요한 데이터는 성능에 문제가 되더라도 캐시는 사용하지 않는것이 맞다.
• 재검증: 데이터의 원래 주인인 웹 서버에 캐시되어 있는 데이터의 유효성 검사

5.1 재검증

캐시한 데이터의 원본 주인인 웹 서버가 설정한 특정 주기에 따라, 캐시한 데이터가 오래됐는지 검증

• 검증 방법 : 조건부 요청 사용 = 재검증 기준이 되는 값을 서버에게 보낸다.

1. 재검증 주기: 캐시해 놓은 데이터를 얼마 간격으로 재검증할 것인가

   • 개발자들은 데이터의 갱신 특성에 따라 주기 설정.

2. 재검증 기준: 캐시해 놓은 데이터가 오래되었는지 여부를 웹 서버가 판단하기 위한 그준 근거.
   - 시간 : 수정일(Last-modified)
   - 고유값 : 해시 또는 ID (ETag)
   
   

Last-Modified

전송 Resource의 마지막 수정 시간 정보를 헤더에 저장함. 기본적으로 캐시가 유효한지 여부를 시간을 기반으로 판단한다.

• if-Modified-Since(저장된 데이터를 받은 시간 이후로 데이터가 바뀌었나?)
  • 바뀌었어!! : 200 + Resource Cache
  • 아니 안바뀌었어!! : 304 Not Changed
• if-Unmodified-Since(저장된 데이터를 받은 시간 이후로 데이터가 안바뀌었나?)
  • 응 안바뀌었어: 304 Not Changed
  • 아니 바뀌었어: 200 + Resource Cache

ETag

HTTP 프로토콜에서 리소스의 특정 버전을 식별하는 고유한 식별자이다. 기본적으로 캐시가 유효한지 여부를 고유값(해시, ID)을 기반으로 판단한다.

• if-None-Match(저장된 데이터를 받은 시간 이후 데이터가 바뀌었나?)
  • 응 바뀌었어!: 200 + Resource Cache
  • 아니 안비뀌었어!: 304 Not Changed
• if-Match(저장된 데이터를 받은 시간 이후 데이터가 안 바뀌었나?)
  • 안바뀌었어!: 304 Not Changed

5.2 Cache-Control 헤더를 통한 세부 설정

Cache-Control 헤더를 통해 캐시의 수명, 캐시 사용 여부, 재검증 필요 여부 등을 설정할 수 있다.

캐시할 데이터는 웹 서버가 반환하는값이고, 반환값에 대한 소유주는 웹 서버이기에 웹 서버가 캐시를 모두 제어

1. 캐시 저장 여부

   • no-store: 캐시를 사용하지 않음. 은행 계좌 정보나 결제 내역 등의 중요한 데이터는 절대 캐시되어서는 안 되는 상황처럼 주로 보안이나 개인정보 보호가 필요한 경우에 사용됨.
   • no-cache: 캐시를 사용함. 단, 매번 재검증 후 사용할 수 있음.

2. 캐시 저장 장소

   • public: Private(웹 브라우저) + Shared(프록시) 모두에 저장
   • private: Private(웹 브라우저) 에만 저장
     

3. 캐시 재검증 주기

   • max-age: Expires(유효시간)으로 변환(기존 Expires 가 있다면 덮어쓴다)
   • s-maxage: Proxy 캐시에만 적용되는 유효기간

4. 재검증 강제

   • must-revalidate: 꼭 "웹 서버"와 직접 재검증이 완료된 뒤 캐시를 사용해야한다는 의미의 정책. 서버와의 접속 문제로 재검증이 실패한 경우 504 에러 발생.