HTTP Cache

 

https://opentutorials.org/module/3830

HTTP Cache

생활 코딩의 HTTP Cache 영상을 보고 쓴 글입니다.

 

Cache

데이터의 전송 속도를 높이기 위해 사용하는 기법, 이미 다운로드 받은 파일을 컴퓨터에 저장했다가 같은 주소로 접속했을때 캐시해둔 파일을 사용한다면 네트워크를 통하지 않아도 되므로 네트워크로 인한 지연 현상이 발생하지 않습니다.

 

하지만 캐시를 사용했을 때 발생할 수 있는 문제점은 웹사이트가 개편되었음에도 사용자가 과거의 파일을 볼 수 있다는 것입니다. 즉 캐시를 최신 상태로 유지해야하는 것이 중요합니다.

 

 

환경 설정

 

 

속도를 Slow 3G로 설정합니다.

 

 

아파치의 httpd.conf 파일을 변경해야합니다.

 

캐쉬 금지

아파치의 httpd.conf 에 다음 명령어를 입력합니다.

Header set Cache-Control "no-store" // 웹 브라우저에게 캐시를 저장하지 않도록 명령한다.

 

 

 

캐시가 저장되지 않아 같은 파일을 새롭게 로드하는 모습입니다.

 

캐시 이용

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

HTTP caching - HTTP | MDN

 

위 MDN 문서를 참고하면 다음과 같은 캐시 설정을 찾을 수 있습니다.

 

 

max-age의 31536000 초를 변환하면 1년이 나오고, 1년동안 캐시를 저장한다는 뜻이 됩니다.

설정을 아파치에 적용해보겠습니다.

 

 

브라우저의 네트워크탭을 살펴보면 초기 로딩과 리로드를 비교했을때 속도차이가 크게 나는 것을 볼 수 있습니다.

 

 

from disk cache , from memory cache 를 볼 수 있고 네트워크를 사용하지 않았음을 의미합니다.

 

이러한 캐시의 장점으로는 사용자는 빠르게 화면을 볼 수있으므로 UX 가 개선되고 , 서버에 요청하는 횟수가 줄어들기때문에 서버 통신 비용이 줄어듭니다.

 

하지만 신선도의 문제가 발생하게됩니다. 위 예시에서는 1년동안 캐시를 가지고 있기 때문에 웹사이트가 리뉴얼 되어도 새로운 화면을 볼 수 없게 됩니다.

 

이러한 문제점을 해결하기 위해서 다음과 같이 max-age 를 5초로 설정해보겠습니다.

 

 

 

5초마다 새로운 데이터를 받는 것을 확인할 수 있습니다. 그런데 데이터 크기를 살펴보면 초기 로드시 받는 데이터와 두번째 로드시 받는 데이터의 크기가 차이가 나는 것을 볼 수 있습니다. 왜 이런 차이가 나는 것일까요?

 

 

서버에서 응답 Last-Modified(마지막 수정 정보) 웹브라우저에게 알려주고 있습니다. 그럼 웹브라우저는 1.html 파일을 캐싱할때 이 파일의  Last-Modified 도 함께 저장하게 됩니다. 그후 캐싱 제한시간인 5초가 지나게 되면 웹브라우저는 Request Header에 다음 정보와 함께 서버에 요청을 보냅니다.

 

 

서버야 if-Modified-Since 시간 이후로 1.html 파일이 수정된 적이 있니? 와 같이 말이죠. 

만약 수정이 되었다면 1.html 파일을 전송해주고 그렇지 않다면 수정된 적이 없다는 말만해. 라고 합니다.

 

 

그럼 서버는 1.html 의 수정시간이 동일한 것을 확인한 후 304 상태코드와 함께 수정된 적이 없다고 웹 브라우저에게 알려줍니다.

이때 Contents 는 주고 받지 않고 Header 만 주고 받게 됩니다. (따라서 아주 작은 Byte 를 응답받게 된 것입니다.)

 

만약 1.html 이 수정이 되었다면 서버는 어떻게 응답할 까요?

 

 

200 상태코드 와 함께 Last-Modified 데이터도 보내게 됩니다.

max-age 를 몇초로 설정하냐에 따라서 캐시 성능을 조정할 수 있습니다.

 

Revalidate

만약 요청을 할때마다 마지막 수정시간을 비교하고 싶다면 다음과 같이 설정할 수 있습니다.

 

 

위 명령어는 다음 명령어와 동일합니다.

 

 

"no-store" 와 "no-cache" 가 혼동 될 수 있습니다. 정리하자면 no-store 는 캐시를 사용하지 않겠다 라는 의미이고 no-cache 는 캐시를 사용하되 항상 서버에 해당 캐시가 refresh 한지 체크하도록 하는 것입니다. 

 

 

ETag

ETag 파일 수정을 감지할 수 있는 또 다른 헤더입니다.

 

 

서버의 응답으로 온 ETag 는 위와 같습니다. 웹 브라우저는 해당 ETag 와 함께 1.html 파일을 캐시로 저장합니다. 

이제 다시 서버에 1.html 요청을 할때 If-None-Match 필드에 저장되어있던 ETag 와 함께 서버에 요청을 보냅니다.

 

 

그럼 웹서버는 If-None-Match의 값과 서버가 응답해야하는 1.html 의 Etag 값을 비교합니다. 

만약 서로 같다면

 

 

304 상태코드를 통해 수정되지 않았음을 알려줍니다.

만약 다르다면 200 상태코드와 함께 새로운 1.html 을 보내줄 겁니다.

 

 

Last-modified vs Etag 

ETag 는 값이 서버당 하나이기 때문에 여러 서버로 운영되는 서비스일 경우 값이 일치하지 않을 수도 있습니다. 블로그

따라서 하나를 선택해야한다면 Last-modified 가 더 낫지 않을까? 라는 생각을 했습니다.

 

 

캐싱 서버 

서비스의 웹 서버가 한국에 있는데 사용자는 미국에 있을 수 있습니다.

 

 

이때 미국 사용자의 가까운 곳에 캐싱 서버를 둡니다.

 

 

그리고 한국의 웹서버에 있는 데이터를 캐싱 서버에 캐싱을 해놓으면 미국에 있는 사용자들은 한국의 서버에 접속하는 것이 아닌 캐싱 서버에 접속하여 빠르게 데이터를 응답받을 수 있습니다.

 

 

캐시 알고리즘