캐싱
하드웨어에서 캐시메모리는 메인메모리와 CPU간의 속도 차이로 인한 병목을 줄이기 위해 메인 메모리에서 자주 사용되는 데이터를 저장해두어 CPU가 바로바로 사용할 수 있도록 도와줍니다. HTTP Caching도 이와 비슷한 느낌으로 클라이언트 사이드에서 리소스의 복사본을 저장해두고 요청 시에 캐시에 있는 리소스를 제공하는 기술입니다.
HTTP Caching
HTTP Caching의 목적은 서버로부터 리소스를 다시 다운받는 오버헤드를 줄이는 것입니다. 요청을 할 때마다 서버에서 리소스를 다시 다운받는다는 것은 엄청난 비용적 손실이 있습니다. 네트워크 사용량 자체도 많아질 뿐더러, 방대한 리소스를 계속 받아와야 하기 때문에 로딩시간도 길어집니다.
첫번째 요청에서 브라우저 캐시에 리소스를 저장해두고, 이후에 요청을 다시 할 때는 브라우저 캐시에 리소스가 있는지 확인하여 있다면 그것을 불러옵니다.
만료의 시기
캐시 리소스를 무한정 저장해둘 수는 없습니다. 점점 브라우저에 쌓인다면 이 역시 성능저하의 원인이 되기 때문입니다.
캐시의 만료를 지정하는 방법은 2가지가 있습니다.
1. Expires
ex) Expires: Tue, 28 Feb 2022 22:22:22 GMT
만료시기를 지정해줍니다.
2. Cache-Control: max-age=?
ex) Cache-Control: max-age=31536000
캐시가 살아있는 시간을 지정해줍니다.
1번은 Time, 2번은 Duration이라고 생각하면 쉽습니다. 대부분의 경우 캐시 만료를 지정하는데 max-age방식을 사용합니다.
그렇다면, 캐시가 만료된다면 무조건적으로 서버에서 리소스를 다시 받아와야할까요? 물론 다시 받아올수도 있겠지만 서버의 리소스가 변경되지 않았다면 굳이 받아올 필요가 없었음에도 다시 받아온다는 것은 오버헤드입니다.
검증헤더 - Last-Modified
이를 해결하기 위한 한가지 방법으로 마지막 수정일자를 이용합니다.
-
처음 서버에서 캐시 데이터를 받아오면, 서버가 보낸 응답 헤더에는
Last-Modified헤더가 있습니다. -
캐시가 만료되면 클라이언트는
if-modified-since헤더를 이용하여 Last-Modified이후로 리소스가 변경되었는지 확인합니다.
3-1. 변경되지 않았다면 서버는 304 Not Modified 응답을 보냅니다. 이때 응답은 헤더만 보내고 리소스가 담겨있어야 할 메세지 Body부분은 빈 채로 보내는데, 이를 통해 응답의 용량을 줄이는 것입니다.
3-2. 변경되었다면 서버는 200 OK 응답을 보냅니다. 이때는 처음부터 리소스를 다시 보냅니다.
검증헤더 - ETag
위의 방법은 중간에 수정되었다가 같이 리소스로 되돌려진 경우를 구분할 수 없습니다. 따라서 다른 방식으로 ETag 헤더를 사용할 수 있습니다.
ETag는 버전관리라고 생각하시면 편합니다. 사용자가 원하는 대로 고유한 버전 이름을 정할 수 있습니다.
- 캐시가 만료되면 클라이언트는
if-None-Match헤더를 이용하여 만료된 캐시의 ETag를 서버에 알립니다.
2-1. 변경되지 않았다면 서버는 304 Not Modified 응답을 보냅니다. 이때 응답은 헤더만 보내고 리소스가 담겨있어야 할 메세지 Body부분은 빈 채로 보내는데, 이를 통해 응답의 용량을 줄이는 것입니다.
캐시 제어 헤더
Cache-Control: no-cache
리소스를 origin 서버에서 항상 검증해서 사용하라는 헤더입니다. origin 서버에 접근이 불가하면 프록시 서버에 저장되어있는 오래된 리소스가 반환될 수도 있습니다. 이름과 다르게 리소스를 캐싱할 수는 있습니다.
Cache-Control: no-store
리소스를 캐시에 절대 저장하지 말라는 헤더입니다.
Cache-Control: must-revalidate
캐시 만료 후 최초 조회시에는 origin 서버에서 검증해야 한다는 헤더입니다. origin 서버에 접근할 수 없으면 504 Gateway Timeout 에러를 반환합니다.
