Http 캐시 🚀

Http에서 캐시가 왜 있을까?

웹이 성장하면서 웹 서버로부터 전송되는 정보의 크기가 급격히 커지게 된다. 데이터의 전송 속도를 높이기 위해서 고민하고 고민하다 나온 결과물이 Http 캐시 기능이다.

이미 다운로드 받은 자원을 다시 웹 서버로부터 다운로드를 받아야 할까?

한번 다운로드 받은 파일을 컴퓨터에 저장했다가 같은 요청을 할 때 웹 서버로부터 다시 다운로드 받지 않고 저장해놓은 자원을 사용한다면 네트워크를 통하지 않고 자원을 사용할 수 있어 사용자는 네트워크 지연으로 발생하는 속도 저하를 겪지 않아도 된다.

*자원: html, javascript, css, jpg, pdf, docs 등

---

그렇다면 캐시가 만사 OK인가?

웹 브라우저가 캐시를 사용하고 있을 때 웹 서버에서 웹 브라우저가 캐시한 자원을 변경하면 어떻게 될까?

아마 웹 브라우저는 서버에서 변경된 것을 인지하지 못하고 구 버전의 자원을 계속 사용하고 있을 것이다.🤦‍♂️ 이런 소리 없는 아우성 같은 상황을 예방하기 위해 Http의 캐시 관련 헤더와 캐시를 최신 상태로 유지하는 방법에는 어떤 것들이 있을지 알아보자!!!

---

Http Response Header: Last-Modified

웹 서버가 웹 브라우저에게 자원을 전송할 때 해당 자원이 언제 마지막으로 수정되었는지에 대한 날짜 정보를 Last-Modified에 담아서 보낸다. 웹 브라우저는 캐시를 저장할 때 Last-Modfied 정보도 같이 저장하게 된다.

Http Request Header: If-Modified-Since

웹 브라우저가 웹 서버에게 캐시한 자원이 유효한지 물어볼 때 보내는 값으로, 웹 서버로 부터 자원을 다운로드 받을 때 Response header 정보로 받은 Last-Modified 값을 If-Modified-Since 담아 보낸다. 웹 서버는 전달받은 If-Modified-Since 값과 서버 자원의 Last-Modified와 비교한다.

• 변경 됐다면, 변경된 자원을 웹 브라우저에게 전송 (Status Code: 200)
• 변경되지 않았다면, Response header만 전송 (Status Code: 304 Not Modified), 웹 브라우저는 캐시한 자원을 재사용하고 max-age를 재설정한다.

---

Http Response Header: ETag

Response header인 Last-Modified의 값만 가지고 캐시 자원의 유효성을 판단하기에는 부정확할 수 있다. 정확한 캐시 자원의 유효성을 검사하기 위해 ETag 값을 활용한다. 웹 브라우저는 캐시 자원을 저장할 때 ETag 값도 같이 저장한다.

*ETag: 자원을 식별하는 고유한 문자열 정도로 해석함.

Http Request Header: If-None-Match

웹 브라우저가 웹 서버에게 캐시한 자원이 유효한지 물어볼 때 보내는 값으로, 웹 서버로 부터 자원을 다운로드 받을 때 Response header 정보로 받은 ETag 값을 If-None-Match에 담아 보낸다. 웹 서버는 Request 받은 If-None-Match 값과 서버 자원의 ETag값과 비교한다.

• 변경 됐다면, 변경된 자원을 웹 브라우저에게 전송 (Status Code: 200)
• 변경되지 않았다면, Response header만 전송 (Status Code: 304 Not Modified), 웹 브라우저는 캐시한 자원을 재사용하고 max-age를 재설정한다.

---

Http Header: Cache-Control

프로그래머가 캐시를 제어하기 위해 Http header에는 Cache-Control이라는 속성이 있다. 한번 알아보자!!!

no-store

웹 서버가 자원을 웹 브라우저에 전송할 때 Http response header의 Cache-Control을 no-store로 설정하면, 웹 브라우저는 무슨 일이 있어도 해당 자원을 캐시 하지 않는다. 항상 최신화된 자원을 서버로부터 받아 올 수 있는 장점이 있지만, 매번 다운로드 해야 하는 단점이 있다.

no-cache

이름이 no-cache라고 해서 캐시를 저장하지 않는 게 아니다. 주의하자!!!
웹 서버가 자원을 웹 브라우저에 전송할 때 Cache-Control을 no-cache로 설정하면, 웹 브라우저는 해당 자원을 캐시한 후 같은 요청을 할 때마다 웹 서버에게 캐시가 유효한지 항상 확인한다.

이는 max-age: 0으로 설정한 것과 같으므로, max-age가 만료되었을 때 동작은 바로 아래 max-age에서 확인하자.

max-age

max-age는 초 단위 입력을 통해 캐시의 만료 시간 지정할 수 있다. Http response header의 max-age: 3600으로 설정되어 있으면 웹 브라우저는 웹 서버로부터 자원을 받아 캐시한 이후 같은 요청을 하게 되면 1시간 동안 컴퓨터에 저장되어있는 캐시 자원을 활용한다. 이 방식은 자원을 재사용해 사용자는 속도가 빠른 서비스를 받을 수 있지만, 웹 서버 자원의 변경사항을 웹 브라우저가 알아채지 못한다는 단점이 있다.

만약 1시간이 지난 후 웹 브라우저가 같은 요청을 하게 되면 어떻게 동작할까?

만료가 됐다고 캐시한 자원을 버리지 않는다. 만료 시간이 지난 캐시 자원을 다시 사용해도 되는지 웹 서버에게 물어보는데, 이때 Request header의 if-Modified-Since, If-None-Match을 포함한 header 정보만 전송한다.

웹 서버는 Request header의 if-Modified-Since, If-None-Match의 값을 비교하여 유효성 검사를 한다. 해당 부분의 유효성 검사는 이미 설명했으니 생략하겠다.

max-age 값을 잘 지정한다면, 네트워크 트래픽 감소와 더불어 리소스를 신선도 있게 웹 브라우저에게 제공할 수 있다.

---

배운점 & 더 알아보고 싶은 것들

업무를 하면서 캐시를 다룬 적이 없었던 것 같다. 이런 부분은 반성해야겠다. 캐시를 활용하면 네트워크 트래픽을 효과적으로 줄일 수 있다. 하지만, 캐시를 섬세하게 컨트롤해야 한다는 것을 이번 포스팅을 통해 느낄 수 있었다.

Application Cache라는 것을 이용하면 네트워크가 끊겨 있어도 캐시 된 데이터를 이용해서 웹 애플리케이션이 동작하게 할 수 있다고 한다. 해당 부분도 추후 기회가 된다면 알아보고 싶다.

Caching Server에 대해서도 추가로 공부해야겠다. 중간에 Caching Server를 둘 경우 캐시가 어떻게 동작하는지도 알아보고 싶다. AWS에서 CDN이 있는데, 사용자와 서버가 지리적으로 거리가 멀 경우 중간에 CDN이 서버를 캐싱하고 사용자와 통신하는데 이런 것과 비슷한 걸까???