“김영한” 님의 인프런 강의 “모든 개발자를 위한 HTTP 웹 기본 지식”을 듣고 정리한 글입니다.

캐시

1. 캐시 기본 동작

  • 캐시 미적용
    • 데이터가 변경되지 않아도 데이터를 계속 다운받아야 한다.
    • 느린 브라우저 로딩, 나쁜 사용자 경험
  • 캐시 적용
    • cache-control: max-age
    • 캐시 가능 시간동안 네트워크를 쓰지 않아도 된다.
    • 빠른 브라우저 로딩, 좋은 사용자 경험
  • 캐시 시간 초과
    • 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신
    • 네트워크 다운로드가 발생(BAD)

2. 검증 헤더와 조건부 요청1

  • 검증 헤더
    • 캐시의 데이터가 수정되었는가?
    • 캐시 시간은 지났으나, Last-Modified(최종 수정일)이 같으면
      304 Not Modified (HTTP Body가 없음. Header만 전송)
      네트워크 부하가 감소 (네트워크 다운로드가 발생 안 하는 건 아님)
      클라이언트에서 캐시를 갱신한다. 데이터 재활용.
    • 조건부 요청: if-modified-since
  • 상태 코드의 색깔이 연한 것은 캐시에서 가져온 것이다.

3. 검증 헤더와 조건부 요청2

  • 검증 헤더
    • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
    • Last-Modified, ETag
  • 조건부 요청 헤더
    • 검증 헤더로 조건에 따른 분기
    • If-Modified-Since: Last-Modified 사용
    • If-None-Match: ETag 사용
    • 조건이 만족하면 200 OK
    • 조건이 만족하지 않으면 304 Not Modified
      (캐시로 리다이렉션)
  • Last-Modified 방식의 단점
    • 1초 미만 단위로 캐시 조정 불가능
    • 날짜 기반의 로직 사용
    • 데이터를 수정했지만 결과는 동일한 경우
    • 서버에서 별도의 캐시 로직을 관리하고 싶을 때
      (크게 영향이 없는 변경에서 캐시를 유지하고 싶을 때)
  • ETag
    • Entity Tag
    • 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
    • ETag만 보내서 같으면 유지, 다르면 다시 받기
    • 캐시 제어 로직을 서버에서 완전히 관리
      (클라이언트는 캐시 메커니즘을 모름)

4. 캐시 제어 헤더

  • Cache-Control (가장 중요)
    • max-age
      캐시 유효 시간, 초 단위
    • no-cache
      데이터는 캐시해도 되지만, 항상 원(origin) 서버에서 검증 후 사용
      (이름에 주의)
    • no-store
      데이터에 민감한 정보가 있으므로 저장하면 안 됨
      (사용 후 최대한 빨리 삭제)
  • Pragma, Expires
    거의 사용하지 않음. 하위 호환

5. 프록시 캐시

  • origin 서버
    진짜 서버. 원 서버.
  • 프록시 캐시 서버
    중간에서 공동으로 사용하는 캐시 서버.
  • CDN(Contents Delivery Network)
    서버를 분산 배치하여, 컨텐츠 전송 중 발생하는
    트래픽 집중 & 병목현상 및 데이터 손실을 해결
  • 캐시 지시어
    • Cache-Control: public
      응답이 public 캐시에 저장되어도 됨
    • Cache-Control: private
      응답이 해당 사용자만을 위한 것임. pivate 캐시에 저장(기본값)
    • Cache-Control: s-maxage
    • Age: 60

6. 캐시 무효화

캐시가 자동으로 적용되기도 한다. 이를 막으려면?

  • Cache-Control: no-cache, no-store, must-revalidate
  • Pragma: no-cache (HTTP 1.0 하위 호환)

참고자료

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의