TIL) Cache : 검증 헤더와 조건부 요청
브라우저는 서버의 응답결과를 캐시에 저장합니다
이후 재차 요청을 보내기 전에, 브라우저는 캐시의 유효기간이 초과되지 않았다면 네트워크를 거치지 않고 캐시를 통해 데이터를 조회합니다.
이때, 만약 캐시의 시간이 초과됐다면 브라우저는 똑같은 응답을 위한 요청을 재차 보내야만 합니다. 이때, 서버에서 데이터를 바꾼 것이 없다면 똑같은 데이터를 굳이 다시 다운로드 받아야 하나? 하는 의문이 생깁니다.
이때 검증 헤더와 조건부 요청을 이용합니다.
캐시 유효 시간이 초과된 이후, 서버에 다시 요청을 보낼 때, 다음의 두가지 경우의 수가 있습니다.
1. 서버에서 기존 데이터를 변경한 경우
2. 서버에서 기존 데이터를 변경하지 않은 경우
2번의 경우, 서버가 데이터를 변경하지 않았다면 기존 데이터를 재사용 할 수 있겠죠? 다만 이때 서버의 데이터와 클라이언트의 데이터가 같다는 것을 검증할 필요성이 있습니다.
이를 위해서 검증헤더를 사용합니다. 검증 헤더는 캐시 데이터와 서버의 데이터가 같은 지를 검증하는 역할을 합니다.
검증헤더에는 Last-Modified와 ETag가 있습니다.
Last-modified의 경우, 조건부 요청 헤더에 if-modified-since 를 사용합니다.
캐시의 데이터 최종 수정일과, 서버의 데이터 최종 수정일이 다를 경우, 200OK, 같을 경우 304 Not Modified(변한게 없다)의 응답이 옵니다. 304 Not Modified의 경우, 데이터가 바뀌지 않았으므로 HTTP BODY가 오지 않습니다.
ETag 는 if-Not-Match의 조건부 요청 헤더를 사용합니다.
ETag는 캐시용 데이터에 고유한 이름을 달아놓은 것입니다.
ETag는 서버 사이드에서 관리하는 것이기에, 캐시 제어 로직은 서버에서 온전히 가지고 있다고 볼 수 있습니다.
서버는 데이터가 변동됐을 시, 해시를 통해서 ETag를 재 생성합니다(해시 함수에 넣는 값이 동일하면 해싱의 결과도 동일하기에, 이를 통해 데이터의 변동을 표현할 수 있습니다). 사용자는 ETag를 통해서 데이터가 변경됐는지 아닌지를 알 수 있습니다.
개발자도구를 켜서, 네트워크 탭에서 트랜잭션을 확인할 수 있습니다
자세히 보면 204는 검은색이고, 200은 회색입니다.
회색인 경우는 기존 캐시에서 불러왔음을 뜻합니다.
해당 특정 트랜젝션을 클릭해보면, 캐시에서 불러왔음을 알 수 있는 문구가 있네요.
