HTTP Cache 에 대한 간단 한 이야기

개술
이른바 HTTP Cache 메커니즘 이란 서버 와 클 라 이언 트 간 의 약속 으로 클 라 이언 트 와 서버 프로그램 에 의 해 구체 적 으로 실현 되 어야 한다.
현대 브 라 우 저 와 일부 추상 적 인 차원 에서 서버 웹 프레임 워 크 에 대해 어느 정도 에 이 약속 에 대한 지 지 를 실현 했다.그러나 우리 가 비교적 밑바닥 에 있 는 http 도 구 를 사용 하여 요청 을 받 을 때 이런 도 구 는 이러한 논 리 를 포함 하지 않 고 인공 적 으로 합 리 적 으로 실현 해 야 한다.
대략적인 흐름

클 라 이언 트 가 처음으로 서버 에 데 이 터 를 요청 합 니 다. 캐 시 를 사용 할 수 없 기 때문에 서버 는 항상 요청 한 데 이 터 를 보 냅 니 다

서버 는 Response 의 관련 Header 를 통 해 클 라 이언 트 가 내용 을 캐 시 하도록 지도 한다

클 라 이언 트 가 이 데 이 터 를 다시 요청 할 때 로 컬 캐 시 버 전 을 먼저 검사 합 니 다.

캐 시가 만 료 되 지 않 으 면 로 컬 캐 시 버 전 을 직접 사용 합 니 다

캐 시가 만 료 되면 캐 시 를 다시 검사 합 니 다.

클 라 이언 트 는 캐 시 된 지문 을 서버 에 보 내 고 서버 에 데 이 터 를 검사 해 달라 고 요청 합 니 다

일치 에 성공 하면 현재 데이터 가 업데이트 되 지 않 았 음 을 나타 내 고 서버 에서 데 이 터 를 다시 보 내지 않 습 니 다. 클 라 이언 트 는 로 컬 캐 시 기간 을 연장 하고 계속 사용 합 니 다

일치 에 실패 하면 현재 데이터 가 업데이트 되 었 음 을 나타 낸다. 서버 에서 클 라 이언 트 에 게 새 데 이 터 를 보 내 고 클 라 이언 트 는 오래된 캐 시 를 버 리 고 새 데 이 터 를 캐 시 한다

기술 세부 사항
서버 는 주로 Response 중의 Cache-Control Header 를 통 해 클 라 이언 트 가 데 이 터 를 캐 시 하도록 지도 한다.
예 를 들 어 서버 에서 클 라 이언 트 가 데 이 터 를 하루 동안 캐 시 하 기 를 원한 다 면 설정 할 수 있 습 니 다 Cache-Control: max-age: 86400.주의 max-age 의 매개 변 수 는 초 입 니 다.추가 로 서버 에 서 는 이 데이터 의 지문 을 지 니 고 있 는 Header ETag 도 첨부 된다.
클 라 이언 트 가 로 컬 캐 시가 만 료 된 것 을 발견 하면 서버 에 데 이 터 를 다시 요청 할 때 If-None-Match Header 를 가 져 옵 니 다. 그 값 은 서버 에서 데 이 터 를 전송 할 때 가지 고 있 는 ETag 데이터 의 지문 입 니 다. 즉, 서버 에서 데 이 터 를 검사 할 수 있 도록 합 니 다.
클 라 이언 트 캐 시 유효기간 내 에 데이터 요청 은 로 컬 캐 시 를 직접 읽 고 서버 에 실제로 보 내지 않 습 니 다.클 라 이언 트 가 로 컬 캐 시 를 강제로 업데이트 하려 면 Cache-Control: no-cache Header 를 가지 고 서버 에 캐 시 를 보지 않 고 바로 검사 절차 에 들 어가 라 고 알려 줄 수 있 습 니 다.
이상 의 예 는 단지 일반적인 용법 을 열거 하 였 을 뿐이다.no-store, smaxage, must-reinvalidate 등 일부 매개 변 수 는 더욱 정교 한 통 제 를 실현 하 는 데 도움 을 줄 수 있 고 여기 서 전개 되 지 않 습 니 다.
마지막 으로 더 많은 독자 들 이 아래 의 참고 링크 를 읽 기 를 바 라 는 것 에 감사 하고 추천 합 니 다.
레 퍼 런 스

HTTP Caching