캐시
자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소로 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공
- 캐시가 없는 경우
- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함
- 인터넷 네트워크는 매우 느리고 비쌈
- 브라우저 로딩 속도가 느림
- 느린 사용자 경험을 줌
- 캐시가 있는 경우
- 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
- 비싼 네트워크 사용량을 줄일 수 있음
- 브라우저 로딩 속도가 매우 빠름
- 빠른 사용자 경험을 줌
- 캐시 시간 초과
- cache-control: max-age=캐시 유효 시간(초) 로 표현
- 캐시 유효 시간이 초과하면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신
- 다시 네트워크 다운로드 발생
- 캐시 유효 시간 초과
- 캐시 유효 시간이 초과 후 서버에 다시 요청 시 다음 2가지 상황이 나타남
- 서버에서 기존 데이터를 변경
- 서버에서 기존 데이터를 변경하지 않음
- 캐시 만료후에도 서버에서 데이터를 변경하지 않는 경우 데이터를 캐시에서 재사용 가능
- 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요
검증 헤더와 조건부 요청
클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법으로 조건부 요청 헤더와 같이 사용
- 검증 헤더 : 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
- Last-Modifined, ETag
- 조건부 요청 헤더 : 검증 헤더로 조건에 따른 분기
- if-modified-since
- 조건 만족(캐시에 있던 데이터와 서버에 요청한 데이터가 다름)시 200 OK
- 조건 불만족(캐시에 있던 데이터와 서버에 요청한 데이터가 같음)시 304 Not Modified
- if-modified-since
- 검증 헤더의 값과 조건부 요청의 값의 조합으로 서버에 요청한 데이터가 갱신되지 않았으면 서버는 헤더만 전송
- 캐시에 원하는 데이터가 있으므로 HTTP Body를 전송하지 않음
- HTTP Body를 전송하지 않음으로써 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
- 네트워크 부하 줄어듬
- 클라이언트는 캐시에 저장되어 있는 데이터 재활용 가능
- 매우 실용적
단점
- 1초 미만 단위로 캐시 조정이 불가능
- 날짜 기반의 로직 사용으로 같은 데이터를 수정해서 데이터 결과가 같지만 날짜가 다른 경우 존재
- 최종적으로 데이터는 변경되지 않았으나 날짜 변경으로 인해 전체 데이터 다운로드
- 이를 극복하기 위해 ETag 사용
ETag
캐시용 데이터에 임의의 고유한 버전 이름을 달아두는 것
- ex. ETag: "v1.0", ETag: "abc" 등
- 데이터 변경 시 이 이름을 바꾸어서 변경(Hash를 다시 생성)
- 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받음
- 캐시 제어 로직을 서버에서 완전히 관리
프록시 캐시
클라이언트와 서버 사이에 대리로 통신을 수행하는 중계 기능을 가진 서버
- 외국 영상을 보려면 오래 걸리니, 한국에 프록시 서버를 두어 한국인들은 프록시 서버에서 데이터를 다운받음