프록시는 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 가리켜 프록시(Proxy)라고 하며, 그 중계 기능을 하는 서버를 프록시 서버라고 한다.
클라이언트, 혹은 반대로는 서버가 다른 네트워크에 간접적으로 접속 할 수 있기 때문에, 보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점이 있다.
한국에 있는 클라이언트(웹 브라우저)가 외국의 원 서버에 있는 특정 데이터가 필요한 상황이라고 가정해보자.
정보를 가져오기 위해서 많은 시간이 소요될 것이다.
이 때 외국의 원 서버와 한국 클라이언트의 중간에 위치한 한국의 캐시 서버가 있다면 프록시 캐시 서버에서 데이터를 가져올 수 있기 때문에 시간을 줄일 수 있다.
또한 여러 사람이 찾은 자료일수록 캐시에 이미 등록되어 있으면 빠른 속도로 데이터를 가져올 수 있다.
(국내에 프록시 캐시 서버가 있기 때문에 외국의 원 서버에서 데이터를 가져오는 것보다 빠르다.)
아마 많은 사람이 겪어봤을 것이다.
한국 사람이 많이 이용하는 외국의 사이트는 로딩이 빠른 반면, 이용하지 않는 사이트는 로딩이 느리다.
이러한 클라이언트에서 사용하고 저장하는 캐시를 private 캐시라 하며 프록시 캐시를 public이라고 한다.
Cache-Control: public
Cache-Control: private
Cache-Control: s-maxage
Age: 60 (HTTP 헤더)
클라이언트가 캐시를 적용하지 않아도 임의로 웹 브라우저가 캐시를 적용하는 경우, 특정 페이지에서 캐시가 되면 안되는 정보가 있다면 어떻게 무효화할까?
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: must-revalidate
캐시 만료후 최초 조회시 원 서버에 검증해야함
원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
Pragma: no-cache
예시를 들어서 no-cache와 must-revalidate의 차이점을 보여주겠다.
웹 브라우저가 캐시에서 데이터를 조회 후 검증을 위해 ETag와 no-cache를 요청에 담아 보낸다. 프록시 캐시는 이를 받고 원 서버에 요청을 하고, 원 서버는 검증을 한 후 문제가 없다면 304 Not Modified로 응답을 해준다.
그런데 만약 프록시 캐시가 no-cache를 받아서 원 서버에 요청을 보내려고 하는데 네트워크 단절로 원 서버에 접근이 불가하다면?
원 서버에 접근이 불가하다면 no-cache의 경우 '오류보다는 프록시 캐시가 보유한 오래된 데이터'라도 보여주자라고 판단해 오래된 데이터와 함께 200 OK 응답을 내려준다.
만약 돈과 관련된 문제에서 no-cache처럼 오래된 데이터를 보여준다면 분명 큰 장애가 될 것이다. 이럴때는 must-revalidate를 사용해야한다.
must-revalidate의 경우 원 서버에 접근이 불가하다면 항상 오류가 발생한다. 프록시 캐시는 웹 브라우저에게 504 Gateway Timeout 응답을 내려준다.
중요한 정보를 사용할 경우 예전 데이터를 보여준다면 큰 문제가 발생하기 때문에 이러한 경우는 must-revaildate를 적용한다.
출처
모든 개발자를 위한 HTTP 웹 기본 강의
해당 게시물의 사진 자료는 위 강의의 자료를 사용하였습니다.
프록시 캐시(Proxy Cache)에 대해 알아보자