헤더에 cache-control 추가
ex)
cache-control:max-age=30 // 캐시가 유효한 시간 : 30초
1.최초 요청
응답 결과를 캐시에 저장
2. 두번째 요청
캐시 유효 시간 검증 + 캐시 조회
▪️ 캐시 가능 시간동안은 네트워크 사용 안해도 됨
▪️ 비싼 네트워크 사용량 줄일 수 있음
▪️ 브라우저 로딩 속도가 매우 빠름
▪️ 캐시 시간 초과한 경우 서버를 통해 데이터를 다시 조회하고 캐시 갱신
➡️ 기존 데이터와 변동이 없다면 네트워크 낭비가 생김
캐시 유효시간이 초과해서 서버에 다시 요청할 때, 기존 데이터의 변경이 없다면 네트워크 낭비가 생김
➡️ 데이터를 다시 다운로드받는 것이 아니라 캐시를 재사용한다.
단, 클라이언트의 데이터와 서버의 데이터가 같다는 것을 확인할 수 있어야 함
캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
Last-Modified
ex) Last-Modified: 2023-08-29T09:00:00 // 데이터의 최종 수정 시간
ETag(Entity Tag)
캐시용 데이터에 임의의 고유 버전 이름을 달아둠
ex) ETag: "v1.0", ETag:"DDeo99"
데이터가 변경되면 달아놓은 이름을 바꾸어서 변경
(Hash 다시 생성 -> 파일 컨텐츠가 같으면 해쉬값 같음)
ex) ETag: "ddddd" -> ETag: "eeeee"
클라이언트 입장에서 ETag를 보고 같으면 캐시에서 사용, 다르면 다시 다운로드
If-modified-since, If-Unmodified-Since -> Last-Modified와 함께 사용
ex) If-modified-since: 2023-08-29T09:00:00 // 데이터 최종 수정 시간
If-None-Match, If-Match -> ETag와 함께 사용
ex) If-None-Match: "dddddddd" // 해쉬값
조건 만족 ➡️ 200 OK / 조건 불만족 ➡️ 304 Not Modified
1. 최초 요청
응답 결과(데이터 최종 수정일 포함)를 캐시에 저장
2. 캐시 시간을 초과한 두번째 요청
if-modified-since 헤더를 포함하여 요청
3. 서버는 요청받은 데이터의 최종 수정 시간을 비교 검증
장점
▪️ 캐시 유효시간이 초과해도 서버의 데이터가 갱신되지 않으면
304 Not Modified + 헤더 메타 데이터 정보만 응답
▪️ 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보 갱신
캐시에 저장되어 있는 데이터 재활용 가능해짐
▪️ 데이터 변경이 없는 경우 네트워크 다운로드는 발생하지만 용량이 적은 헤더 정보만 다운로드하면 됨
단점
▪️ 1초 미만 단위로 캐시 조정 불가능
▪️ 날짜 기반의 로직을 사용
A->B->A 순으로 수정을 하여 최종적으로 수정이 되지 않은 것과 같으나 다른 데이터로 판단할 것
➡️ 서버에서 별도의 캐시 로직을 관리하고 싶은 경우에는 ETag 사용
✅ 데이터 변경 없는 경우
➡️ 응답에 304 Not Modified
cache-control, LastModified 헤더 포함
HTTP Body 없음 (헤더만 전송)➡️ 응답 결과 재사용
헤더 데이터 갱신(chache-control...)➡️ 요청데이터 캐시에서 조회
데이터 변경이 있다면 200 OK, 모든 데이터 전송(HTTP Body O)
1. 최초 요청
요청에 대한 응답으로 서버는 ETag 헤더를 포함하여 전송
ETag값을 캐시에 저장
2. 캐시 시간 초과 후에 두번째 요청
If-None-Match헤더 포함하여 전송
3. 서버는 ETag값과 If-None-Match 값을 비교하여 검증
ETag값과 If-None-Match값이 같으면 데이터 수정 안된 것
ETag만 보내서 같으면 유지, 다르면 다시 받기
캐시 제어 로직을 서버에서 완전히 관리 -> 클라이언트는 블랙 박스 상태
클라이언트는 단순히 값을 서버에 제공만, 캐시 매커니즘은 모름
✅ 데이터 변경 없는 경우
➡️ 응답에 304 Not Modified
cache-control, ETag 헤더 포함
HTTP Body 없음 (헤더만 전송)➡️ 응답 결과 재사용
헤더 데이터 갱신(chache-control...)➡️ 요청데이터 캐시에서 조회
Cache-Control : 캐시 제어
Pragma: 캐시 제어
HTTP 1.0 하위 호환, 잘 사용하지 않음
Expires: 캐시 유효 기간
캐시 만료일 지정, 초단위가 더 유연 -> Cache-Control: max-age 사용 권장
Cache-Control: max-age
: 캐시 유효 시간, 초 단위
Cache-Control: no-cache
: 항상 조건부 요청을 사용하여 ORIGIN 서버에 검증하고 사용해야 함
Cache-Control: no-store
: 데이터에 민감한 정보가 있으니 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제해라)
A 나라의 클라이언트들이 B 나라에 있는 origin서버에 접근한다면 응답이 느릴 것
➡️ A 나라에 프록시 캐시 서버를 두고 클라이언트들은 프록시 캐시 서버에 요청을 보냄
➡️ 응답 속도가 빠름
클라이언트(웹 브라우저) - private 캐시
프록시 캐시 서버 - public 캐시
캐시 적용 안하더라도 웹브라우저가 임의로 캐시를 적용하기도 함
➡️ 확실한 캐시 무효화 응답
Cache-Control: no-cache
데이터는 캐시 OK, 항상 origin 서버에 검증하고 사용
origin 서버에 접근 불가 상태(네크워트 단절)일 경우 프록시 캐시가 과거 데이터로 응답할 수도
Cache-Control: no-store
데이터에 민감한 정보가 있으니 저장하면 안됨
Cache-Control: must-revalidate
캐시 만료 후 최초 조회시에 origin 서버에 검증해야
origin 서버에 접근 불가 상태(네크워트 단절)일 경우 반드시 오류 발생시킴 (504 Gateway Timeout)
Pragama: no-cache
HTTP 1.0 하위 호환
인프런 / 모든 개발자를 위한 HTTP 웹 기본 지식 (김영한) 참조