캐시 기본 동작
서버에 이미지를 요청 ( 캐시 X )
-
요청 ⇒ 서버에서 이미지를 응답 ( 이미지 + 메시지 1.1M )
-
다시 요청 ⇒ 1.1M 다시 응답
-
데이터가 변경되지 않아도 매번 많은 데이터를 다운로드 해야하다
-
네트워크 비용은 느리고 비쌈
-
브라우저 로딩 속도가 느림
-
사용자 불편함
서버에 이미지를 요청 ( 캐시 O )
HTTP header ⇒ + cache-control : max-age=60 ( 캐시가 유요한 시간(초) )
-
60초 동안 캐시가 유요하다
-
요청 ⇒ 서버에서 이미지를 응답 ( 이미지 + 메시지 1.1M )
-
응답에 캐시에 60초 동안
-
다시 요청 ⇒ 캐시 저장소를 확인 ⇒ 1.1M 다시 응답
-
60초 미만이면 캐시 저장소에 있을태니 재요청을 하지 않고 바로 사용
-
캐시 기간 동안 네트워크를 사용하지 않아도 된다
-
네트워크 사용량 감소
-
브라우저 로딩 속도 매우 감소
캐시 시간 초과
- 캐시 유효 기간이 초과되면 서버를 통해 재 조회 후 캐시를 갱신
- 재 조회시 네트워크 다운로드 발생
- 하지만 클라이언트와 캐시저장소에 있는 데이터가 동일하면 이는 비효율적이라 검증을 한다.
검증 헤더 조건부 요청
- 서버에서 기존 데이터를 변경함
- 재 다운로드가 필요
- 서버에서 기존 데이터를 변경하지 않은다.
- 다운로드가 필요 없다
Last-Modified ⇒ 데이터가 마지막으로 수정한 시간
- 캐시를 저장 후 데이터의 최종 수정일을 같이 저장
- 60초과 초과되서 재요청을 보낼 때
Last-Modified를 같이 조회해 - 서버의 데이터 최종 수정일과 저장된 정보의 최종 수정일을 검증 할 수 있다
- 변경되지 않은 경우
HTTP/1.1 304 Not Modified응답- HTTP Body가 없다
요약 → 캐시 메타 정보와 , 검증 헤더를 사용하자
검증 헤더
- 서버의 데이터와 캐시의 데이터가 같은지 검증하는 데이터
- Last-Modified
- 최종 수정 시간
- ETag
조건부 요청
-
검증 헤더를 통해 결과에 따라 보내는 분기
-
if-Modified-Since : Last-Modified- 데이터 미변경 예시
- 304 Not Modified , 헤더 데이터만 전송 (Body 미포함)
- 전송 용량 0.1M ( 헤더 0.M )
- 데이터 변경 시
- 200 OK 모든 데이터 전송
- 전송 용량 1.1M (헤더 0.1M , 바디 1.0M )
- 날짜 기반의 로직( 데이터 수정은 있지만 결과가 동일한 경우 손실 )
- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
- 스페이스 , 주석 컨텐츠에 영향이 변화는 캐시에서 유지하고 싶은 경우
- 데이터 미변경 예시
-
if-None-Match : ETag- 캐시용 데이터에 임의이 고유한 버전의 이름을 사용 가능하다
- 데이터가 변하면 버전의 이름을 바꿔서 변경할 수 있다.
- 데이터 변경 ⇒ 버전 이름을 바꿔서 변경 ( Hash를 다시 생성 )
- ETag를 보내서 같으면 유지 , 다르면 다시 받기
- 캐시 제어 로직을 서버에서 완전히 관리 ( 클라이언트는 캐시 매커니즘을 모른다 )
-
조건에 만족시 200OK
-
조건 만족 하지 않으면 304Not Modified
