프런트엔드 캐시의 HTTP 캐시(2)

1.1 HTTP 캐시란 무엇입니까?

HTTP 캐시: 클라이언트가 서버에 자원을 요청할 때 브라우저 캐시로 이동합니다. 브라우저 캐시에 요청할 자원의 복사본이 있으면 서버에 가지 않고 브라우저 캐시에서 직접 추출할 수 있습니다.
흔히 볼 수 있는 http 캐시는 get 방식으로 응답을 요청하는 자원만 캐시할 수 있고 다른 종류의 응답을 처리할 수 없습니다.
HTTP 캐시는 두 번째 요청부터 시작되며 첫 번째 요청이 있을 때 서버는 자원을 되돌려주고 요청 헤더에서 자원의 캐시 파라미터를 되돌려줍니다.두 번째 요청 시 브라우저는 이러한 매개 변수에 대해 판단하고 적중력 캐시는 200을 되돌려줍니다. 적중력 캐시는 요청 헤더에 요청 매개 변수를 추가하여 서버에 전송합니다. 적중력 협상 캐시는 304를 되돌려줍니다. (간단하게 말하면 서버가 GET를 실행했지만 파일이 변하지 않았습니다.) 그렇지 않으면 서버는 새로운 자원을 되돌려줍니다.
HTTP 캐시는 강력한 캐시와 협상 캐시로 나뉩니다.강제 캐시가 적용되면 서버와 상호작용을 할 필요가 없고, 협상 캐시는 효력이 발생하든 안 발생하든 서비스 측과 상호작용을 해야 한다.

1.1.1 강력한 캐시

캐시 데이터가 효력을 상실하지 않은 경우 (즉 Cache-Control의 max-age가 만료되지 않았거나 Expires의 캐시 시간이 만료되지 않은 경우) 브라우저의 캐시 데이터를 사용하여 서버에 더 이상 요청을 보내지 않습니다.강제 캐시가 적용될 때 http 상태 코드는 200입니다.이 방식은 페이지가 불러오는 속도가 매우 빠르고 성능이 좋지만, 이 기간에 서비스 측의 자원이 수정되면 서버에 요청을 보내지 않기 때문에 페이지에서 얻을 수 없습니다.예를 들어 우리가 실제 개발에서 어떤 페이지의 스타일을 수정하고 페이지에서 리셋했지만 수정된 내용은 효력이 발생하지 않았다. 왜냐하면 강한 캐시를 사용하기 때문에 이때 Ctrl+F5가 필요하다.
헤더 속성:

Pragma(HTTP/1.0)

no-cache: 캐시를 직접 사용하지 않고 신선도에 따라 캐시를 사용합니다. 응답 헤더는 이 속성을 지원하지 않습니다. 우선순위가 가장 높지만 HTTP/1.1에서 폐기되었습니다

Cache-Control(HTTP/1.1)

no-cache: 캐시를 직접 사용하지 않고 신선도에 따라 캐시를 사용합니다

no-store: 캐시를 사용하지 않고 매번 새로운 자원을 다운로드해 달라고 요청합니다

max-age: 캐시 시간

public/private: 한 사용자만 사용할 수 있는지, 기본값은private입니다

must-revalidate: 매번 접근할 때마다 캐시 검사 요청 헤더와 응답 헤더가 이 속성을 지원합니다. HTTP/1.0에는 적용되지 않습니다. 캐시가 효력을 상실하기 전에 수정된 자원을 얻지 못합니다

Expires(시간)

GMT 타임 서버와 클라이언트의 시간이 일치하지 않으면 문제가 발생할 수 있습니다. HTTP/1.0과 HTTP/1.1은 캐시가 효력을 상실하기 전에 수정된 자원을 얻지 못합니다

1.1.2 협상 캐시

첫 번째 요청 시 서버가 되돌아오는 응답 헤더에 Cache-Control과 Expires가 없거나 Cache-Control과 Expires가 만료되거나 그의 속성이 no-cache로 설정되어 있지 않으면 브라우저가 두 번째 요청 시 서버와 협상하여 서비스기와 비교하여 자원이 업데이트되었는지 판단합니다.서버 측의 자원이 수정되지 않으면 304로 돌아가 브라우저에 캐시에 있는 데이터를 사용할 수 있음을 알려주면 서버의 전송 압력을 줄일 수 있다.데이터가 업데이트되면 서버는 200 상태 코드를 되돌려주고 서버는 업데이트된 자원을 되돌려주며 캐시 정보를 함께 되돌려줍니다.

ETag/If-Not-Match(HTTP/1.1)

검사 값은 기본적으로hash 알고리즘을 사용하고 분포식 환경에서 서로 다른 서버에서 생성된 ETag 값이 일치하지 않을 수 있습니다.자원이 수정되었는지 정확하게 판단하고 1초 동안의 수정 횟수를 식별할 수 있다.ETag를 계산하려면 성능 소모가 필요합니다

Last-Modified/If-Modified-Since(HTTP/1.0)

GMT 시간은 자원이 수정되면 내용에 변화가 있든 없든 클라이언트에게 자원을 되돌려줍니다.시간을 표지로 하여 1초 동안의 수정 변화를 얻을 수 없음;일부 서버는 마지막 수정 시간을 정확하게 얻을 수 없습니다

브라우저가 처음으로 서버에 요청을 보낼 때 응답 헤더에서 협상 캐시 헤더의 속성인 ETag와 Last-Modified를 되돌려줍니다. 그 중에서 ETag는 하나의hash값을 되돌려줍니다. Last-Modified는 GMT 형식의 마지막 수정 시간을 되돌려줍니다.브라우저가 두 번째로 요청을 보낼 때 요청 헤더에 ETag에 대응하는 If-Not-Match를 가져옵니다. 이 값은 응답 헤더에서 되돌아오는 ETag의 값입니다. Last-Modified는 If-Modified-Since에 대응합니다.서버는 이 두 파라미터를 받은 후에 비교합니다. 만약에 304를 되돌려주면 요청 자원이 수정되지 않았습니다. 브라우저는 캐시에서 데이터를 얻을 수 있습니다. 그렇지 않으면 서버가 데이터를 되돌려줍니다.
ETag/If-Not-Match는 HTTP/1.1에서 주로 다음과 같은 문제를 해결합니다.
(1), Last-Modified 마크업의 마지막 수정은 초까지만 정확할 수 있으며, 일부 파일이 1초 이내에 여러 번 수정되면 파일의 수정 시간을 정확하게 표시할 수 없습니다
(2), 만약 일부 파일이 수정되었지만 내용은 아무런 변화가 없고, Last-Modified는 변경되어 파일이 캐시를 사용할 수 없습니다
(3), 서버가 파일 수정 시간을 정확하게 가져오지 못하거나 프록시 서버와 일치하지 않는 경우

2.1 HTTP 캐시는 어떻게 사용합니까?

일반적으로 캐시가 필요한 자원은 html 페이지와 다른 정적 자원이 있습니다.

html html 페이지 캐시 설정은 주로 헤드 라벨에 메타 라벨을 삽입하는데 이런 방식은 페이지만 유효하고 페이지의 자원에 무효입니다

캐시 해제

IE 브라우저에서만 인식되는 탭입니다. 요청 필드에 Pragma를 추가할 필요는 없지만 현재 페이지에서 매번 새로운 요청을 보낼 수 있습니다

<meta http-equiv="pragma" content="no-cache">

기타 메인스트림 브라우저에서 식별되는 태그

<meta http-equiv="cache-control" content="no-cache">

IE 브라우저에서만 식별되는 탭입니다. 이 방식은 IE 캐시 시간을 알 수 있는 표시일 뿐, 요청이나 응답 메시지에서 Expires 필드를 찾을 수 없습니다

<meta http-equiv="expires" content="0">

캐시 설정

IE 브라우저에서만 인식되는 레이블입니다

<meta http-equiv="Expires" content="Mon, 20 Aug 2018 23:00:00 GMT" />

기타 메인스트림 브라우저에서 식별되는 태그

<meta http-equiv="Cache-Control" content="max-age=7200" />

정적 자원 정적 자원의 캐시는 일반적으로 웹 서버에 설정된다. 예를 들어nginx,Apache..

2.2 주의사항

강력한 캐시 상황에서 캐시가 만료되지 않으면 캐시에서 데이터를 직접 찾습니다. 서버 측에서 데이터가 바뀌어도 서버 측에서 가져오지 않습니다. 그러면 수정된 데이터를 얻을 수 없습니다.해결 방법은 다음과 같다. 수정된 자원에 무작위 수를 더해서 캐시에서 꺼내지 않도록 하는 것이다

304의 요청을 최대한 줄여야 한다. 협상 캐시는 매번 백엔드 서버와 상호작용을 하기 때문에 성능이 좋지 않다는 것을 우리는 알고 있기 때문이다.성능 측면에서 볼 때 가능한 한 강력한 캐시를 많이 사용하세요.

더 자세한 내용은 이 녀석이 쓴 글을 볼 수 있다