HTTP Cache

 

 

웹브라우저는 웹서버에게 요청을 보낼 때마다 매번 서버로부터 응답을 받아와야 한다. 그러나 동일한 응답을 반복해서 받아야 하는 경우, 웹브라우저가 매번 서버로부터 응답을 받아올 필요는 없다. 이전에 받아온 응답을 저장해두었다가, 동일한 요청이 들어올 때 이 저장된 응답을 재사용하여 반환할 수 있다. 이는 HTTP 캐시 중 Private로 불리며, 주로 웹브라우저 측에서 사용된다.

 

한편 웹 서버는 클라이언트의 요청에 따라 매번 응답을 생성하여 반환해야 한다. 그러나 매번 동일한 응답을 만들어야 한다면, 서버도 효율적으로 응답을 처리할 수 있다. 이전에 생성하여 반환했던 응답을 캐시해두고, 동일한 요청이 들어올 때 이 저장된 응답을 재사용하여 반환할 수 있다. 이러한 방식을 HTTP 캐시 중 Shared에 해당하며 프록시 서버나 API 서버의 자체 캐시에서 사용된다. 캐시는 서버 내부의 로컬 캐시나 전역적으로 관리되는 캐시로 구현될 수 있다.

 

 

웹브라우저는 매번 웹서버로부터 동일한 응답을 받아오는 것은 시간과 네트워크 자원을 낭비하는 일이 될 수 있다. 특히, 응답을 생성하고 전송하는 과정에서 대기시간이 길어질 수 있다. 이로 인해 사용자는 느린 로딩 속도를 경험할 수 있고, 불필요한 네트워크 트래픽이 발생하게 된다. 하지만, 이전에 받아온 응답을 브라우저가 캐시해두고 동일한 요청에 대해 이를 재사용하면, 네트워크 트래픽이 줄어들고 페이지 로딩 속도도 빨라진다.

 

웹서버는 클라이언트 요청에 대해 매번 새로운 응답을 생성하는데 노동력과 자원을 투입한다. 만약 많은 사용자가 동일한 요청을 반복적으로 보내면, 서버는 반복적인 연산 작업을 계속해야 하며, 이는 서버 자원의 과도한 소비를 초래한다. 그러나, 응답을 한 번 생성한 후 이를 캐시에 저장하고 동일한 요청이 들어올 때 이를 재사용하면, 서버는 반복적인 연산을 줄일 수 있다. 이로 인해 서버 자원을 보다 효율적으로 사용할 수 있고, 다수의 사용자에게 빠르게 캐시된 응답을 제공할 수 있다.

 

 

01. HTTP Cache : 웹브라우저와 웹서버 사이 임시 중간 저장소

웹브라우저와 웹서버는 반복되는 요청에 대해 부담을 나누기 위해 HTTP Cache 기술을 도입하였다.

웹브라우저와 웹서버 사이 HTTP Cache에 재활용하려는 HTTP Resource 결과를 저장한다.

 

HTTP 캐시에서 데이터를 저장하는 위치는 크게 두가지로 Shared 캐시와 Private 캐시로 나뉘며, Public과 Private이나는 두 가지 타입으로 구분된다. 또한 위 그림처럼 중간 저장소를 활용하여 데이터를 저장해두어 요청이 들어올 때 해당 데이터가 저장소에 있으면 HIT을 한 후, 해당 요청에 대한 데이터를 바로 반환해주어 시간이 절약된다.

• Shared 프록시 캐시 : 여러 사용자나 클라이언트가 공통으로 사용하는 캐시 공간. 주로 프록시 서버(CDN, Forward/Reverse Proxy)에서 사용.
• Private 브라우저 캐시 : 각 사용자가 개별적으로 사용되는 캐시로, 웹브라우저에 저장. 각 사용자가 자신의 브라우저에 캐시된 데이터를 사용하므로, 사용자마다 캐시된 내용이 다를 수 있다. 사용자의 로그인 정보나 개인 설정과 같이 개인화된 데이터에 적합하다.

 

• Public 캐시 : Private 캐시와 Shared 캐시 모두에 저장될 수 있다. 즉, Public으로 지정된 데이터는 브라우저에도 캐시되고, 프록시 서버와 같은 Shared 캐시에도 저장될 수 있다. 이렇게 하면 다양한 사용자와 위치에서 동일한 데이터를 빠르게 제공할 수 있다.
• Private 캐시 : Private 캐시에만 저장된다. 이 데이터는 웹 브라우저에만 저장되고, Shared 캐시에는 저장되지 않는다. 개인화된 정보나 특정 사용자만이 사용할 수 있는 데이터는 Private 캐시로 지정되어 다른 사용자와 공유되지 않도록 한다.

•  

 

 

#1. HTTP Cache 종류

◼︎ Private : 웹브라우저에 위치

해당 웹브라우저만을 위해 캐시가 사용된다.

 

웹 서버가 HTTP Cache 헤더 통한 제어

• 200(disk cache) : 웹브라우저 캐시 사용시 웹서버에게 원본 요청 없이 바로 캐시 사용
• 200(memory cache) : 웹브라우저가 반복적 리소스 조회 성능 개선을 위해 나름 캐싱. 따로 헤더 통한 캐시 설정 없이 웹브라우저가 자체적으로 최적화를 위해 캐시해주는 것
• 304(not modified) : 기간 만료시 웹브라우저가 웹서버에게 원데이터 변경 여부 확인 = 재검증

 

 

◼︎ Shared : 웹브라우저와 웹서버 사이 프록시에 위치

• 프록시 캐시 : 웹서버 HTTP Cache 헤더를 통한 제어
• 관리형 캐시 : 서비스 개발자가 직접 정책 제어, 배포, 캐싱할 데이터 직접 업로드로 관리

 

 

 

 

02. HTTP Cache 동작 : 재검증을 통한 캐시값의 준실시간성 보장

실시간성이 매우 중요한 데이터는 성능 문제가 발생해도 캐시를 사용하지 않아야 한다.

캐시는 준실시간성을 보장하여 캐시해놓은 데이터가 너무 오래된 데이터가 되지 않도록 특정 주기에 따라 재검증을 해주어야 한다.

 

#1. HTTP Cache 동작 원리

캐시는 임시 저장을 위한 준실시간성을 보장하는 정책이다.

준실시간성은 캐시해놓은 데이터가 너무 오래된 데이터가 되지 않도록 특정 주기에 따라 재검증을 해주어야 하는 것을 뜻한다.

 

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

< 재검증 검증 방법 : 조건부 요청 사용 = 재검증 기준이 되는 값을 서버에 보냄 >

• 재검증 주기 : 캐시해놓은 데이터를 얼마 간격으로 재검증할지
• 재검증 기준 : 캐시해놓은 데이터가 오래됐는지 여부를 원본 주인인 웹서버가 판단하기 위한 기준 근거
  • 수정일 : Last-Modified
  • 고유값 : ETag

 

💡 재검증 기준 : Last-Modified - 수정일 기반

: 전송 Resource의 마지막 수정일

: 캐시가 유효한지(원본이 바뀌었는지) 여부를 시간 기반 판단

 

💡 재검증 기준 : ETag - 고유값(해시 기반)

: 전송 Resource의 고유값(해시, ID)

: 캐시가 유효한지(원본이 바뀌었는지) 여부를 고유값 기반 판단

 

 

 

03. HTTP Cache 동작 : Cache-Control 헤더 통한 세부 설정

캐시할 데이터는 웹서버가 반환하는 값으로, 반환 값에 대한 소유주는 웹서버이므로 웹서버가 캐시를 모두 제어한다.

 

💡 저장 여부

• no-store : 캐시 안함
• no-cache : 캐시 함. 단, 매번 재검증 후 사용 (패킷 경량화)

 

💡 저장 장소

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

 

💡 재검증 주기

• max-age : 캐시된 데이터의 유효 기간을 설정. 이 기간동안 캐시된 데이터를 서버 재검증없이 사용할 수 있다. max-age=0이면 매번 서버와 재검증해야 한다는 것을 의미하며 no-cache와 같은 것을 의미한다.
• s-maxage : 프록시 서버에서만 적용되는 유효기간. s-maxage=31536000(1년), max-age=0은 브라우저는 매번 CDN과 재검증하지만, CDN은 1년 동안만 서버와 재검증한다는 의미. 

 

💡 재검증 강제

• must-revalidate : 캐시된 데이터를 사용하기 전에 반드시 웹서버와 재검증해야 한다는 것을 의미. 서버와의 재검증이 실패할 경우, 기본적으로 기존에 캐시된 데이터를 사용하지만, must-revalidate가 설정되어 있다면 서버와의 재검증이 실패한 경우 캐시된 데이터를 사용하지 않고 504 에러 메시지를 반환

 

💡 SWR

SWR은 HTTP 캐싱 전략으로, 사용자에게 즉시 캐시된 데이터를 제공하면서 백그라운드에서 최신 데이터를 서버로부터 가져오는 방식.

예를 들어, stale-while-revalidate=60일 경우, 캐시된 데이터가 60초 이내에 요청되면 즉시 캐시된 데이터를 반환하고, 동시에 서버와 재검증을 통해 최신 데이터를 가져와 캐시를 업데이트한다. 사용자는 빠르게 응답을 받으면서도 다음 요청시 최신 데이터를 사용할 수 있게 된다.

 

 

 

 

04. HTTP Cache 이점

#1. 웹서버 입장

웹서버 부하 완화

• 반복 연산 감소 : 서버가 한 번 생성한 응답을 캐시에 저장하면, 동일한 요청이 들어올 때 캐시된 데이터를 반환하여 불필요한 연산을 피할 수 있다.
• 트래픽 분산 : 전 세계에 분산된 캐시 서버를 통해 콘텐츠를 제공하므로, 웹 서버에 집중되는 트래픽을 분산

 

#2. 웹브라우저 입장

• 네트워크 트래픽 감소 : 트워크를 통한 데이터 전송이 줄어들고, 전체 트래픽이 감소
• 유저 경험 증진 : 사용자가 웹사이트를 더 빠르게 이용할 수 있도록 도우며, 페이지 로딩 속도가 빨라지면 사용자는 더 원활한 브라우징 경험을 하게 되고, 사이트의 응답성이 높아져 사용자의 만족도가 증가