브라우저 캐시

캐시는 브라우저에서 서버에 최초 요청 이후 로딩을 더 빠르게 하기 위한 장점이 있다.

그러나 요청에 의해 캐시가 저장되면 이후 변경 내용이 있어도, 사용자 브러우저의 캐시에 의해 캐시를 지우기 전까지 변경 내용의 수정이 일어나지 않을 수 있다.

우리는 header의 cache-control 태그를 이용해 max-age 속성으로 캐시의 수명을 지정할 수 있다.

말만 들으면 max-age=60 으로 설정해놓으면 60초 동안 캐싱된 데이터를 사용하고, 그 이후는 캐싱된 데이터를 사용하지 않고 새 응답을 받는 것 같다. (200을 받을 것같으나)

하지만 이것은 명확한 캐시 수명이 아니다. 60초 이후에도 브라우저는 캐싱된 데이터를 확인하며 캐싱된 데이터가 있다면 304 Not Modified 응답을 준다.

결국,, 브라우저에게 어떤 기준으로 해당 파일은 업데이트되었으니 새로운 응답값을 받으라고 명령할까?

이때 비교할 수 있는 것이 ETag헤더와 Last-Modified헤더이다.

Last-Modified

• If-Modified-Since 요청 헤더와 함께 사용된다
• 서버의 데이터 최종 수정 시각을 비교하여 데이터 수정 여부를 확인한다

ETag

• 특정 버전의 리소스를 식별하는 고유 식별자 (데이터 버전 또는 해시값)
  • 파일이 변경될 때마다 새 ETag값을 생성하고 이전 ETag값을 비교한다
• If-None-Match 요청 헤더와 사용된다
• Last-Modified 헤더의 한계를 극복하기 위한 리소스 검증 헤더이다

위의 값을 비교하여 캐싱된 값이 있으면 304 Not Modified , 없으면 200 OK 로 새 응답값을 받아온다.

프록시 캐시

클라이언트와 본서버를 중계하는 서버 대리자이며 이 것을 캐시 서버로 이용할 수 있다. CloudFront가 대표적인 예이다.

클라이언트(브라우저)에서 사용되고 저장되는 캐시는 private 캐시이며 프록시 서버의 캐시는 public 캐시이다.

이렇게 웹 브라우저 캐시와 프록시 서버의 캐시는 분리되어 운용되기 때문에 Cache-Control 헤더와 프록시 전용 캐시 설정 둘다 이루어져야한다\

ref

• 🌐 웹 브라우저의 Cache 전략 & 헤더 다루기
• 웹 Cache(웹 브라우저 캐시) & 헤더 다루기