Caching?
리소스 복사본을 저장하고 잇다가 요청시에 제공하는 기술.
웹 캐시가 저장소 내에 요청된 리소스를 가질 경우, 요청을 가로채 원래 서버로부터 리소스를 다시 다운로드 하는 대신 리소스의 복사본을 반환.
기대효과 ?
- 서버의 부하 완화
- 네트워크 트레픽 절감
👉🏻 성능 향상
"리소스가 변하는 경우"가 있으므로 이에 주의.
Cache-Control Header
HTTP 에서 캐시는 Cache-Control 헤더에 따라 동작 방식이 다르다.
no-cache
캐시를 사용하지 않는 것이 아니라, 매번 요청을 엔드포인트 서버까지 도달시켜 상태를 검사함. (Fresh vs Stale)
no-store
캐시를 사용하지 않는 것.
private
하나의 Endpoint 클라이언트 브라우저 전용.
ex) 뒤로가기시 이미 다운로드 받았던 파일을 캐싱을 통해 재활용하는데 쓰인다. (오프라인 브라우징)
public Cache
한명 이상 사용자에 의해 재사용되는 응답을 저장하는 캐시.
ex) ISP 내의 회사망, 동일 프록시 내의 모든 사용자에게 공유되는 캐시
must-revalidate
Stale state resource일 때 Endpoint origin 으로 항상 상태 검사를 하도록 하는 헤더
캐시의 상태는 2가지로 나뉜다.
1. Fresh state (최신의 리소스)
2. Stale state (기간 만료됨)
Cache-Control
max-age
유효성 (Freshness)
Cache Eviction
캐시는 저장공간이 한정되어 있으므로 주기적으로 사용하지 않는 리소스를 제거하거나 상태를 업데이트 하는 매커니즘.
'원본'은 항상 서버에, '사본'이 캐시에 저장된 다는 사실을 기억하자.
원본이 바뀌면 사본은 유효성(Freshness)를 잃는다.
하지만, 서버 입장에서는 캐시나 클라이언트에게 "야!! 나 리소스 업데이트했어!!!" 를 바로 알려줄 수가 없다.
HTTP 프로토콜은 항상 클라이언트의 요청이 있을때만 커뮤니케이션이 가능하기 때문이다.
그래서 이 cache eviction 이라는 매커니즘이 필요하다.
서버는 리소스에 대한 만료시간을 max-age 혹은 expiration 으로 명시한다. (명시하지 않을경우 Heuristic 알고리즘 사용)
=> "이 시간이 지나면 유효성을 확인해야해!"
만료시간 이전 => Fresh state
만료시간 이후 => Stale state
캐시가 stale state resource 에 대한 요청을 받을 경우 포워딩하며 If-None-Match와 함께 요청을 전달한다.
서버는 리소스가 변경되지 않았을 경우 304 Not Modified헤더만 응답한다. (body 보내지 않는다.)
Question '만료시간'은 어떻게 아나요 🤔 ?
서버의 Last Modified, etag 헤더로 알 수 있다. 이에 대한 자세한 내용은 다음편에 다룬다.
imutable
만료되지 않은 경우, 서버에서 변경되지 않을 때만 사용.
주로 변경되지 않는 리소스에 대해, max-age 를 길게하여 사용한다.
⚠️ 표준이 아니기 때문에, 호환성을 확인하고 사용해야한다.
변경 되지 않는 이미지, PDF 파일 같은 것들은 Static Caching을 사용하자.
Cache-Control: Public, max-age=86400
=> 86400초 (1일)간 유지되는 공유캐시
ETag (Entity Tag)
서버에서 생성한 임의의 문자열 값.
클라이언트가 첫 요청시 이 etag 값을 반환하여 클라이언트는 다음 요청부터 리소스가 캐시에서 stale state 일 경우 자신이 가졌던 etag 값을 If-None-Match 헤더에 싣어 보내 유효성을 검사한다.
✅ 일치 => Return Not Modified (304) with no body
❌ 불일치 (리소스 업데이트됨) => return updated resource (200)
Reference
