캐시 시간 초과
- 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.
-
서버에서 기존 데이터를 변경함
-
서버에서 기존 데이터를 변경하지 않음
-
캐시 만료후에도 서버에서 데이터를 변경하지 않음
-
생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.
-
단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요
이러한 이유로 검증헤더라는것이 생긴다!!
처음상황으로 돌아가보자 캐시가 없이 완전 처음 star.jpg를 요청을 한다. 그럼 서버에서 알고있듯이 cache-control 을 추가하면 정해진 시간동안 캐시를 할수있고 추가로 Last-Modified를 넣어줄수 있다. 말 그대로 데이터가 마지막에 수정된 최정 수정일을 넣어준다. 실제 예시에는 UTC표기법으로 적혀있을것이다.
자 그렇게 서버가 응답을 내려주면 웹브라우저는 응답결과를 당연하게 유효한 시간을 넣은 캐시를 저장하는데 거기에 한개가 추가된다. 바로 그 데이터의 최종 수정일이다.
Last-Modified에서 받은 응답값을 기록한다는 뜻이다.
이 상황에서 설정된 시간이 지나면 http요청을 보낼텐데 그런데 cahce에 보니 Last-Modified값이 있다. 그러면 웹브라우저가 서버에 요청을 보낼때 if-modified-since 라는 요청 헤더를 붙인 다음 거기에 날짜를 붙여서 서버에 넘긴다.
이렇게 서버가 요청을 받았을때 if-modified-since값을 확인하고 서버는 star.jpg의 데이터 최종수정일을 확인하고 요청받은 데이터와 서버가 가지고있는 데이터의 최종수정일을 확인하고 판단을 한다. 날짜가 아직 유효하면 다음과 같은 상황이 나온다.
중요
수정이 안되었으면 HTTP응답을 만들때 304 Not Modified라고 보낸다. 그 다음에 cache-control 그대로 가고 Last-Modified를 다시 내보내는데 HTTP-Body가 없다는게 중요하다. 즉 헤더가 0.1M 바디부가 1.0M라고 가정을 하면 바디를 그냥 빼버리는것이다. 왜냐? 수정된게 없기때문에!!바디를 빼고 스타드라인과 헤더만 만들어서 응답을 보내버린다.
그렇게 응답을 받으면 바디가 빠지니 용량이 확줄어들고 그럼 네트워크 부하가 많이 줄어든다.
이렇게 서버의 응답을 웹브라우저가 받으면 304 Not Modified 를 확인하고 cache-control 값을 갱신하고 수정일도 갱신되었다면 Last-Modified도 갱신될것이다.
그리고 똑같이 cache에서 데이터를 불러와서 쓰게 되는것이다.
검증헤더와 조건부 요청을 같이 쓰는것이다.
검증헤더는 Last-Modified 검증할수 있는 값!
조건부요청은 if-modified-since 만약 이때로부터 바뀌엇으면 !
이 두가지를 조합해서 캐시가 진짜 서버에서 갱신이 되었는지를 맞춰볼수있는것이다.
이렇게 하면 쓸데없는 전송할수있는 용량을 확 줄일수있고 로컬에 들고 있는 캐시를 재사용할수 있다!!
검증 헤더와 조건부 요청 정리
- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified+헤더 메타 정보만 응답( 바디 X)
- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
- 클라이언트는 캐시에 저장되어 있는 데이터 재활용
- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
- 매우 실용적인 해결책
