브 라 우 저 & HTTP 캐 시 정책

캐 시 정책
브 라 우 저의 캐 시 정책 은 HTTP Header 에 의 해 이 루어 집 니 다. 모두 두 가지 로 나 눌 수 있 습 니 다.

강 캐 시

협상 캐 시

강 캐 시
강 한 캐 시 란 캐 시 기간 에 서버 에 요청 하지 않 고 브 라 우 저 에서 캐 시 결 과 를 되 돌려 주 는 것 을 말 합 니 다. Header 를 설정 해 야 합 니 다.

expires

Cache-Control

expires

expires: Wed, 10 Oct 2020 09:51:00 GMT

expires 는 HTTP / 1.0 에서 웹 캐 시 를 제어 하 는 필드 로 서버 가 이 요청 결과 의 캐 시 만 료 시간 을 되 돌려 줍 니 다. 즉, 같은 요청 을 다시 시작 할 때 클 라 이언 트 시간 이 Expires 값 보다 적 으 면 브 라 우 저 는 캐 시 결 과 를 직접 되 돌려 줍 니 다.
expires 는 클 라 이언 트 시간 으로 캐 시 실효 시간 과 비교 하지만 클 라 이언 트 시간 은 수정 할 수 있 습 니 다. 클 라 이언 트 시간 과 서버 시간 이 일치 하지 않 으 면 강 한 캐 시 가 효력 을 잃 거나 시효 가 적 습 니 다.
그래서 HTTP / 1.1 에 cache - control 헤드 를 추가 했다.
cache-control
cache - control 일반적인 값 은:

Public: 모든 내용 이 캐 시 됩 니 다 (클 라 이언 트 와 프 록 시 서버 는 캐 시 가능)

private: 모든 내용 은 클 라 이언 트 만 캐 시 할 수 있 고 기본 값 은 private

입 니 다.

no - cache: 클 라 이언 트 캐 시 내용 이지 만 캐 시 사용 여 부 는 협상 캐 시 를 통 해 결정 해 야 합 니 다

no - store: 모든 내용 이 캐 시 되 지 않 습 니 다

max - age = xxx: 캐 시 내용 은 xxx 초 후에 효력 을 상실 합 니 다

예 를 들 어 보 겠 습 니 다.
이 예 에서 expires 와 cache - control 은 모두 설정 되 어 있 지만 cache - control 우선 순위 가 높 기 때문에 이 자원 은 2592000 초 (즉 30 일) 후에 효력 을 잃 습 니 다.
우 리 는 두 가지 결론 을 얻 을 수 있다.

expires 와 cache - control 이 동시에 존재 할 때 cache - control 만 유효 합 니 다.

HTTP / 1.1 을 지원 하지 않 는 환경 에서 expires 는 용 도 를 발휘 합 니 다. 현 단계 의 존 재 는 호환성 을 위 한 것 입 니 다

Memory Cache & Disk Cache

F12 에서 브 라 우 저 네트워크 요청 을 볼 때 이러한 정 보 를 본 적 이 있 을 것 입 니 다. from memory cache (메모리 캐 시) 와 from disk cache (디스크 캐 시).
강 한 캐 시 를 요청 하면 브 라 우 저 는 메모리 나 디스크 에서 캐 시 된 자원 을 되 돌려 주 고 서버 에 도착 하지 않 습 니 다.
그렇다면 어떤 자원 캐 시 는 memory 에 있 고 어떤 캐 시 는 disk 에 있 습 니까?
memory cache 와 disk cache 에 대해 Chrome 공식 적 으로 다음 과 같은 설명 이 있 습 니 다.
Caching
Chrome employs two caches — an on-disk cache and a very fast in-memory cache. The lifetime of an in-memory cache is attached to the lifetime of a render process, which roughly corresponds to a tab. Requests that are answered from the in-memory cache are invisible to the web request API. If a request handler changes its behavior (for example, the behavior according to which requests are blocked), a simple page refresh might not respect this changed behavior. To make sure the behavior change goes through, call handlerBehaviorChanged() to flush the in-memory cache. But don't do it often; flushing the cache is a very expensive operation. You don't need to call handlerBehaviorChanged() after registering or unregistering an event listener.
이상 참조 Chrome API
memory 의 캐 시 자원 을 읽 는 것 은 disk 를 읽 는 것 보다 빠 를 것 입 니 다. 그러나 memory 의 캐 시 는 프로 세 스 가 풀 리 면서 방출 됩 니 다. 즉, Tab 탭 을 닫 으 면 memory 의 캐 시 도 없어 집 니 다.
그러면 어떤 자원 이 memory 에 캐 시 되 고 어떤 자원 이 disk 에 캐 시 됩 니까? 이 점 에 대해 저도 정설 을 찾 지 못 했 습 니 다. 대부분의 관점 은 다음 과 같 습 니 다. 참고 하 시기 바 랍 니 다.

큰 파일 은 disk 로 우선 캐 시 하고 작은 파일 은 memory

로 우선 캐 시 합 니 다.

메모리 사용량 이 높 은 경우 disk

로 우선 캐 시 합 니 다.
협상 캐 시
강 한 캐 시 를 명중 시 키 지 않 거나 강 한 캐 시가 효력 을 잃 으 면 서버 에 요청 하여 자원 이 업데이트 되 었 는 지 검증 해 야 합 니 다. 이 과정 을 협상 캐 시 라 고 합 니 다.
브 라 우 저가 인증 자원 을 요청 할 때 자원 이 바 뀌 지 않 으 면 서버 는 304 상태 코드 를 되 돌려 주 고 브 라 우 저 캐 시 유효기간 을 업데이트 합 니 다. 자원 이 바 뀌 면 서버 는 200 상태 코드 를 되 돌려 주 고 해당 자원 을 되 돌려 주 며 브 라 우 저 캐 시 유효기간 을 업데이트 합 니 다.
그러면 서버 에서 자원 이 업데이트 되 었 는 지 확인 하 는 방법 은 다음 과 같은 두 개의 HTTP 헤드 를 사용 해 야 합 니 다.
last-modified & if-modified-since
last - modified 는 파일 의 마지막 수정 날 짜 를 표시 합 니 다. 서버 에서 Response Header 에 추 가 했 습 니 다. if - modified - since 는 브 라 우 저 에서 Request Header 에 추 가 했 습 니 다. 이 자원 의 last - modified 값 입 니 다.
서버 가 요청 을 받 으 면 if - modified - since 와 서버 에 있 는 이 파일 의 수정 시간 스탬프 를 비교 합 니 다. 캐 시 시간 을 초과 하면 최신 자원, 200 상태 코드 를 되 돌려 주 고 캐 시 유효기간 내 에 있 으 면 304 상태 코드 를 되 돌려 줍 니 다.

위의 이 예 는 볼 수 있다.

Request Header 에서 if - modified - since: Fri, 20 Dec 2019 12:44:01 GMT

Response Header 에서 last - modified: Fri, 20 Dec 2019 12:44:01 GMT

이 서버 는 if - modified - since 의 시간 과 서버 에 있 는 파일 의 수정 시간 을 비교 한 결과 캐 시 시간 유효기간 내 에 있 는 것 을 발 견 했 기 때문에 304 상태 코드 를 직접 되 돌려 주 고 파일 자원 을 되 돌려 주지 않 으 며 브 라 우 저 에서 캐 시 된 자원 을 제공 합 니 다.
그러나 last - modified 도 단점 이 있다.

서버 에 있 는 파일 이 열 리 고 수정 되 지 않 으 면 수정 시간 스탬프 도 바 뀌 고 last - modified / if - modified - since 가 효력 을 잃 으 며 서버 는 같은 자원

을 되 돌려 줍 니 다.

last - modified / if - modified - since 는 초 단위 로 파일 이 수정 되면 이 헤더 서버 에 따 르 면 파일 이 수정 되 지 않 았 다 고 생각 하고 캐 시 협상 에 명중 하여 오래된 자원 으로 돌아 갑 니 다

.
이 문제 들 때문에 HTTP / 1.1 에 etag / if - none - match 가 나 타 났 습 니 다.
etag & if-none-match
etag 는 파일 지문 과 유사 합 니 다. md5 와 같은 파일 내용 에 대한 요약 알고리즘 을 만 들 수 있 습 니 다. 생 성 된 값 은 etag 의 값 으로 서버 에서 Response Header 에 추 가 됩 니 다. 브 라 우 저가 이 자원 을 다시 요청 할 때 Request Header 에 if - none - match 헤드 를 추가 합 니 다. 값 은 지난번 etag 의 값 입 니 다. 서버 가 요청 을 받 으 면 요청 자원 에 대해 같은 요약 알고리즘 을 다시 만 듭 니 다., if - none - match 값 과 비교 하여 다 르 면 자원 업데이트, 200 및 업 데 이 트 된 자원 파일 을 되 돌려 줍 니 다. 같 으 면 파일 이 수정 되 지 않 았 음 을 설명 하고 304 를 되 돌려 주 며 브 라 우 저 에서 캐 시 자원 을 되 돌려 줍 니 다.
결론 적 으로 last - modified / if - modified - sic 와 etag / if - none - match 는 서버 를 되 돌려 주 는 값 입 니 다. 브 라 우 저 에서 요청 을 보 낼 때 가 져 가 고 서버 가 값 을 받 은 후 로 컬 파일 의 특정한 속성 과 판단 하여 새로운 자원 으로 돌아 갈 지, 브 라 우 저 에서 캐 시 자원 으로 돌아 갈 지 여 부 를 결정 합 니 다. 이 과정 을 협상 캐 시 라 고 합 니 다.
expires 와 cache - control, etag / if - none - match 와 같은 우선 순 위 는 last - modified / if - modified - since 보다 높 습 니 다.
캐 시 정책 이 설정 되 어 있 지 않 으 면 브 라 우 저 는 시작 식 알고리즘 을 사용 합 니 다. 보통 Response Header 의 date 헤드 를 읽 고 last - modified 값 의 10% 를 캐 시 시간 으로 줄 입 니 다.
전체 흐름 도

실제 장면
위의 캐 시 정책 을 배 웠 습 니 다. 실제 장면 에서 우 리 는 어떻게 응용 해 야 합 니까?
잦 은 변동 자원

캐 시 를 전혀 하지 않 습 니 다. cache - control: no - store

캐 시, cache - control: no - cache 를 협상 하여 브 라 우 저 로 하여 금 요청 할 때마다 서버 를 이동 하 게 한 다음 에 etag 또는 last - modified 와 결합 하여 자원 이 효과 적 인지 검증 합 니 다. 이렇게 하면 캐 시 되 지 않 은 것 에 비해 HTTP 요청 이 서버 에 도착 하 는 횟수 를 줄 일 수 는 없 지만 응답 데이터 의 크기

를 현저히 줄 일 수 있 습 니 다.
문건

HTML 파일 에 캐 시 를 설치 하지 않 음

CSS, JS, 이미지 등 파일 자원 은 비교적 긴 캐 시 유효기간 을 설정 할 수 있 습 니 다. 예 를 들 어 1 년, cache - control: max - age = 31536000, HTML 파일 이 도입 한 파일 이름 이 변 할 때 만 최신 자원 파일 을 다운로드 할 수 있 습 니 다. 그렇지 않 으 면 캐 시

를 계속 사용 합 니 다.