캐시가 없는 경우

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야한다. (중복)
• 인터넷 네트워크는 매우 느리고 비싸다.(하드웨어 기준)
• 브라우저 로딩 속도가 느리다
• 느린 사용자 경험

캐시가 있는 경우

• 캐시 덕분에 캐시가 유효한 기간? 동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다.
• 브라우저 로딩 속도가 매우 빠르다.
• 빠른 사용자 경험

캐시 시간 초과

• 캐시 유효 시간이 초과되면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신한다.
• 이때 다시 네트워크 다운로드가 발생한다. → 근데 … 유효기간만 끝나고 서버에 있는 데이터와 캐시 데이터가 동일하면 또 다운로드하면 아깝다 … 그래서 ! 검증헤더와 조건부 요청이 있다.
• 캐시 유효 시간이 초과되면 서버에 요청할 때 다음 두가지 상황이 있다.
  • 서버에서 기존 데이터를 변경함 ⭐️ → 💫
  • 서버에서 기존 데이터를 변경하지 않음 ⭐️

검증 헤더 추가

Last-Modified 를 추가한다.

• Client —— 요청 ——> Server
• Client <—— 응답 —— Server 이때 Last-Modified(검증) 헤더를 추가한다.
• 어느덧 30일 후 , Client - 엇! 캐시가 만료되었네? 엇!!!! 근데 Last-Modified가 있네 ? 그러면!
• Client —— 요청 ——> Server if-modified-since(조건부 요청) 요청할때 헤더에 담아서 서버에 있는 데이터랑 비교하자
• Client <—— 응답 —— Server 변경 되지 않았을 경우, 304 Not Modified 를 준다.(바뀌었을 경우 200) 단! HTTP BODY가 없다. ⇒ HTTP 헤더만 넘겨주기 때문에 빠르다

검증헤더와 조건부 요청 1

정리

• 검증 헤더가 있는 캐시 유효시간이 초과해도 서버의 데이터가 갱신되지 않으면 조건부 요청을 한다.
• 304 Not Modified + 헤더 메타 정보만 응답(바디 X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다.
• 클라이언트 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드하여 매우 실용적이다.

---

검증헤더와 조건부 요청 2

검증 헤더

캐시 데이터와 서버 데이터가 같은지 검증하는 데이터

• Last-Modified, ETag

조건부 요청 헤더

검증 헤더로 조건에 따른 분기

• If-Modified-Since: Last-Modified 사용
• If-None-Match: ETag 사용

Last-Modified, If-Modified-Since 단점

• 1초 미만 단위 캐시 조정 불가
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터가 같은 경우 예) A → B →A

ETag, If-None-Match

• 캐시 제어 로직을 서버에서 완전히 관리한다.
• 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기!
• 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
• 예) 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신
• Client 에서 요청 GET If-None-Match: ’starTag’ → Server
• 요청 받은 ETag가 있으면 서버는 304 Not Modified 응답에 HTTP Body는 없음