이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
만약에, 캐시가 만료되었어도, 클라이언트가 가진 데이터와 서버가 가진 데이터가 똑같다면, 구지 서버에서 데이터를 가져오지 않고, 클라이언트의 데이터를 활용할 수 있는 방법은 없을까??
캐시 시간 초과
-
서버에서 별 이미지를 노란색에서 연두색으로 바꿔버림
=> 이건 데이터가 바뀐 상황이니까 데이터를 새로 받아오는게 맞다. -
데이터가 기존과 똑같다면??
=> 용량이 1.1M나 되는데 이거를 처음부터 다시 다운 받을 필요가 있을까??
그래서, 이것을 해결하기 위해서 나온 개념이 "검증 헤더"와 "조건부 요청"이다.
만료된 캐시의 데이터를 재사용하기 위해서는, 캐시가 가진 데이터와 서버 측의 데이터가 여전히 동일하다는 것을 알아야한다.
그래서, 클라이언트가 가지고 있는 만료된 캐시의 데이터와 서버의 데이터가 같다는 사실을 확인하기 위해, "검증 헤더"를 사용한다.
검증 헤더와 조건부 요청
다시 맨 처음부터 요청한다고 가정하자!!
서버에서 데이터를 보내줄 때, Last-Modified라는 항목을 추가할 수 있다.
Last-Modified : 해당 데이터의 최종 수정일
그러면, 웹 브라우저는 응답 결과를 당연히 캐시 저장소에 저장한다.
그리고 60초가 유효하다는 것과 해당 "데이터 최종 수정일" 역시 적어둔다.
60초가 지난 후에,(캐시가 만료된 후에) 별 이미지를 꺼내려한다면, 캐시가 만료됐기 때문에, 다시 서버에 요청을 보낸다.
그런데, 캐시에 Last-Modified 가 명시되있다면, if-modified-since라는 HTTP 요청 헤더를 붙인다.
요청을 받은 서버는 if-modified-since를 보고, 데이터가 수정되지 않았다는 것을 알았다.
서버는 304 상태 코드와 함께 응답 메세지를 보내주는데, HTTP body가 없다!!
총 1.1M 중 1.0M를 차지하는 body를 보내지 않는다. 왜냐면, 수정된 것이 없기 때문에...
이렇게 하면, 네트워크 부하가 확 줄어든다.
응답 메시지를 받은 웹 브라우저는 304 상태 코드를 확인하고, "캐시가 안 바뀌었으니까 재사용해도 된다"고 인식한다.
그래서, cache-control값 갱신하고, 캐시를 다시 세팅한다.
그리고, 캐시에서 데이터를 꺼내와서 사용한다.
지금까지 예시는 검증 헤더와 조건부 요청을 같이 사용한 거다.
검증 헤더는 Last-Modified 이고, 요청 메시지에서 첨부해준 if-modified-since를 조건부 요청이라고 한다. if절이 사용됐으니까, 왜 "조건부 요청"인지는 쉽게 이해된다.
결과적으로, 네트워크 다운로드가 발생하기는 한다.
요청도 발생하고, 응답도 발생하기는 하지만, 예시의 경우는 0.1M (헤더의 용량)만 받으면 되서, 굉장히 실용적인 해결책이다.
브라우저에서 확인해보는 검증 헤더와 조건부 요청
실제로, 웹 브라우저들은 이 메커니즘을 다 실행하고 있다.
상태 코드의 색깔이 진한 게 있고, 연한 게 있는 것을 볼 수 있다.
색깔이 연한 것은 "캐시"에서 불러온 것이다.
색깔이 연한 파일 하나를 더블 클릭해서 "새로고침"을 한 뒤, 확인해보면,
요청 헤더에서는 if-modified-since라는 조건부 요청을 보내고,
바뀌지 않았다는 의미의 "304 상태 코드"로 돌아오는 것을 확인할 수 있다.
메타 정보(메타 데이터)??
메타데이터(Metadata)는 데이터에 대한 데이터이다.
Karen Coyle에 의하면 "어떤 목적을 가지고 만들어진 데이터(Constructed data with a purpose)" 라고 정의한다.
대량의 정보 가운데 찾고 있는 정보를 효율적으로 찾아내서 이용하기 위해 일정한 규칙에 따라 콘텐츠에 대하여 부여되는 데이터이다. 어떤 데이터 즉 구조화된 정보를 분석, 분류하고 부가적 정보를 추가하기 위해 그 데이터 뒤에 함께 따라가는 정보를 말한다.
자료 출처 : 네이버 백과사전
