✅이렇게 데이터가 변경되지 않아도 계속해서 같은 데이터를 응답해야하고 웹 브라우저는 네트워크를 사용해서 다시 한번 데이터를 다운로드 받아야한다
→ 실제 인터넷 네트워크는 매우 느리고 비싸기에 브라우저 로딩 속도가 느리고, 느린 사용자 경험을 할 수 있다
캐시
캐시는 데이터나 값을 미리 복사해놓는 임시장소로 위와 같은 상황을 해결할 수 있다
❓캐시가 있다면
cache-control : max-age
= 60 라는 헤더를 같이 보낸다실제 네트워크에서 연하게 표시되는것은 캐시에서 가져오는 데이터이고 status code 옆에 (from memory cache)가 적혀있다
✅캐시 장점
❓캐시의 유효시간이 초과되었다면
하지만 만약에 유효시간이 초과되었지만 기존 데이터가 변경되지 않은 상황이라면?
→ 유효시간이 초과되어도 기존 데이터가 변경되지 않았다면 다시 사용할 수 있다
서버는 데이터를 응답할 때 Last-Modified라는 헤더도 함께 전송한다 이는 데이터가 마지막에 수정된 시간을 의미한다
브라우저는 캐시에 데이터를 저장할 때 데이터 최종 수정일 (Last-Modified)를 저장하고 유효시간이 초과되어 다시 데이터를 요청할때 if-modified-since라는 요청헤더에 최종 수정일을 담아 전송한다
만약 데이터가 변경되지 않았으면 서버는 상태코드 304로 http body가 없는 상태에서 응답을 보낸다 ( 1.0M을 전송하지 않은것)
브라우저는 이미지 데이터를 전달받고 응답 결과를 캐시에 재사용하면서 헤더의 메타 데이터를 갱신한다( 다시 cache- control:max -age의 값인 유효시간을 갱신)
이는 매우 실용적인 해결책으로 자주 사용되는 매커니즘이다
검증헤더
조건부 요청 헤더
1초 미만 단위로 캐시 조정이 불가능하고 날짜 기반의 로직을 사용한다
만약 star 이미지를 circle 이미지로 수정후 원래의 star 이미지로 수정했다면 데이터는 수정되지 않았음에도 last-modified가 변경되어 데이터가 변경되었다고 판단한다
ETag
캐시용 데이터에 임의의 고유한 버전을 달아두는 것으로 데이터가 변경되면 이 이름을 바꾸어서 변경한다 캐시 제어로직을 서버에서 완전히 관리되는 것이다
( ex 애플리케이션 배포때마다 ETag를 바꾸자와 같이 규칙을 정해놓으면 캐시 제어로직을 서버에서 완전히 관리할 수 있다)
Cache - Control
한국에 있는 클라이트가 미국에 있는 원 서버에 직접 요청을 하면 너무 오래걸린다는 단점이 있다
그래서 프록시 캐시 서버를 도입하였고 이런걸 cdn 서비스라한다
그러면 우리는 프록시 캐시 서버에 접근하기도 하는데 이는 응답 시간이 빠른 장점이 있다
클라이언트 캐시를 private 캐시라하고 프록시 캐시를 public 캐시라고 한다
아래와 같은 캐시 지시어가 존재한다
ex) 클라이언트 브라우저에서 데이터 요청을 하여 프록시 캐시에서 원서버로 가는 순간 네트워크가 단절되었다고 가정 그러면 오류가 뜨는 것보다 옛날 데이터라도 보내는 것이 낫다고 생각해서 200과 함께 과거 데이터를 보낼 수도 있음
하지만 must-revalidate는 원 서버에 접근할 수 없는 경우 항상 504 오류를 발생시킨다