프록시 캐시와 캐시 무효화
인프런 강의 中
김영한 강사님의 '모든 개발자를 위한 HTTP 웹 기본 지식' 내용을 정리했습니다.
잠이 쏟아지는 와중에도 공부를 해야할 때, 잠을 깨우는 저만의 꿀팁이 있습니다.
바로 입술을 살짝 깨물어서 피가 나오게 하는 것입니다.
너무 크게 깨물면 아프니까 살짝만 깨무는 것을 추천드립니다.
목차
- 캐시(Cache)란?
- 캐시 적용 예제
- 검증 헤더
- 프록시 캐시
- 캐시 무효화
1. 프록시 캐시
프록시 캐시는 클라이언트와 서버의 사이에 위치하는 서버에 데이터를 저장해 두었다가 재요청 시 원서버(소스 코드가 있는 origin 서버)에 재접속하지 않고 빠르게 응답해주는 캐시 시스템이다. CDN이 프록시 캐시 서버의 대표적인 예다.
프록시 캐시 서버는 위 이미지처럼 원서버와 클라이언트 서버 사이에 위치한다. 그래서 프록시 캐시 서버에 저장하고 사용하는 데이터 같은 경우에는 멀리 떨어져 있는 원 서버까지 네트워킹을 하지 않아도 되기에 더 빠르게 데이터를 응답 받을 수 있다. 프록시 캐시 서버의 이런 장점 덕분에 우리나라에서 멀리 떨어져 있는 유튜브를 빠르게 볼 수 있다.
보통 첫 번째 요청은 원서버에서 데이터를 가져오고 재요청 시 프록시 캐시 서버에서 데이터를 가져오지만(웹 페이지를 처음 호출 했을때 보다 두 번째 호출 했을때 더 빨리 접속할 수 있는 이유) 프록시 캐시 서버 설정을 통해 알아서 원서버의 데이터를 캐싱하고 클라이언트는 프록시 캐시 서버의 데이터만 사용하게 할 수도 있다.
프록시 캐시는 public, 브라우저 캐시는 private로 구분되며 다음과 같은 설정을 통해서 데이터의 캐싱을 설정할 수 있다.
- Cache-Control: public -> 응답이 public 캐시에 저장 가능
- Cache-Control: private -> 응답이 해당 사용자만을 위한 것임. private 캐시에 저장되어야만 함(기본값)
- Cache-Control: s-maxage -> 프록시 캐시에만 적용되는 max-age
- Age: 60 -> 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
2. 캐시 무효화
get 요청의 경우 자신이 따로 설정하지 않아도 브라우저에서 임의로 캐시를 해버리는 경우가 있다. 금융 자산 조회와 같은 내용은 당연히 캐싱이 되면 안되는 내용이기 때문에 이런 경우 캐시를 확실하게 무효화 시켜줄 필요가 있다. 다음과 같이 설정하자.
- Cache-Control: no-cache, no-store, must-revalidate
- Pragma: no-cache -> HTTP 1.0 하위 호환
위 설정을 다 넣어주면 캐시가 확실히 무효화가 된다. 참고로 브라우저에서 "캐시 비우기 및 강력 새로고침"을 한 후 데이터 요청 헤더를 확인해보면 Cache-Control: no-cache와 같은 내용을 포함해서 서버로 요청을 보내는 것을 확인할 수 있다. 위 설정 옵션 내용을 정리하면 아래와 같다.
(1). Cache-Control: no-cache
- 데이터는 캐시해도 되지만 항상 원서버에 검증하고 사용
- 원서버 접근 실패 시 과거 데이터와 함께 200 Ok를 response 하도록 설정 할 수 있음 -> must-revalidate 옵션과의 차이점
(2). Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
(3). Cache-Control: must-revalidate
- 캐시 만료 후 최초 조회 시 원서버에 검증해야함.
- 원서버 접근 실패 시 반드시 오류가 발생해야 함(504 Gateway Timeout) -> no-cache 옵션과의 차이점
- 캐시 유효 시간이라면 캐시를 사용함(원서버 접근 x) -> no-cache 옵션과의 차이점