HTTP 캐시

HTTP 캐시란

HTTP 캐시는 한 번 받은 응답을 저장해 두었다가 같은 요청에 재사용하는 것이다. 네트워크 왕복을 아예 없애거나(신선한 캐시), 본문 전송만 생략한다(재검증). 캐시는 브라우저(private cache)와 CDN·프록시(shared cache) 두 곳에 생긴다.

캐시가 놓이는 곳

요청이 사용자에서 원본 서버까지 가는 길목마다 캐시가 있을 수 있다.

브라우저 캐시는 다시 두 층이다. DevTools Network 패널의 Size 열에 (memory cache)·(disk cache)로 구분해 보인다.

어느 층에 둘지는 브라우저가 정하고 개발자가 고를 수 없다. 개발자가 다루는 것은 아래 헤더로 정하는 재사용 여부와 기간이다.

앞쪽 캐시가 맞을수록 왕복 시간(RTT), 서버 부하, 대역폭 비용이 함께 준다. 반대로 층이 많을수록 무효화가 어렵다. 배포 뒤 옛 응답이 남았다면 어느 층의 캐시인지부터 가린다. CDN은 CDN, 프록시는 프록시, 서버 쪽 캐시는 캐싱 전략에 있다.

어떻게 캐시할지는 서버가 응답 헤더로 정한다. 프론트엔드 개발자는 이 헤더를 읽고 배포 설정에서 고칠 수 있어야 한다.

두 단계: 신선도와 재검증

flowchart TB
  rq["요청"] --> q1{"캐시에 있음?"}
  q1 -->|"없음"| s200["서버에서 받기 (200)"]
  q1 -->|"있음"| q2{"아직 신선? (max-age 이내)"}
  q2 -->|"예"| use["서버에 묻지 않고 바로 사용"]
  q2 -->|"아니오"| rv["조건부 요청으로 재검증"]
  rv -->|"안 바뀜"| r304["304 Not Modified (본문 없음)"]
  rv -->|"바뀜"| r200["200 + 새 본문"]

신선도는 어떻게 정해지나

재검증 헤더

Last-Modified는 날짜라서 한계가 있다. 1초 안에 두 번 바뀌면 구분하지 못하고, 내용이 같아도 파일을 다시 저장하면 날짜가 바뀌어 전체를 다시 받는다. ETag는 서버가 붙이는 버전 이름(보통 내용 해시)이라 내용이 같으면 같은 값을 준다. 서버가 값을 정하므로 「주석·공백만 바뀐 배포에서는 ETag를 유지한다」, 「배포 주기에 맞춰 한꺼번에 갱신한다」처럼 캐시 정책을 서버가 통제할 수도 있다. 둘 다 있으면 If-None-Match가 우선한다. 어느 쪽이든 안 바뀌었으면 서버는 본문 없이 304와 갱신된 헤더(Cache-Control, ETag)만 보내고, 브라우저는 저장된 본문을 다시 쓰며 신선도 시간을 새로 센다.

Cache-Control 지시어

no-cache와 no-store를 헷갈리기 쉽다. 이름과 달리 no-cache는 캐시한다.

Pragma: no-cache는 HTTP/1.0 시절의 캐시 금지 헤더다. Cache-Control이 있으면 무시되므로 새로 쓸 일은 없다. 과거에는 민감한 페이지에 Cache-Control: no-cache, no-store, must-revalidate와 Pragma: no-cache를 함께 붙였지만, 지금은 no-store 하나로 충분하다.

캐시 키와 Vary

캐시는 기본적으로 URL로 응답을 구분한다. 같은 URL이라도 Accept-Language, Accept-Encoding, Accept에 따라 본문이 다르면(콘텐츠 협상) 응답에 Vary를 붙여 그 요청 헤더까지 캐시 키에 넣게 한다.

Vary: Accept-Encoding, Accept-Language

Vary: Cookie나 Vary: User-Agent처럼 값이 사용자마다 다른 헤더를 넣으면 사실상 캐시가 안 된다. 사용자별 응답은 Vary로 쪼개지 말고 private으로 보낸다. Authorization 헤더가 붙은 요청의 응답은 public이나 s-maxage를 명시하지 않는 한 공유 캐시에 저장되지 않는다.

자산별 전략

새로고침, 무효화, 흔한 문제

• 새로고침해도 하위 자원까지 다시 확인하지 않게 하려면 immutable을 쓴다. Chrome은 이 지시어 대신 새로고침 때 하위 자원을 재검증하지 않도록 구현을 바꿨다.
• 긴 max-age로 이미 저장된 응답은 서버가 지울 방법이 없다. 요청이 서버까지 오지 않기 때문이다. Clear-Site-Data: "cache"는 그 사이트의 브라우저 캐시만 지우고 CDN·프록시에는 효과가 없다(CDN은 퍼지 API로 지운다). 그래서 자주 바뀌는 URL은 no-cache로 서버가 통제권을 쥐고, 길게 캐시할 파일은 URL에 해시·버전을 넣는 캐시 무효화(cache busting) 로 바꾼다. 쿼리(?v=123)보다 파일 이름(bundle.3f2a1c.js)에 넣는 편이 일부 캐시가 쿼리를 무시하는 문제를 피한다.
• 공유 캐시는 같은 요청이 동시에 몰리면 원 서버에 하나만 보내고 결과를 나눠 준다(요청 병합, request collapse). 이때 no-cache 응답도 동시 요청끼리는 재사용되므로, 개인화된 응답은 반드시 private으로 표시한다.
• 배포했는데 옛 화면이 보인다: HTML이 길게 캐시되어 옛 번들을 가리키는 경우가 많다. HTML 캐시 헤더부터 확인한다.
• 캐시에서 왔는지, 헤더가 의도대로인지는 DevTools Network 패널로 확인한다: DevTools Network 패널.

정리

• 신선하면 서버에 묻지 않고, 만료되면 ETag·Last-Modified로 재검증한다.
• 정책은 Cache-Control 하나에 거의 다 담긴다.
• no-cache는 "매번 확인", no-store는 "저장 금지"다.
• 해시 파일은 1년 + immutable, HTML은 매번 재검증이 기본이다.
• 이미 저장된 응답은 서버가 지울 수 없다. 바꿔야 할 파일은 URL을 바꾸고, 콘텐츠 협상을 하면 Vary를 붙인다.

관련 노트: CDN, HTTP 프로토콜, SWR, 캐시 메모리와 MMU, 캐시 클러스터 운영과 장애 대응, 이미지 CDN과 Accept 헤더 협상, 이미지·동영상 처리 서버 설계