수정일: 2025. 3. 16.
HTTP Cache-Control에 대한 분석
HTTP의 헤더 중 하나입니다. 서버는 유저의 요청에 의해 서버가 가지고 있는 자원을 적절히 가져와 반환합니다.
이 때, 서버는 가져온 자원들 중 한동안은 변경되지 않을 자원들을 미리 알 수 있습니다. 예를 들어 올해의 연도를 반환한다고 하면, 1월 1일에 유저에게 돌려줄 데이터는 적어도 364일간은 변경될 일이 없을 것입니다.
이 때, HTTP 헤더의 Cache-Control을 이와 같이 설정해 보내줍니다. ``` Cache-Control: public, max-age=31536000 # 365일 = 60 * 60 * 24 * 365 ```
당장 본 사이트에도 Cache-Control이 사용되고 있습니다. 제가 제공하고 있는 사이트의 자원들 중 css, js, html등은 http 통신을 통해 서버에서 브라우저로 전송되어집니다.
서버로 부터 받은 http Response Headers를 확인해보면
``` access-control-allow-credentials: true access-control-allow-headers: Content-Type, Authorization access-control-allow-methods: GET, POST, PUT, DELETE
access-control-allow-origin: * cache-control: public, max-age=3600 # <= 여기!
```
서버는 3600초만큼 브라우저에 직접 캐싱을 요청하게 됩니다. 브라우저는 이를 적절히 캐시하게 됩니다.
Cache 요청은 서버가 브라우저에게 보내는 HTTP 응답의 header에 담아 보냅니다. 브라우저는 그 헤더를 읽고 유저의 디바이스에 적절히 저장을 하게 됩니다.
이 때, 적절히는 유저의 disk 혹은 memory에 저장됩니다.
disk에 저장되는 것은 보통 저장 기간이 아주 긴 경우, 혹은 사이즈가 아주 커서 메모리를 많이 차지 하는 경우입니다.
memory는 위의 disk와 반대로, 저장 기간이 매우 짧거나 아주 가벼운 파일들인 경우입니다.
이는 브라우저가 디바이스의 스펙에 따라 알아서 선택하므로 어디에 저장할지는 강제할 수 없습니다.
PWA를 하다보면 Web의 Service Worker를 사용해 브라우저의 요청을 프록시(Proxy)하여 응답을 저장하거나, 저장된 응답을 반환하는데 사용되는 것이 Cache Storage입니다.
이는 개발자가 직접 자원을 다루게 됩니다. 이는 브라우저의 IndexedDB에 바이너리 형태로 저장됩니다.
즉 Cache Storage와 Cache Control은 저장 위치부터 전혀 다른 별개의 API입니다.