강 한 캐 시 와 협상 캐 시 상세 설명

강 캐 시
도대체 강 캐 시가 무엇 입 니까?강 한 게 어디 있어?강 한 것 은 강제 라 는 뜻 이다.브 라 우 저가 어떤 파일 을 요청 하 러 갔 을 때, 서버 는 respone header 에서 이 파일 에 캐 시 설정 을 했 습 니 다.캐 시 시간, 캐 시 유형 은 모두 서버 에서 제어 합 니 다. 구체 적 으로 respone header 의 cache - control 로 나타 납 니 다. 흔히 볼 수 있 는 설정 은 max - age Public private no - cache no - store 등 입 니 다.
다음 그림 에 서 는 cahe - control: max - age = 31536000, Public, immutable max - age 가 캐 시 시간 을 3153600 초 (1 년) 로 설정 하고, Public 는 브 라 우 저 와 프 록 시 에 캐 시 될 수 있다 고 표시 하 며, 프 록 시 서버 는 일반적으로 nginx 로 할 수 있다.immutable 은 이 자원 이 영원히 변 하지 않 는 다 는 것 을 표시 합 니 다. 그러나 실제 이 자원 은 영원히 변 하지 않 는 것 이 아 닙 니 다. 이 설정 은 사용자 가 페이지 를 새로 고 칠 때 서버 에 요청 하지 않도록 하 는 것 입 니 다!무슨 소리 야?즉, cahe - control: max - age = 31536000 만 설정 하면 Public 는 강 한 캐 시 에 속 합 니 다. 사용자 가 이 페이지 를 정상적으로 열 때마다 브 라 우 저 는 캐 시가 만 료 되 었 는 지, 만 료 되 지 않 았 는 지 캐 시 에서 데 이 터 를 읽 습 니 다.그러나 일부 '똑똑 한' 사용자 들 은 브 라 우 저 왼쪽 상단 의 리 셋 단 추 를 누 르 면 페이지 를 리 셋 합 니 다. 이 럴 때 자원 이 만 료 되 지 않 았 더 라 도 브 라 우 저 는 서버 에 직접 요청 합 니 다. 이것 은 추가 요청 이 소모 되 었 습 니 다. 이 때 는 캐 시 협상 절 차 를 밟 는 것 과 같 습 니 다.cahe - control: max - age = 315360000, Public 에 immutable 을 추가 하면 사용자 가 페이지 를 새로 고침 하 더 라 도 브 라 우 저 는 서 비 스 를 요청 하지 않 습 니 다. 브 라 우 저 는 로 컬 디스크 나 메모리 에서 캐 시 를 직접 읽 고 200 상 태 를 되 돌려 줍 니 다. 위의 그림 의 빨간색 상자 (from memory cache) 를 봅 니 다.2015 년 페 이 스 북 팀 이 HTTP 표준 을 제정 한 IETF 작업 팀 에 제안 한 것 이다. 그들 은 HTTP 프로 토 콜 이 Cache - Control 응답 헤드 에 속성 필드 를 추가 하여 이 자원 이 만 료 되 지 않 는 다 는 것 을 나타 내 기 를 바란다. 브 라 우 저 는 더 이상 이러한 자원 에 조건 을 요청 할 필요 가 없다.
강 한 캐 시 요약
cache - control: max - age = xxxx, Public 클 라 이언 트 와 프 록 시 서버 는 모두 이 자원 을 캐 시 할 수 있 습 니 다.클 라 이언 트 는 xxx 초의 유효기간 내 에 이 자원 에 대한 요청 이 있 으 면 캐 시 를 직접 읽 습 니 다. statu code: 200, 사용자 가 새로 고침 작업 을 하면 서버 에 http 요청 을 합 니 다.
cache - control: max - age = xxxx, private 는 클 라 이언 트 가 이 자원 을 캐 시 할 수 있 도록 합 니 다.프 록 시 캐 시 클 라 이언 트 가 xxx 초 안에 캐 시 를 직접 읽 습 니 다. statu code: 200
cache - control: max - age = xxxx, immutable 클 라 이언 트 는 xxx 초 유효기간 내 에 이 자원 에 대한 요청 이 있 으 면 캐 시 를 직접 읽 습 니 다. statu code: 200, 사용자 가 새로 고침 작업 을 하 더 라 도 서버 에 http 요청 을 하지 않 습 니 다.
cache - control: no - cache 는 강 한 캐 시 설정 을 건 너 뛰 지만 협상 캐 시 설정 에 방해 가 되 지 않 습 니 다.일반적으로 강 한 캐 시 를 만 들 었 다 면 강 한 캐 시가 효력 을 잃 었 을 때 만 협상 캐 시 를 사용 합 니 다. no - cache 를 설정 하면 강 한 캐 시 를 사용 하지 않 습 니 다. 요청 할 때마다 서버 에 문의 합 니 다.
cache - control: no - store 는 캐 시 를 하지 않 습 니 다. 이것 은 클 라 이언 트, 서버 를 캐 시 하지 않 고 강 한 캐 시, 협상 캐 시 라 는 것 도 없습니다.
협상 캐 시
위 에서 말 한 강 한 캐 시 는 자원 에 만 료 시간 을 설정 하 는 것 입 니 다. 클 라 이언 트 는 자원 을 요청 할 때마다 만 료 여 부 를 봅 니 다.만 료 되 어야 서버 에 문의 할 수 있 습 니 다.그래서 강 캐 시 는 클 라 이언 트 에 게 자급자족 용 으로 사용 하기 위 한 것 이다.어느 날 클 라 이언 트 가 이 자원 을 요청 할 때 기한 이 지난 것 을 발견 하면 서버 에 요청 하 는 것 이 고 이 럴 때 서버 에 요청 하 는 과정 에서 협상 캐 시 를 설정 할 수 있 습 니 다.이때 협상 캐 시 는 클 라 이언 트 와 서버 양 끝 이 상호작용 을 해 야 한다.
협상 캐 시 는 어떻게 설정 합 니까?
response header 설정

etag: '5c20abbd-e2e8'
last-modified: Mon, 24 Dec 2018 09:49:49 GMT

etag: 파일 마다 하나 가 있 습 니 다. 파일 을 바 꾸 면 변 합 니 다. 바로 파일 hash 입 니 다. 모든 파일 이 유일 합 니 다. 예 를 들 어 webpack 으로 포장 할 때 모든 자원 에 이런 물건 이 있 습 니 다. 예 를 들 어 app. js 를 포장 한 후에 app. c20abbde. js 로 바 뀌 고 유일한 hash 를 추가 하 는 것 도 캐 시 문 제 를 해결 하기 위해 서 입 니 다.
last - modified: 파일 의 수정 시간, 초 까지 정확 합 니 다.
즉, 매번 response header 에 있 는 etag 와 last - modified 를 되 돌려 달라 고 요청 할 때마다 request header 에서 이 두 개 를 가 져 옵 니 다. 서버 에서 가 져 온 표 지 를 비교 한 다음 에 자원 이 변경 되 었 는 지 여 부 를 판단 하고 변경 하면 새로운 자원 으로 돌아 가 해당 하 는 response header 의 표지 etag, last - modified 를 업데이트 합 니 다.자원 이 변 하지 않 으 면 etag, last - modified 가 변 하지 않 습 니 다. 이 럴 때 클 라 이언 트 에 게 매번 요청 할 때마다 협상 캐 시 를 해 야 합 니 다. 즉,:
요청 보 내기 – > 자원 이 만 료 되 었 는 지 확인 – > 만 료 – > 요청 서버 – > 서버 대비 자원 이 정말 만 료 되 었 는 지 확인 – > 만 료 되 지 않 았 습 니 다 – > 304 상태 코드 를 되 돌려 줍 니 다 – > 클 라 이언 트 용 캐 시 오래된 자원.
이것 이 바로 완전한 협상 캐 시 과정 이다.
물론 서버 에서 자원 이 정말 만 료 된 것 을 발견 하면 다음 과 같은 절 차 를 밟 습 니 다.
요청 을 보 냅 니 다 – > 자원 이 만 료 되 었 는 지 확인 합 니 다 – > 만 료 되 었 는 지 확인 합 니 다 – > 만 료 되 었 는 지 확인 합 니 다 – > 클 라 이언 트 는 이 자원 을 처음 받 은 것 처럼 cache - control 의 max - age, etag, last - modified 등 을 기록 합 니 다.
그래서 협상 캐 시 절차 요약:
자원 을 요청 할 때 사용자 로 컬 자원 의 etag 를 동시에 서버, 서버 와 최신 자원 을 비교 합 니 다.자원 이 변경 되 지 않 았 다 면 304 로 돌아 가 브 라 우 저 는 로 컬 캐 시 를 읽 습 니 다.자원 이 변경 되면 200 을 되 돌려 주 고 최신 자원 을 되 돌려 줍 니 다.
한 가 지 를 추가 합 니 다. response header 의 etag, last - modified 는 클 라 이언 트 가 서버 에 다시 요청 할 때 request header 에서 key 이름 을 바 꿉 니 다.

// response header
etag: '5c20abbd-e2e8'
last-modified: Mon, 24 Dec 2018 09:49:49 GMT

// request header   
if-none-matched: '5c20abbd-e2e8'
if-modified-since: Mon, 24 Dec 2018 09:49:49 GMT

왜 etag 가 있어 야 돼 요?
last - modified 를 사용 하면 브 라 우 저 에 게 로 컬 캐 시 복사 본 이 충분히 새 롭 고 왜 etag 가 필요 하 다 고 생각 할 수 있 습 니까?HTTP 1.1 에서 etag 의 등장 (즉, etag 는 새로 추 가 된 것 이 고 이전에 If - Modified 만 있 었 던 단점 을 해결 하기 위해) 은 주로 last - modified 가 해결 하기 어 려 운 몇 가지 문 제 를 해결 하기 위해 서 입 니 다.
일부 파일 은 주기 적 으로 변 경 될 수 있 지만 그의 내용 은 변 하지 않 습 니 다. (변 경 된 수정 시간 만) 이 럴 때 우 리 는 클 라 이언 트 가 이 파일 이 수정 되 었 다 고 생각 하고 다시 get 하 는 것 을 원 하지 않 습 니 다.
일부 파일 의 수정 이 매우 빈번 하 다. 예 를 들 어 초 이하 의 시간 내 에 수정 을 한다. (예 를 들 어 1s 내 에 N 번 수정 했다) if - modified - since 가 검사 할 수 있 는 입 도 는 초 단위 이다. 이런 수정 은 판단 할 수 없다 (또는 UNIX 기록 MTIME 는 초 까지 만 정확 할 수 있다).
일부 서버 는 파일 의 마지막 수정 시간 을 정확하게 얻 을 수 없다.
강 한 캐 시 와 협상 캐 시 를 어떻게 설정 합 니까?
nodejs res. setHeader ('max - age': '3600 public') res. setHeader (etag: '5c20abbd - e2e 8') res. setHeader ('last - modified': Mon, 24 Dec 2018 09: 49: 49 GMT) nginx 설정
어떻게 써 요?
예 를 들 어 현재 vue - cli 로 포장 한 후 생 성 된 단일 페이지 파일 은 html 이 있 고 js css img 자원 이 있 습 니 다. 이 파일 들 을 어떻게 설정 합 니까? 핵심 수 요 는?
캐 시 가 있 으 면 새 가방 을 보 낼 때 오래된 캐 시 자원 을 불 러 오 는 것 을 피해 야 합 니 다. 제 방법 은 index. html 파일 은 협상 캐 시 를 사용 합 니 다. 이 유 는 사용자 가 매번 index. html 에 브 라 우 저 캐 시 를 요청 하지 않 고 서버 에 직접 요청 해 야 하기 때 문 입 니 다. 그러면 자원 업 데 이 트 를 보증 할 수 있 습 니 다. 사용 자 는 바로 새로운 자원 에 접근 할 수 있 습 니 다. 만약 에 서버 에서 304 로 돌아 가면이때 브 라 우 저의 캐 시 를 가 져 오 는 index. html, 강 한 캐 시 를 설정 하지 마 세 요!!
다른 자원 은 강 한 캐 시 + 협상 캐 시 를 사용 하 는데 이 유 는 더 이상 말 하지 않 겠 습 니 다.