프록시 캐시와 캐시 무효화
이 글은 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한 님의 강의를 듣고 정리한 내용입니다.
프록시 캐시
원 서버(진짜 서버) 직접 접근
origin 서버
만약 클라이언트에서 원 서버까지 500ms 가 걸린다고 가정을 한다면
프록시 캐시를 도입하여서 원서버에 직접 접근하는 것이 아닌 프록시 캐시 서버를 거쳐서 가는 방식으로 만들어버린다.
이렇게 되면 클라이언트는 그저 프록시 캐시 서버에 접근만 하면 되기 때문에 시간을 매우 빠르게 단축 시킬 수 있다.
보통 웹 브라우저를 private 캐시, 프록시 캐시 서버를 public 캐시라고 부른다.
Cache-Control
캐시 지시어(directives) - 기타
-
Cache-Control : public
- 응답이 public 캐시에 저장되어도 됨
-
Cache-Control : private
- 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야함 (기본값)
-
Cache-Control : s-maxage
- 프록시 캐시에만 적용되는 max-age
-
Age: 60 (HTTP 헤더)
- 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
캐시 무효화
Cache-Control (확실한 캐시 무효화 응답)
-
Cache-Control : no-cache, no-store, must-revalidate
-
Pragma: no-cache
진짜 이 페이지는 캐시를 하면 안된다고 하면 딱 이걸 넣어주면 된다.
no-cache, no-store, must-revalidate 이걸 넣고
Pragma: no-cache 까지 넣어주면 확실하게 캐시가 안된다.
-
Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용!!
-
Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨
- 메모리에서 사용하고 최대한 빨리 삭제
-
Cache-Control : must-revalidate
-
캐시 만료후 최초 조회시 원 서버에 검증해야함
-
원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gate Timeout)
-
must revalidate는 캐시 유효 시간이라면 캐시를 사용함
-
-
Pragma: no-cache
- HTTP 1.0 하위 호환
기본적으로 동작하는 흐름에 대해서는
-
웹 브라우저에서 캐시 서버에 해당 데이터에 대한 이미지가 변한것이 있냐고 요청을 보낸다.
-
프록시 캐시에서 원 서버에 요청을 보낸다.
-
원 서버에서 검증을 한다.
-
원 서버는 프록스 캐시로 응답을 보낸다. (Not Modified - > 변한 것이 없다)
-
프록시 캐시에서 웹 브라우저에게 응답을 한다 (Not Modified -> 변한 것이 없다)
-
브라우저 캐시 안의 데이터를 꺼내서 사용한다.
no-cache 경우
원 서버에 접근이 순간적으로 단절이 되어서 캐시 서버 설정에 따라 캐시 데이터를 반환할 수 있는데, 오류보다는 오래된 데이터라도 보여주게 끔 설정해서 웹 브라우저로 응답 데이터를 OK로 보낸다.
must-revalidate 경우
원 서버에 접근이 순간적으로 단절이 된다면 항상 오류가 발생해야 한다.
정말정말 중요한 데이터이므로 만약 돈과 관련된 결과라고 생각을 한다면 OK라고 보내면 안되기 때문에 응답을 오류로 보낸다.
