[HTTP] 캐시 무효화 & 전략

1. 캐시 무효화(Cache Busting)

"캐시 무효화"란 프록시 캐시 서버나 웹 브라우저 캐시 등 캐시 시스템에 저장된 캐시 데이터를 삭제하거나 삭제하는 행위를 말한다.

 

그렇다면 캐시 무효화 전략이 필요한 것일까요?
 
그 이유는 다음과 같다.

웹 브라우저가 GET 요청을 받으면 서버가 캐시 헤더를 제공하지 않더라도 최적화 목적을 위해 임의로 캐싱을 할 수 있다. 
그리고 리소스의 캐시 수명이 장기간으로 설정되어 오래된 정보가 사용자에게 표시될 수 있는 경우가 있다. 이러한 경우 업데이트된 데이터가 정확하게 반영되도록 캐시를 무효화해야 합니다.

기본적으로 브라우저는 일반적으로 캐시 제어 헤더에 지정된 캐시 유효 기간이 만료될 때까지 서버에서 유효성 검사를 요청하지 않기 때문에 문제가 발생합니다. 즉, 캐시된 콘텐츠가 오래된 경우에도 브라우저는 만료 시간에 도달할 때까지 해당 콘텐츠를 사용자에게 계속 제공합니다.

이 문제를 해결하기 위해 캐시 무효화 메커니즘이 사용된다. 캐시 무효화에는 만료 시간 전에 캐시된 리소스를 명시적으로 제거하거나 업데이트하여 사용자가 항상 서버에서 최신 데이터를 받을 수 있도록 보장하는 작업을 포함합니다.

요약하자면, 브라우저 캐싱은 성능을 최적화하지만 캐시 수명이 너무 길면 오래된 콘텐츠가 표시될 수 있습니다. 캐시 유효 기간이 아직 경과되지 않은 경우에도 사용자가 정확한 최신 정보를 받을 수 있도록 하려면 캐시 무효화가 필요합니다.

 

 

2. 캐시 무효화 헤더 종류

Cache-Control: no-cache, no-store, must-revalidate
Pragma도 있지만 요즘에는 사용하지 않으니 그냥 넘어가겠습니다!!!

 

2-1. 캐시 무효화 헤더 지시자 특징

• Cache-Control: no-store
  • 데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용해야 한다. 즉, 서버가 캐시된 데이터가 여전히 유효함을 나타내는 304 응답 가져온다는 말이다. 비록 네트워크 트래픽이 발생하지만 헤더 메시지만 교환되므로 네트워크 사용량이 최소화된다
• Cache-Control: no-cache
  • 주로 데이터에 민감한 정보가 포함되어 있는 경우에 사용하며, 저장하지 않고 최대한 빨리 삭제한다.
• Cache-Control: must-revalidate
  • 캐시 만료후 최초 조회시 원 서버에 검증
  • 만일 캐시 유효 시간 내에 있다면 캐시를 사용한다.
  • 원 서버에 접근 실패시 클라이언트, 프록시 서버, 원본 서버 간의 원활한 통신이 안되었다는 의미인 504(Gateway Timeout)상태코드를 발행 하는게 좋다

 

3. 캐시 무효화 전략

캐시 무효화 전략을 사용할때 보통 no-cache 와 must-revalidate 를 같이 설정하는 편이다.
2개를 같이 사용되는 이유는 no-cache에 의해 원 서버(Origin Server) 에 검증 요청을 보내는 도중 원 서버 와 프록시 캐시 서버(Proxy Cache Server) 의 연결이 불의의 사고로 끊어져 검증이 불가능할 경우, 504 Gateway Timeout 오류를 발생시키기 위해서이다. 왜냐하면 특이하게 몇몇 프록시 캐시 서버에서는 원 서버에 접근이 불가능해질 경우에 검증을 거치지 않고 이전의 캐시 데이터를 반환하기 때문이다.
예를들어 은행 관련 애플리케이션을 이용할 때 통장 잔고와 같은 중요 데이터의 경우, Origin Server 와의 연결이 불가능하다고 해서 변경 전의 데이터를 반환하면 큰일나므로, must-revalidate 를 활용해 일부로 5XX 오류를 발생시키는 전략을 세운다고 보면 된다. 돈 문제는 중요하니까!!! ㅎ

 

참조: 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한