-
캐시가 없을 때
- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야한다.
- 인터넷 네트워크는 매우 느리고 비싸다
- 브라우저 로딩 속도가 느리다.(느린 사용자 경험)
캐시 적용
- cache-control: max-age =60 //캐시 지속시간(?) 60초로 설정
- 캐시 덕분에 캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다.
- 비싼 네트워크 사용량을 줄일 수 있다.
- 브라우저 로딩 속도가 매우 빠르다.
- 빠른 사용자 경험
캐시 시간 초과
- 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
- 이때 다시 네트워크 다운로드가 발생한다.(불필요한 손실)
캐시 시간 초과(해결방안)
검증헤더(Last-Modified)와 조건부(if-Modified-since) 요청
- 서버 데이터를 변경하지 않았을 경우(검증이 필요함)
- Last-Modified / if-modified-since 이 둘을 비교해서 변경 유무를 확인(날짜를 보고 비교하고 판단)
- 304 Not Modified(변경 x), HTTP Body가 없다.헤더만 전송
- 헤더가 0.1m, 바디가 1.0m라고 가정했을 때, 0.1m만 보내서 손실 최소화(효율성 상승)
- 서버 데이터가 변경되었을 경우
- if-Modified-since와 Last-Modified가 서로 다름, 따라서 200 OK 호출되면서 모든 데이터 전송(헤더+바디)
- 단점
- 초단위기 때문에 초 이하 단위로는 캐시 조정이 불가능
- A->B로 수정했다가 B->A로 수정했다면, 결국 A로 결정됐는데 날짜가 다름. 따라서 전체 데이터를 다시 받게 됨.
검증헤더(ETag)와 조건부 요청(if-none-match)
- if-None-Match / ETag
- 조건이 만족하면 200, 그렇지 않으면 304
- 날짜가 아닌 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다.
- 데이터가 변경되면 이 이름을 바꿔서 변경한다(Hash를 다시 생성)
- 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!
- 캐시 제어 로직을 서버에서 완전히 관리
- 사용 예) 서버는 베타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
- 애플리케이션 배포 주기에 맞춰 ETag 모두 갱신
캐시 제어 헤더
- 캐시-컨트롤
- cashe-control: max-age
- Cashe-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
- Cashe-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
프록시 캐시
- 원 서버 직접 접근(원 서버 : 진짜 리소스가 있는 서버)
- 장거리에 위치한 서버에 빠르게 접속하기 위해 프록시 캐시 서버 구축
- 프록시 캐시 서버는 public server
- Cashe-Control 기본은 private
캐시 무효화
- 캐시가 되면 안되는 프로그램에 사용
- Cashe-Control: no-cache, no-store, must-revalidate(revalidate:재검증)
- no-cache : 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
- no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨
- must-revalidate : 캐시 만료후 최초 조회시 원 서버에 검증해야함.
- 네트워크 장애로 원서버에 요청이 닿지 않았을 때, 임시방편으로 프록시 서버에서 응답을 해주는 no-cache 정책이 있는데
- must-revalidate는 항상 오류가 발생하도록 하는것(504 Gateway Timeout)
- pragma: no-cache : HTTP 1.0 하위 호환