HTTP Cache 개념 및 Cache-control 헤더

 

웹 성능 개선을 위한 HTTP Cache

웹 페이지 로딩 시간을 단축하는 것은 웹 성능 최적화의 핵심이다. 여기서 중요한 역할을 하는 것이 바로 HTTP Cache.

웹은 클라이언트가 서버에 요청을 보내고 그 결과를 받는 것이다. 이 때  웹 브라우저는 매번 웹 서버에게 요청해서 응답을 받아야하고 웹 서버는 매번 웹 브라우저의 요청에 대한 응답을 만들고 반환해야한다. 이 과정을 반복하면 서버에 부하를 가져올 수 있다. 이렇기에 HTTP Cache를 활용하면 서버와 클라이언트 부하를 모두 줄이고 웹 페이지 속도를 개선 할 수있다. 오늘은 HTTP Cache에 대해 포스팅하고자 한다.

---

웹 브라우저는 매번 웹 서버에 요청을 보내고 서버는 그 요청에 따라 결과를 생성하여 반환한다. 이 과정은 시간과 리소스가 많이 소모된다.

• 웹 브라우저: 매번 동일한 결과를 서버에 요청할 필요가 있을까? 이전에 받아온 결과를 저장하고, 이를 재사용하면 어떨까?  →  Private Cache 의 개념
• 웹 서버: 매번 동일한 결과를 생성할 필요가 있을까? 이전에 생성한 결과를 저장하고, 이를 재사용하면 어떨까? → Public Cache 또는 Shared Cache(Foward/Reverse Proxy or CDN)의 개념

---

웹 브라우저와 웹 서버 측면에서의 HTTP Cache 비용 절감

 

1. 웹 브라우저 측면: 결과 "반환" 비용(시간, 네트워크) 절감

 

웹 브라우저가 서버에 요청을 보낼 때, 서버는 요청에 따라 결과를 생성하고 반환하는 데 시간이 소요된다. 예를 들어, 웹 브라우저가 어떤 리소스를 요청하면, 서버는 그 리소스를 생성하는 데 3초, 그리고 이를 웹 브라우저에 반환하는 데 3초가 걸린다고 가정한다면 총 6초가 소요.

• 캐시를 사용하는 경우:
  • 웹 브라우저가 캐시에 저장된 리소스를 즉시 사용 (0초)
  • 서버에 요청을 보내지 않으므로 네트워크 및 서버 자원 소요 없음
  • 총 소요 시간: 0초

2. 웹 서버 측면: 결과 "생성" 비용(노동, 자원) 절감

 

웹 브라우저가 서버에 요청을 보내면, 서버는 그 요청에 따라 결과를 생성해야 한다. 그러나, 서버가 이전에 해당 결과를 생성하여 캐시에 저장해 두었다면, 서버는 다시 결과를 생성할 필요 없이 캐시된 결과를 반환하기만 하면 된다.

• 캐시를 사용하는 경우:
  • 서버가 이전에 생성한 결과를 캐시에 저장
  • 웹 브라우저가 요청할 때 서버는 결과를 생성하지 않고 캐시에서 바로 반환 (3초)
  • 총 소요 시간: 3초

 

이처럼 HTTP Cache는 서버와 클라이언트 부하를 줄일 수 있고 로드 속도를 개선할 수 있는 중요한 기술이다.

---

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

 

캐시는 웹 브라우저, 프록시 서버, 웹 서버에 위치할 수 있다. 웹 브라우저와 웹 서버는 반복되는 요청에 대한 부담을 줄이기 위해 HTTP Cache를 도입하며, 이 캐시는 웹 브라우저와 웹 서버 사이에서 HTTP Resource를 재활용하기 위한 임시 중간 저장소 역할을 한다.

 

• HTTP Cache 데이터를 캐시하는 곳은 크게 두 곳으로 나늰다.
  • Private Cache: 클라이언트 측에서만 사용되는 캐시로, 특정 웹 브라우저에만 저장된다
  • Public Cache:여러 클라이언트가 공유하는 캐시로, 프록시 서버 또는 CDN과 같은 중간 서버에 저장된다. → Shared Cache

---

Private Cache: 웹 브라우저에 위치

웹 브라우저 캐시: 해당 웹 브라우저(특정 한명)만을 위해 캐시사용

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

Shared: 웹 브라우저와 (원본) 웹 서버사이 프록시에 위치

프록시 캐시: 모든 웹 브라우저(모든 유저)를 위해 캐시가 사용

• 프록시캐시: 웹 서버 HTTP Cache(Cache-control)를 통한 제어
• 관리형캐시: 사용자(개발자)가 직접 제어, 배포, 캐싱할 데이터를 직접 업로드로 관리

 

---

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

웹 서버는 'Cache-Control' 이라는 HTTP 헤더를 사용하여 캐시 동작을 제어할 수 있다.

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

 

• 캐시 저장 여부

no-store: 리소스에 캐시를 저장하지 않는다. 즉 캐시를 안한다.
no-cache: 리소스에 캐시를 저장하되, 매번 서버에서 재검증을한다 → 캐시를 안하는 것이 아니다(헷갈릴 수 있음)

• 재검증 장소

Public: Private(웹 브라우저) + Shared(프록시) 모두에 저장 (브라우저에도 저장한다는 것 기억)
Private: Private(웹 브라우저)에만 저장

• 캐시 재검증 주기

max-age: 리소스의 유효시간(Expires) 설정(기존 Expires가 있다면 덮어씀)
EX) max-age=0 → no-cache = 매번 재검증

s-maxage: 공유 캐시(프록시 서버)에만 적용되는 유효기간
EX) s-maxage=31536000(1년), max-age=0
// 웹 브라우저는 계속 CDN 에게 재검증을 수행, CDN 은 1년을 주기로 본 웹 서버에게 재검증
// 웹 브라우저는 CDN 이 자체적으로 Invalidation(무효화)하지 않는한 1년 동안 같은 데이터만

max-age → WB에만 적용

s-maxsage → Proxy에만 적용

1년이 넘으면 Proxy는 WS에게 revalidate→ WB는 Proxy에게 revalidate

+@ 배포했는데 새버전이 안보인다 → Invalidate

• 재검증 강제: "재검증이 꼭 서버로부터 이뤄진 데이터만 보겠습니다"

must-revalidate: 꼭 웹서버와 직접 재검증이 완료된 뒤 캐시를 사용해야한다는 의미
// 서버와의 접속 문제로 재검증이 실패한 경우 기본 행동은 그냥 기존 캐시되어있는 데이터를 반환
// 하지만 must-revalidate가 활성화 되어있다면 504 Error - 웹서버와 연락두절

• SWR(stale-while-revalidate):"캐시의 즉시성과 최신성을 한번에" 

// 캐시된 데이터는 즉시 사용하고, 백그라운드에서 새로운 데이터를 받아 캐시를 갱신
// 현재에 캐싱된 콘텐츠를 즉시 로드하는 즉시성
// 미래에 업데이트가 된 캐싱 컨텐츠가 사용 될 수 있도록 보장하는 최신성
Cache-Control: max-age=1, stale-while-revalidate=60

즉시성(빨간색)과 최신성(주황색)을 한번에 보장하는 방법

즉시성(빨간색) = 일반적인 Cache반환, 최신성(주황색) = Revalidate, SWR(초록색) = 즉시성(빨간색) + 최신성(주황색)

 

---

ℹ️참고

[ASAC 6기 강의자료]