기존에 캐싱은 이미지나 정적파일 http요청에 만 적용되는 건 줄 알았는데
이외 데이터(json..) http 요청에도 캐싱이 적용되는가에 의문을 가진적이 있어 이를 해결해보고자 글을 작성해보려한다.
캐싱
주어진 리소스의 복사본을 저장하고 있다가 요청 시에 그것을 제공하는 기술로
웹 캐시가 자신의 저장소 내에 요청된 리소스를 가지고 있다면, 요청을 가로채 원래의 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환하는 기법이다.
캐싱을 할 때 중요한 점은, 모든 리소스가 영원히 변하지 않는 것은 아니므로 리소스가 변하기 전까지만 캐싱하고 변한 이후에는 더이상 캐싱하지 않는 것이다.
캐싱 제어
cache-control 헤더를 이용해 캐싱을 제어할 수 있다.
no-store: 클라이언트 요청, 서버 응답 항상 새로운 것! 매번 요청되고 리소스가 다운로드 된다.
no-cache: 캐싱하지만 유효성 확인을 위해 서버로 요청이간다.
유효성 (Freshness)
유효(fresh): 캐시 만료 시간 전의 리소스 상태실효(stale): 캐시 만료 후의 리소스 상태캐시가 실효된 리소스에 대한 요청을 받는 경우 리소스가 유효한지 아닌지 (변경된 내용이 없는지)를 확인하기 위해
If-None-Match와 함께 요청을 전달하고 서버는 응답으로 304 Not Modified를 보낸다.
그러고는 age를 초기화시키고 리소스를 반환한다.
✅ Cache-control 헤더에 max-age(만료기간) 설정해서 보낼 경우
→ 만료기간 전 까지는 사용자가 요청을 하면 캐싱된 리소스가 응답된다.
→ 만료기간이 다되면 서버에 유효성 검증을 요청하는데,
동일한 요청에 대해 변경된 데이터가 없으면 304(Not modified, 변경되지 않음) 응답과 함께 age가 리셋되며 원래 캐싱된 리소스가 반환되고
실효(stale)하다면 변경된 데이터로 응답한다.
따라서 - !
max-age를 설정한 경우에 실제 서버와 통신하는 시점은 최초로 요청을 보낼 때와 만료기간이 다되어 유효성을 검증할 때이다.
🧸 여기서부턴 잡담 - ! 🧸
검색 기능을 구현할 때, 동일한 검색어에 대한 요청은 불필요한 요청일 수 있다.
따라서 캐싱을 활용하면 더 효율적일 것이다.
나는 cache-control을 설정하지 않았을 때와 만료기한을 설정했을 때를 비교해보았다.
우선 cache-control을 설정하지 않았을 때는 no-cache를 설정했을 때와 동일한 통신흐름을 보인다.
즉 위에서 언급했던 것과 같이 캐싱은 하지만, 유효성을 검증하기 위해 서버에 요청을 하고 바뀐게 없다면 리소스를 보내지 않는다.
만료기한을 설정했을 때는 조금 다르다.
max-age를 300000로 설정했다 가정하면, 초기 요청후 300000초 동안은 유효성 검증없이 디스크 캐시에서 가져오게 된다. 이 경우에는 서버의 데이터에 변경이 일어났다고해도 클라이언트에서는 예전 데이터를 읽을 것이다.
개발할 시스템을 잘 파악해서 초기 cache-control을 따라갈 것인지 아니면
직접 설정을 할 것인지 잘 선택해서 사용하면 될 것 같다.
유효성 검증을 중요하게 여긴다면 no-cache로 설정하는 게 좋은 것 같다.
(실제 네이버 사이트의 경우 동일한 검색어에 대해 추가적인 통신이 일어나지 않음을 확인했다. 내부적으로 어떻게 처리됐는지가 궁금하다....🤔)
📔 참조문서 HTTP caching
