CDN Request Flow
CDN 요청은 라우팅, 캐시 판단, 원본 재검증으로 나뉜다
사용자 요청은 먼저 적절한 엣지 PoP로 유도된다. 엣지는 캐시 키와 정책을 확인하고, hit이면 바로 응답하며 miss이거나 재검증이 필요할 때만 origin으로 간다.
DNS 기반 steering 또는 Anycast 등 CDN별 방식으로 엣지에
도달한다
Cache-Control은 브라우저 캐시와 공유 캐시의 동작을 나눈다
purge, versioned filename, short TTL은 서로 다른 무효화
전략이다
1Edge 선택
DNS 기반 steering 또는 Anycast 등 CDN별 방식과 라우팅 정책, 부하 상태로 PoP에 도달한다.
DNS 기반 steering 또는 Anycast 등 CDN별 방식과 라우팅 정책, 부하 상태로 PoP에 도달한다.
2Cache key 계산
URL, Host, query, 일부 header/cookie 정책으로 캐시 항목을 찾는다.
URL, Host, query, 일부 header/cookie 정책으로 캐시 항목을 찾는다.
3Freshness 판단
max-age, s-maxage, revalidation 상태를 확인한다.
max-age, s-maxage, revalidation 상태를 확인한다.
Edge cache decision
HIT
엣지에서 즉시 응답
원본 서버, 장거리 링크, DB 근처 네트워크를 거치지 않는다.
MISS / REVALIDATE
원본으로 fetch
응답을 받아 사용자에게 보내고, 정책이 허용하면 엣지에 저장한다.
Stale-while-revalidate
만료된 캐시를 잠깐 응답하면서 백그라운드에서 새 버전을 받아
다음 요청에 반영한다.
max-age브라우저와 CDN 모두에 기본 freshness 시간을 준다.
s-maxageCDN 같은 공유 캐시에 우선 적용되는 TTL이다.
no-cache저장은 가능하지만 사용 전 원본 재검증이 필요하다.
no-store브라우저와 CDN이 응답을 저장하지 말라는 지시다.
핵심: CDN 성능은 단순히 “복사본이 있다”가 아니라, 올바른 cache key, TTL, 재검증, 무효화 전략이 맞물릴 때 나온다.