캐시

캐시

 > 데이터나 값을 미리 복사해 놓는 임시 장소

 > 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용

 > 브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있음

 

캐시 검증 헤더와 조건부 요청

 > 캐시의 유효시간이 초과하면 다시 서버에 요청을 보내 새로운 데이터로 캐시를 업데이트

 > 하지만 캐시의 유효기간이 지났지만, 데이터의 변경이 없는 경우?

 > 검증 헤더 사용

 

★ 검증 헤더

● If-Modified-Since: ${data}(요청) -> Last Modified: ${data}(응답)

 > 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함

 

1. 데이터가 수정되었는지 검증

2. 304 Not Modified +수정되지 않았다면 HTTP 헤더만 전송

3. 브라우저 캐시에서 응답 결과를 재사용, 헤더 메타데이터 또한 갱신

4. 브라우저는 캐시에서 조회한 데이터를 렌더링

 

★ 단점:

 - 1초 미만 단위로 캐시 조정 불가능

 - 날짜 기반 로직 사용

 - 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우

 - 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

 

● 1. ETag: "${data}"(요청) -> 서버에서 ETag 저장(응답) -> 다시 ETag 보냄, 캐시에서 저장 

● 2. if-None-Match: "${data}"(요청) -> ETag(Entity Tag): "${data}"(응답) 

> 캐시의 데이터에 임의의 고유한 버전 이름을 달아둠

  - ETag: "v1.3", ETag: "3aewq5eqweq684eqwe486"

> 데이터가 변경되면 이 이름을 바꾸어서 저장(Hash를 다시 생성"

> ETag를 보내서 같으면 유지, 다르면 다시 받는 방식 

 

장점 > 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식 > 캐시 제어 로직을 서버에서 완전히 관리 > 클라이언트는 단순히 이 값을 서버에 제공 > 서버는 베타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일 유지 > 애플리케이션 배포 주기에 맞춰 ETag 갱신

 

 

● Cache-Control: max-age (캐시 유효 기간)

 

● Cache-Control: no-cache (데이터는 캐시해도 되지만, 항상 원 서버에서 검증)

 

● Cache-Control: no-store ( 민감한 정보이므로 캐시 저장하면 안됨)

 

Expires

 > 정확한 날짜를 캐시 만료일로 지정

 > HTTP 1.0부터 사용

 > 지금은 max-age 권장

 > max-age 사용하면 Expires는 무시