웹 캐시
웹 캐시 또는 HTTP 캐시 라고 하는데,
이 캐시는 서버와 불필요한 네트워크 통신을 줄이기 위해서 임시 저장한
정보들을 바로 뿌려주는 기술이다.
웹 캐시가 자신의 저장소 내에 요청된 리소스를 가지고 있다면, 그 요청을 가로채
원래라면 서버에서 리소스를 가져오겠지만, 리소스의 복사본(프록시) 를 통해 데이터를 가져오게 된다.
성능이 향상되는건 말할 것도 없지만, 이 리소스가 영원히 변하지 않는 것은 아니기 때문에
가지고 있던 값이 변하기 전까지만 캐시로 유지하고 더 이상은 캐싱을 하지 않아야 한다.
사설 브라우저 캐시
이 캐시는 한 사용자 전용의 캐시이다.
예로, 크롬 브라우저를 켰을때 브라우저 자체는 이 사용자만의 캐시를 고유하게 갖고 있다.
이게 사용자마다의 개개인의 캐시로 기록이 되어있기 때문에 사설 브라우저 캐시라고 하는 것이다.
공유 프록시 캐시
내가 이해한 바로는 어떤 API를 호출하는 작업이 있을 때
자기 자신뿐 아니라, 같은 API를 누구든 호출할 때 재사용되기 때문에 그 재사용되는 응답을 저장하는 캐시이다.
유효성
사실상 캐시에 저장된다고 한다면 그 리소스가 변경, 만료기간이 없다고 할 때,
영원히 캐시로만 서비스가 될 수도 있다.
그렇지만 캐시의 공간은 유효하기 때문에 주기적으로 제거가 된다.
동작과정
Cache-Control 헤더의 max-age값은 만료 시간을 의미한다.
1번 그림
1번그림은 캐시가 없을 때, /doc의 url로 GET 요청을 하면
캐시가 없는 상태이므로, 서버에서 리소스를 조회한다.
그 이후에 저장된 캐시가 없었기 때문에, 이 리소스를 바탕으로 캐시를 하나 생성하고
클라이언트에 Response값을 내려준다.
2번 그림
1번 그림에서 10초가 지난뒤에 다시 /doc로 GET요청을 보내본다.
근데 설정한 만료시간은 100초 이므로 10초는 만료시간 내에 존재한다.
그래서 서버로 리소스 찾는 명령을 보내지않고 캐시에 저장된 데이터를 클라이언트에게 돌려준다.
3번 그림
설정한 만료 시간 (100초) 를 지난 후에 같은 방식으로 요청을 보낸다.
이번에는 만료 시간이 지났기 때문에 캐시는 한번 검증을 해야한다.
변경된 값이 있는지를 체크해야 한다
그다음에 변경 사항이 없다면 304 상태 코드로 수정 사항이 없다는 것을 알리면서
시간을 갱신한 후 클라이언트로 돌려주는 과정이 되겠다.
캐시 검증
위 3번 그림에서 봤듯, 캐시의 만료시간이 지나면 문서를 다시 서버에 요청하여 가져와야 하는데
두가지 옵션이 있다.
ETags
ETags는 캐시 데이터와 함께 헤더에 고유 식별자를 붙여서 내려보내 주게 된다.
HTTP/1.1 200 OK
Cache-Control: max-age:100
Age: 0
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"이런식으로 데이터가 내려가게 된다.
검증할 때에는 ETag 헤더값으로 데이터를 식별하고, 만료되어 새로운 캐시를 저장할 때에는
마찬가지로 ETag의 값도 새로 갱신하고 내려주게 된다.
아래는 깃허브에서 스프링 캐시에 대한 학습을 진행해보았다.
