캐시 개요

캐시

캐시가 없을 때 문제점

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.

• 인터넷 네트워크는 매우 느리고 비싸다.

• 브라우저 로딩 속도가 느리다.

캐시 적용시 장점

• 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다.
• 브라우저 로딩 속도가 향상된다.

캐시 제어 헤더

• Cache-Control : 캐시제어

  • max-age : 캐시 유효 시간, 초 단위
  • no-cache : 데이터는 캐시해도 되지만 항상 origin 서버에 검증하고 사용
  • no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨, 메모리에서만 사용하고 ASAP 삭제
  • public : 응답이 public 캐시에 저장되어도 됨
  • private : 해당 클라이언트만을 위한 응답, public 제약
  • s-maxage : 프록시 캐시에서 사용되는 max-age

• Pragma : 캐시제어 (하위 호환)

  • 굳이 사용 할 필요 없음

• Expires : 캐시 유효 기간 (하위 호환)

  • 날짜로 지정

  • 굳이 사용 할 필요 없음

캐시 무효화 헤더

캐시 무효화를 위해 필수적으로 적용해야할 헤더들이다.

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

캐시 생명주기와 검증 헤더

캐시 유효시간이 초과해서 서버에 다시 요청할 경우 두 가지 경우의 수가 있다.

1. 요청한 데이터가 그대로일 경우
2. 요청한 데이터가 바뀌었을 경우

2번 같은 경우는 오히려 유효 시간을 잘 설정하여 정확하고 최신화 된 데이터를 받은 경우라고 볼 수 있다.

하지만 1번의 경우는 결과적으로 캐시가 없을 때의 문제점이 재발하게 된 것 이다.

이런 문제를 해결 하기 위해 검증 헤더를 사용한다.

검증 헤더와 조건부 요청

검증헤더와 조건부 요청을 통해 캐시를 효율적으로 관리할 수 있다.

처리 과정

대략적인 로직은 이렇다

1. 서버에서 데이터 요청에 대한 응답에 캐시 유효기간과 함께 Last-Modified 와 같은 검증헤더를 추가해서 보낸다.
2. 유효기간이 만료된 후 클라이언트가 서버에 다시 해당 데이터를 요청 할 때, 검증헤더를 이용한 조건부 요청을 함께 서버에 요청한다.
3. 서버는 해당 조건부 요청을 확인 후 조건이 만족하지 않을 때(데이터가 변경되지 않았을 때) 304 응답 메시지를 보낸다.
4. 클라이언트는 받은 헤더만을 이용해 기존에 있던 캐시의 헤더데이터만을 갱신하여 데이터를 재사용한다.

검증 헤더 상세

• 검증헤더
  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  • Last-Modified, ETag
• 조건부 검증 헤더
  • 검증 헤더로 조건에 따른 분기
  • if-Modified-Since : Last-Modified 검증헤더를 사용 할 때
  • if-None-Match : Etag 검증헤더를 사용 할 때
  • 조건이 만족하면 200 OK
  • 조건이 만족하지 않으면 304 Not Modified

프록시 캐시

오리진 서버와 별도로 프록시 캐시 서버를 둠으로서 다양한 클라이언트에서 오는 많은 데이터 요청을 효율적으로 처리하기 위한 시스템

CDN 서버라고도 불림