HTTP 의 Cache 에 대한 이해

www.youtube.com/watch?v=fczpUczepS4&list=PLuHgQVnccGMAM6VAWEKtaUnvzePCxnUVo

이 글은 위의 영상을 바탕으로 작성되었습니다

 

HTTP 에서의 캐시 제어는 주로 http 메세지 헤더의 Cache-Control 속성을 통해서 이루어집니다. 이 속성값을 "no-store" 로 해주면 브라우저는 이를 읽고 해당 데이터(파일)을 절대 캐시하지 않습니다.

 

 

maxAge 를 통해 캐시 허용

캐시를 무한정 허용하면 웹 서버 내에 그 파일 내용의 업데이트가 이루어졌다고 하더라도 웹 브라우저는 그 컨텐츠를 다시 받지를 않을 것이기 때문에 절대 좋다고만 볼 수 없습니다. 따라서 캐시가 '언제까지 허용될지를 결정하기 위해' Cache-Contol 속성에 maxAge 값을 지정해주는 식으로 주로 캐시를 컨트롤 하게 됩니다.

 

Cache-Control: "max-age=3153600" # 이때 숫자는 '초' 단위입니다. # 만일 maxAge 값이 0 이라는 이는 값을 'no-cache'로 하는 것과 같습니다. # 만일 Cache-Control 값을 'private'으로 지정하면 캐시가 중간 지점에서 절대 이루어지지 않고 # 반드시 사용자 브라우저 상에만 이루어집니다. # Public 으로 해놓는다면 사용자의 브라우저가 아니더라도 중간 지점의 어디서든 # 캐시가 이루어질 수 있습니다.

 

maxAge 의 시간 값을 너무 짧게 해줬다고 해서 그 시간이 지나면 이용자가 그 파일을 반드시 아예 새로 받게 되는 것은 또 아닙니다. 브라우저는 처음에 특정 데이터(파일)을 받을 때, 그 데이터가 마지막으로 수정된 시간 정보 또한 같이 받습니다. maxAge 에 할당된 시간이 다 지나서 웹 브라우저가 서버에 해당 데이터를 재요청 할 때, 재요청을 받은 웹 서버는 헤더에 포함되어 있는 웹 브라우저가 재요청하는 데이터의 마지막 수정시간과 웹 서버가 가지고 있는 그 파일의 마지막 수정시간을 비교합니다. 만일 업데이트가 이루어졌다면 마지막 수정시간이 다를 것이고, 그렇지 않다면 수정시간이 같을 것입니다. 웹 서버는 이를 판단한 후 마지막 수정시간이 다르다면 그 때 브라우저에게 파일을 다시 전송합니다. 만일 수정시간이 같다면 오직 response 헤더만 보냅니다. 이 헤더의 응답코드는 304 이고 이는 재요청하는 그 데이터가 딱히 수정된 내용이 없어서 다시 보내주지 않았다는 말입니다.

 

 

ETag

하지만 '마지막 수정 시간'은 정확하지 않을 수도 있습니다. 실제로 업데이트가 이루어졌어도 컴퓨터 자체의 문제 때문에 아주 조그마한 수정 시간 기록의 차이가 있을 수 있습니다. 이로 인해 발생할 수 있는 문제를 해결하기 위해 각 헤더에는 ETag 라는 속성이 하나 더 있습니다(정확히는 request 헤더에는 If-None-Match 에 ETag 값이 담기고 If-Modified-Since 에 Last-Modified 값이 담깁니다. response 헤더에는 ETag 속성 안에 ETag 값이 담기고 Last-Modified 속성 안에 Last-Modified 속성 값이 담깁니다). 웹 서버는 맨 처음 브라우저가 데이터를 요청할 때, Last-Modified 값과 함께 ETag 값을 함께 보냅니다. ETag 값은 웹 서버 내의 데이터(파일)이 수정될 때마다 갱신됩니다.

 

만일 마지막 수정 시간이 같다면 웹 서버는 request 헤더 안에 있는 If-None-Match 속성의 ETag 값을 보게 됩니다. 만일 수정 시간이 같더라도 ETag 값이 다르다면 결국 업데이트가 있었다는 의미이기 때문에 웹 서버는 해당 데이터를 재전송합니다. 정리하자면, 파일의 업데이트 유무를 판단하기 위해 HTTP 프로토콜에서는 ETag 와 Last-Modified 값을 활용하는데, 만일 둘 중 하나라도 다르다면 데이터의 재전송이 일어나게 되는 것입니다.

 

만일 캐시 정책을 어떻게 해야하는지가 헷갈린다면 다음의 결정 트리를 참고해볼 수 있습니다. 이 보다 더 상세한, 더 진보된 캐싱을 위해서 우리는 PWA 를 활용해볼 수 있습니다.