Nginx 는 어떻게 캐 시 를 연기 합 니까?

3000 단어 nginxcache-control
Nginx 가 proxy cache 파일 을 응답 으로 사용 할 때 Date 응답 헤더 와 같은 내용 을 업데이트 합 니 다.그러나 대부분의 응답 헤드 는 Expires 와 Cache - Control 등 업데이트 되 지 않 습 니 다.Cache - Control 은 max - age = xxx 또는 s - maxage = xxx 명령 을 통 해 캐 시 유효 시간 을 설정 할 수 있 습 니 다.Expires 응답 헤드 와 달리 이 시간 은 상대 적 입 니 다.상위 서버 가 되 돌 아 왔 다 고 가정 하면 Nginx 는 이 응답 을 한 시간 동안 캐 시 합 니 다.이 시간 이 만 료 되 기 전에 Client 가 Nginx 를 방문 하면 같은 Cache - Control 응답 헤드 를 가 져 오기 때문에 한 시간 더 캐 시 합 니 다.그래서 전체적으로 이 응답 은 두 시간 동안 캐 시 됩 니 다.
이것 은 듣 기 에 매우 놀랍다.하지만 곰 곰 이 생각해 보면 심각 한 문제 도 아니다.우선, 우리 가 설정 Cache-Control: public; max-age=3600 할 때 대부분 상황 에서 엄격하게 한 시간 후에 기한 을 넘 기 라 고 요구 하지 않 는 다.그 다음으로 이것 은 일반적인 다 중 캐 시 고유 한 단점 이 라 고 할 수 있 습 니 다. 캐 시 데이터 의 최대 만 료 시간 은 각급 캐 시 TTL 의 총화 에 달 려 있 습 니 다.피 하려 면 외부 데이터 에 따라 남 은 TTL 을 선택 하여 현재 TTL 을 설정 할 수 있 습 니 다.또는 주동 적 인 Purge 작업 을 제공 하고 가장 안쪽 부터 데 이 터 를 한 층 씩 정리 합 니 다.
물론 이 행 위 는 어떤 때 는 문제 가 될 수 있다.예 를 들 어 우리 가 proxy 를 열 었 다 고 가정 하 자.cache_use_stale, 상위 서버 에 문제 가 생 겼 을 때 정상 적 인 응답 대신 만 료 된 내용 을 사용 합 니 다.이 경우 캐 시 는 임시 구급 방안 으로 만 사용 되 며 클 라 이언 트 가 더 많은 시간 을 캐 시 하 는 것 을 원 하지 않 습 니 다.그렇지 않 으 면 상류 애플 리 케 이 션 개발 자 들 은 왜 상류 서버 가 정상 적 이 고 사용자 가 페이지 를 새로 고 치 는 것 이 오래된 데이터 인지 불평 할 것 이다.해결 방법 으로 우 리 는 Nginx 의 header filter 단계 에서 Lua 코드 나 Nginx C module 을 통 해 max-age=3600Cache-Control: max-age=... 로 수정 할 수 있다.이렇게 되면 클 라 이언 트 는 캐 시 를 사용 하기 전에 먼저 검 증 됩 니 다. Nginx 가 304 상태 코드 를 되 돌려 주면 이 캐 시 는 계속 사 용 됩 니 다.상위 에 OK 가 있 고 응답 이 업데이트 되면 클 라 이언 트 는 만 료 된 내용 을 사용 하지 않도록 다시 요청 합 니 다.
여기 서 강조해 야 할 것 은 Cache-Control: no-cache 글자 의 의미 가 캐 시 되 지 않 는 다 는 것 이 아니 라 클 라 이언 트 가 이 캐 시 를 사용 하기 전에 캐 시 된 내용 이 최신 인지 확인 해 야 한 다 는 것 이다.MDN 의 표현 은:
Forces caches to submit the request to the origin server for validation before releasing a cached copy.
대응 하 는 RFC 7234 의 표현:
The "no-cache" request directive indicates that a cache MUST NOT use
a stored response to satisfy the request without successful
validation on the origin server.
클 라 이언 트 가 응답 하 는 내용 을 캐 시 하지 않 으 려 면 MDN 에 있 는 대로 no-cache (https://developer.mozilla.org...)。 Cache-Control: no-cache, no-store, must-revalidate / no-cache / no-store 이 세 가지 명령 에 대한 소 개 를 자세히 살 펴 보면 must-revalidate 클 라 이언 트 가 이 캐 시 를 사용 하지 않 게 할 수 있 을 것 같 습 니 다. no-store 요구 가 있 기 때 문 입 니 다.
The cache should not store anything about the client request or server response.
또한 no-store 기한 이 지난 캐 시 를 사용 하기 전에 이 내용 이 최신 인지 검증 해 달라 고 요 구 했 고 must-revalidate 도 재 검증 을 요구 했다. 그런데 왜 둘 다 같이 사용 해 야 합 니까?
Google 검색 에서 이 SO 문답 에 저 를 데 리 고 왔 습 니 다.https://stackoverflow.com/que...。이 대답 은 왜 단순히 no-cache 만 사용 하지 않 는 지 설명 했다. 악명 높 은 IE6 브 라 우 저 는 처리 no-store 할 때 bug 가 있 기 때문이다.그러나 안 타 깝 게 도 이 대답 은 IE 의 bug report 와 같은 논단 의 증 거 를 제시 하지 않 았 다.MDN 은 no-store 이 예 를 제시 할 때 도 더 많은 문맥 을 언급 하지 않 았 다.이것 은 주석 이 없 는 오래된 코드 와 같다. 우 리 는 당초에 왜 이렇게 썼 는 지 모 르 지만, 그것 을 지 우 는 것 은 아무런 문제 가 없 을 것 같다.

좋은 웹페이지 즐겨찾기