프록시 캐시
네트워크는 실제로 굉장히 멀리 떨어진 곳의 데이터를 받을 수 있게 해준다.
하지만 실제로 물리적인 거리가 멀어지면 전송속도가 상당히 떨어지기 때문에 이런 문제를 방지하고자 프록시 캐시 서버라는 것을 사용하게 되었다.
프록시 캐시 서버란 브라우저가 원서버에 바로 접근하는 것이 아니라 프록시 캐시 서버로 들어오게 하여 응답 속도를 높이는 것이다.
CDN Service라고도 부르는 이 방법은 원 서버에 있는 데이터를 첫번째 요청이 들어오면 프록시 캐시 서버에 저장해 두고 다음 요청이 들어올 때는 프록시 캐시 서버에서 응답을 보내게 하여 전송 속도를 높이는 방법이다.
이때 프록시 캐시 서버에 저장되는 것을 public 캐시라고 부르고 브라우저에 저장되는 것을 private 캐시라고 부른다.
쉽게 설명하면 공용으로 사용하는 캐시 서버라고 생각하면 좋을 것이다.
Cache-Control
당연히 이런 캐시 서버를 위한 헤더도 존재 하며 캐시 지시어는 다음과 같은 것들이 존재한다.
- Cache-Control: public
- 응답이 public 캐시에 저장되어도 됨
- Cache-Control: private
- 응답이 해당 사용자만은 위한 것임, private 캐시에 저장해야 함(기본값)
- Cache-Contorl: s-maxage
- 프록시 캐시에만 적용되는 max-age
- Age: 60 (HTTP 헤더)
- 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
캐시 무효화
캐시를 적용하지 않으면 캐시를 하지 않는 다고 생각할 수 있지만 실제로는 GET 요청 같은 경우 임의로 캐시를 하기도 한다.
따라서, Cache-Control에는 확실한 캐시 무효화를 할 수 있는 응답이 존재한다.
- Cache-Control: no-cache, no-store, must-revalidate
- Pragma: no-cache (HTTP 1.0 하위 호환)
위의 헤더를 모두 사용해야만 완벽하게 캐시가 사용되지 않으며 매우 중요한 정보라던지 항상 갱신이 되는 데이터들에는 위의 헤더를 모두 사용하여 캐시가 되지 않도록 만들어야만 정보가 보호된다.
각각의 대해 자세하게 살펴 보도록 하자.
- Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)
- Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
- Cache-Control: must-revalidate
- 캐시 만료후 최초 조회시 원 서버에 검증해야함
- 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
- Pragma: no-cache
- HTTP 1.0 하위 호환
그렇다면 no-cache와 must-revalidate는 똑같이 원서버에 검증하는 것인데 무엇이 다를까?
no-cache의 경우 캐시 서버 요청을 하면 프록시 캐시가 원 서버에 요청을 보내고 원 서버가 검증 후 응답을 보내면 브라우저가 확인하는 경우이다.
그런데 만약 순간적으로 네트워크가 단절이 되거나 원 서버에 접근 불가하게 되면 프록시 캐시 서버가 Error나 200 OK를 응답하게 된다.
반대로 Must-revalidate는 프록시 캐시와 원 서버가 통신이 안되는 경우 무조건 504 Gateway Timeout을 반환하게 된다.
이는 매우 중요한 차이 점으로, 특히 매우 중요한 돈과 관련된 결과인 경우 프록시 캐시에 있는 과거 데이터가 반환되면 큰 문제가 될 수 있기 때문에 반드시 현재 데이터가 중요한 경우 사용해야 한다.