웹브라우저의 캐시(Cache)

웹브라우저는 서버와 HTTP 프로토콜을 통해 리소스를 서버에게 요청하여 가져오고 이를 사용자에게 화면으로 보여주거나 제공한다.

이러한 통신 과정을 거치면서 클라이언트는 네트워크를 거치는 시간이 소비되며, 서버는 요청을 처리하는데 시간이 소비된다.

클라이언트가 이전에 받은 데이터와 똑같은 데이터를 서버에 재요청을 할 때 똑같은 통신 과정을 거치게 된다면 이 과정은 낭비라고 할 수 있다. 해결책으로 캐시의 개념을 웹브라우저에 그대로 적용한 HTTP에서 제공하는 헤더(Headres)인 Cache-Control 이 있다.

 

웹브라우저의 캐시 기본 동작

캐시가 없을 경우

캐시가 없을 경우 똑같은 이미지를 요청한다면, 서버에서는 동일한 이미지를 매번 1.1M 용량의 데이터로 응답해야 한다.

용량이 작은 리소스일 경우 큰 문제가 되지는 않겠지만 용량이 크면 클수록 통신 비용이 커지게 되고 로딩속도가 느려진다.

 

웹 브라우저에서 start.jpg라는 이미지를 요청하면, 서버에서 별과 관련된 그림을 보내줄 것이다.

HTTP 헤더에 관련된 부분의 용량이 0.1M 그리고 실제 해당 이미지를 표현하는 HTTP Body 부분이 1M정도 된다면, 총 1.1M의 네트워크를 차지하면서 웹 브라우저로 내려온다.

 

그러면 해당 이미지가 웹 브라우저에 표시된다.

 

캐시가 없을 경우, 두번 째 요청

똑같은 요청을 한번 더 했을 때, 서버에서는 또 똑같이 요청을 받아서 응답을 보내준다. 헤더와 바디 부분을 다시 만들어서 총 1.1M의 네트워크를 차지한다.

 

이후에 웹 브라우저에 다시 이미지를 그린다.

똑같은 요청을 2번 했고, 데이터도 변경이 없지만, 네트워크를 사용하여 데이터를 받아왔다.

 

캐시가 없을때

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

이러한 문제점을 보완하기 위해 "캐시"가 있다.

 

캐시 적용

일단 서버에서 캐시와 관련된 것을 세팅해야 한다.

이후에 서버에서 캐시를 적용하면,  cache-control(캐시가 유효한 시간)을 헤더에 넣어줄 수 있다.

웹 브라우저에는 쿠키와 마찬가지로 캐시 또한 캐시 저장소에 별도로 존재한다.

위의 캐시는 60초 동안 유효하다고 설정 후 응답 결과를 캐시에 저장한다.

 

캐시를 적용한 후에 두번째 요청할 때는 캐시부터 확인한다.

아직 캐시가 유효하다면, 캐시에서 star 이미지를 바로 가져온다. 네트워크를 탈 필요가 없게 된다.

 

캐시 적용 후

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

캐시 시간 초과

3번째 요청에서도 캐시 먼저 확인한다.

그런데, 캐시 유효기간이 만료되었다면, 다시 서버에 요청해야 한다.

웹 브라우저는 기존의 만료된 캐스를 지우고, 새로 받아온 캐시를 저장한다.

캐시가 만료되어서 불필요하게 1.1M의 네트워크를 다시 사용해야 했다.

 

캐시 시간 초과

• 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
• 이떄 다시 네트워크 다운로드가 발생한다.

Star 이미지는 전혀 바뀌지 않았지만, 네트워크 다운로드가 다시 발생한다.

만약 캐시가 만료되었어도, 클라이언트가 가진 데이터와 서버가 가진 데이터가 똑같다면, 굳이 서버에서 데이터를 가져오지 않고 클라이언트의 데이터를 활용할 수 있는 방법은 없을까?

 

 

캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.

1. 서버에서 기존 데이터를 변경함 - 데이터가 바뀐 상황이면 데이터를 새로 받아오는게 맞다.
2. 서버에서 기존 데이터를 변경하지 않음 - 데이터가 기존과 똑같다면, 1.1M 용량을 다시 다운 받을 필요가 없다.

데이터를 전송하는 대신에 저장해두었떤 캐시를 재사용할 수 있다. 

단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다.

 

이것을 해결하기 위해 나온 개념이 "검증 헤더"와 "조건부 요청" 이다.

만료된 캐시의 데이터를 재사용하기 위해서는, 캐시가 가진 데이터와 서버 측의 데이터가 여전히 동일하다는 것을 알아야 한다.

 

검증 헤더와 조건부 요청

다시 처음부터 요청한다고 했을 때, 

서버에서 데이터를 보내줄 때,  Last-Modified(해당 데이터의 최종 수정일)라는 항목을 추가할 수 있다.

그러면 웹 브라우저는 응답 결과를 캐시 저장소에 저장하고, 60초가 유효하다는 것과 해당 "데이터 최종 수정일" 역시 저장한다.

 

60초가 지난 후에(캐시가 만료된 후에) Star 이미지를 꺼내려 한다면, 캐시가 만료되었기 때문에 다시 서버에 요청을 보낸다.

그런데 만약 캐시에 Last-Modified 가 명시되어 있다면, if-modified-since 라는 HTTP 요청 헤더를 붙인다.

요청받은 서버는 if-modified-since를 보고, 데이터가 아직 수정되지 않았다는 것을 알 수 있다.

 

서버는 304 상태코드와 함께 응답 메시지를 보내주는데, HTTP Body가 없다.

수정된 것이 없기 때문에, 총 1.1M중 1.0M를 차지하는 body를 보내지 않는다. 이렇게 하면 네트워크 부하가 확 줄어든다.

응답 메시지를 받은 웹 브라우저는 304 상태 코드를 확인하고, "캐시가 안바뀌었으니까 재사용해도 된다"고 인식한다.

이후 cache-control값을 갱신하고, 캐시를 다시 세팅한다.

그리고, 캐시에서 데이터를 꺼내와 사용한다.

여기서 검증 헤더는 Last-Modifed 이고, 요청 메시지에서 첨부해준 if-modified-since를 조건부 요청이라고 한다.

 

정리

• 캐시 유효기간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답(body X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드

결과적으로, 네트워크 다운로드가 발생하지만, 위의 경우는 0.1M(헤더의 용량)만 받으면 되어서, 굉장이 실용적인 해결책이다.