캐시가 없을때
요청 GET /star.jpg 을 하면
서버에서 이를 보내준다.
캐시가 없을때, 만약 같은 요청이 온다면
같은 과정을 반복해서 다시 보내준다.
- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 받아야한다.
- 네트워크는 CPU나 다른 하드웨어 비용 대비 비싸고 브라우저 역시 느려진다
캐시가 생기면?
서버에서 cache-control을 설정한다.
max-age = 60
그 후, 이 유효기간동안 캐시저장소에 응답결과를 저장한다.
한번 더 요청이 들어오면, 캐시저장소에서 먼저 탐색을하고 있다면 저장결과를 사용한다.
캐시 시간 초과
만약 캐시 컨트롤 시간이 지나고 요청이 들어온다면
당연히 다시 요청을 하고 다시 결과를 보내준다. (60초 짜리)
하지만 이는 좀 아쉬운 부분이 있다.
이를 해결하기위해 다음의 기술을 사용한다
검증헤더와 조건부 요청
캐시 유효 시간 초과 후 서버에 다시 요청하면
1. 서버에서 데이터가 변한 경우
2. 변하지 않은 경우
두 가지가 있다.
캐시데어터가 바뀌지 않음을 검증하기
- 요청이 들어온다 GET /star.jpg
- 여기에 last modified 를 넣어줄 수 있다.
- 웹 브라우저는 결과를 캐시에 저장하는데 동시에 modified도 저장한다.
- 다시 요청한다. 이때, 캐시에 있는 if-modified-since + last modifed를 보낸다.
- 이를 서버에서 받고 데이터가 수정되지 않았다면 바디를 빼고 스타트라인 헤더만 보낸다.
- 다시 캐시에서 데이터를 불러다가 쓴다.
정리
캐시 유효 시간이 초과해도 데이터 갱신이 없으면
304 not modified(리다이렉션) + 헤더 정보만응답한다
네트워크 다운로드가 생기긴 하지만 헤더만 받으면 되고 이렇게 네트워크 과부화를 줄일 수 있다.
바뀌었다면?
- 요청이 들어온다 GET /star.jpg
- 여기에 last modified 를 넣어줄 수 있다.
- 웹 브라우저는 결과를 캐시에 저장하는데 동시에 modified도 저장한다.
- 다시 요청한다. 이때, 캐시에 있는 if-modified-since + last modifed를 보낸다.
- 이를 서버에서 받고 데이터가 수정되었다면, 200 ok를 보내고 수정시간을 포함한 헤더와 바디를 다시보낸다
- 캐시에 새로운 정보를 저장한다.
last modified의 단점
만약 주석이나 스페이싱같은 사소한것이 변해도 변경사항으로 저장되기때문에, 이는 또 낭비가 될 수 있다. 이런사항까지 완벽하게 통제할 수 있는것이 있다
ETag Entity Tag
캐시용데이터에 임의이 공휴한 버전이름을 달아둔다
예시) ETag: "v1.0", ETag "a2joidwjekji3"
데이터가 변경되면 이 이름을 바꾸어서 변경한다. (HASH를 다시 생성)
이 태그를 통해서 변경을 체크한다.
정리
캐시 제어 로직을 서버에서 완전 관리하고 클라이언트는 단순히 전송만해서 캐시 매커니즘을 아예 모른다
캐시 제어 헤더
Cache Control
- max-age : 캐시 수명
- no-cache : 데이터는 캐시해도 되지만, 원 서버에 검증하고 사용한다
- no-store : 민감한 정보라서 저장하면 안된다
Pragma
HTTP 1.0 하위호환, 이젠 안쓴다
Expires
캐시 만료일을 지정할 수 있다.
하지만 max-age가 더 유연해서 잘 쓰지 않는다.
만약 같이 써지면 max-age가 먼저 온다.
검증헤더
ETag
조건부 요청 헤더
If-Match, If-None-Match : ETag
If-Modified-Since, If-Unmodified-Since : last-modified 사용
프록시 캐시
해외 서버는 굉장히 멀다.
따라서 CDS 서비스라고 하는 프록시 캐시 서버를 각 지역마다 두고 그 안에 자료들을 캐시화해서
최초접근때 복사를 하고 두번째 접근부턴 캐시서버에 접근해서 더 빠르게 로딩가능하게 한는 기술이다.
캐시 지시어
public - 모든 사용자가 보는 정보
private - 응답이 해당 사용자만을 우히나 것임, private 캐시에 저장해야함
maxage - 프록시 캐시에만 저장되는 맥스 에이지
age = 60 - 오리진 서버 응답 후 캐시가 머무르는 시간 체크
캐시무효화
캐시를 하면 안도니느 정보들은 이렇게 무효화해야한다
Cache-Control
no-cache = 데이터는 캐시해도 되지만 원서버 검증해라
no store = 메모리에서 사용하고 최대한 빨리 삭제하라
must-revalidate = 캐시만료후 최초 조회시 원서버 검증
노캐시의 경우 캐시 서버에 요청을 하면 프록시 서버에서 원서버까지 가지고가서 점검을 하고 캐시를 검증하고 처리한다
만약 네트워크가 중단이 되더라도, 프록시 캐시서버 설정에 따라 구데이터라도 보여주는 세팅이라면 검증안된 캐시를 보여주기도 한다.
revalidate의 경우 위와 같은 네트워크 단절이 생기면 무조건 504 gateway timeout을 내버린다.
Pragma
no-cache = 구 버전을 위한 안전장치
