브라우저 캐싱 전략

WEB

송이 🫧 2024. 1. 21. 21:29

웹 브라우저에서 서버로 데이터를 요청할 때, 캐시가 없을 경우 데이터가 변경되지 않았더라도 네트워크를 통해 데이터를 다운로드 받아야 한다.

캐시를 사용하면 불필요한 네트워크 통신 없이 좀 더 빠른 사용자 경험을 할 수 있다.

1. cache-control 적용

- response header에 캐시가 유효한 시간(초)를 함께 반환해 브라우저가 해당 시간동안 캐시로 응답 결과를 저장하도록 한다.

- 캐시 시간이 초과되면 다시 네트워크로 요청을 보내 응답을 가져오고 다시 유효시간동안 캐시로 저장하게 된다. (갱신)

- 브라우저는 cache-control 정보를 받으면 설정된 시간동안 새로운 요청이 와도 리소스를 요청하지 않는다.

- 클라이언트의 메모리 캐시 -> 디스크 캐시 순으로 확인하여 데이터를 찾는다.

EX) cache-control: max-age=60(초)

2. 캐시 시간의 초과

캐시 유효 시간이 초과한 경우 아래와 같은 서버는 아래 2가지 상황 중 하나를 가질 것이다.

1) 서버에서 기존 데이터를 변경

2) 서버에서 기존 데이터를 변경하지 않음

만약 캐시 만료후에도 서버에서 데이터가 변경되지 않았다면 브라우저의 캐시를 재사용할 수 있다.

이를 위해 클라이언트의 캐시 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다.

3. 검증 헤더 추가 (Last-Modified)

1) 데이터가 마지막에 수정된 시간 추가

데이터가 마지막에 수정된 시간을 응답헤더에 함께 보냄

최대 캐시 유효시간이 지난 경우

브라우저 캐시가 가지고있는, 데이터 최종 수정일이후로 변경되었는지 조건부 요청(If-Modified-Since)을 함께 보냈을 때,

만약 데이터가 아직 변경되지 않았다면 304(Not Modified) 응답과 함께 서버는 body 없이 응답을 준다.

결과적으로 네트워크를 타긴 하지만 Body가 없이 오기 때문에 훨씬 적은 비용으로 통신이 가능하다.

4. 검증 헤더 추가 (ETag)

- 데이터를 수정해서 날짜는 변경되었지만 만약 같은 데이터를 수정해서 결과가 똑같은 경우 캐시를 유지할 수 있는 방법이 있다.

- ETag 란 캐시용 데이터에 대해 고유한 해시값을 생성하여 실제로 값이 같으면 같은 해시값을 가진다.

응답 헤더에 ETag 를 담아서 보내주면 브라우저 캐시가 해시값을 저장한다.

만약, 브라우저 유효 캐시 시간이 만료되어 조건부 요청(If-None-Match)과 함께 서버에 요청을 보내게 되면

마찬가지로 해시값을 비교해서 데이터의 변경이 없는 경우 304(Not Modified) 응답을 보내준다.

즉 검증헤더와 조건부 요청은 함께 쓰인다.

- If-Modified-Since: Last-Modified 사용

- If-None-Match: ETag 사용

1. Cach-Control: max-age -> 캐시 유효 시간, 초 단위

2. Cach-Control: no-cache -> 데이터는 캐시해도 되지만, 항상 원 서버에서 검증하고 사용, 원 서버 접근 불가한 경우 캐시 데이터 반환 가능

3. Cach-Control: no-store -> 데이터 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

4. Cache-Control: must-revalidate -> 캐시 만료 후 최초 조회시 원 서버(프록시 캐시 서버 X)에 검증, 원 서버 접근 불가한 경우 오류 발생

- Cache-Control : public -> 응답이 public 캐시에 저장되어도 됨

- Cache-Control : private -> 응답이 해당 사용자만 위한 것이라 private 캐시에 저장해야함

- Cache-Control : s-maxage -> 프록시 캐시에만 적용되는 max-age

- Age : 60 (HTTP 헤더) -> 원 서버 응답 후 프록시 캐시 내에 머문 시간

김영한님 강의 - 모든 개발자를 위한 HTTP 웹 기본 지식