강력한 캐싱과 협상된 캐싱에 대해 이야기해 보겠습니다.

이 글은 소박하고 실용적이며 뛰어난 중국의 선한 청년 프론트 엔드 커뮤니티의 글쓰기 활동에 참여했습니다

브라우저에서 페이지를 열면 우리 모두 알고 있습니다. , 브라우저는 입력한 URL을 해당 서버에 사용하여 원하는 데이터 리소스를 요청합니다. 그러나 이 프로세스 중에 페이지가 페이지에 렌더링되기 전에 일정 시간(흰색 화면 시간) 동안 기다려야 할 수도 있습니다.

사용자 경험을 개선하려면 DNS 캐싱, CDN 캐싱 등 다양한 캐싱 기술을 언급해야 합니다. 브라우저 캐싱, 페이지 로컬 캐싱 등 좋은 캐싱 전략은 반복되는 리소스 요청을 줄이고 서버 오버헤드를 줄이며 사용자 페이지의 로딩 속도를 향상시킬 수 있습니다.

이 기사에서는 HTTP 강력한 캐싱과 협상된 캐싱에 대해 설명합니다.

브라우저는 리소스를 로드할 때 먼저 요청 헤더의 만료 및 캐시 제어를 기반으로 판단합니다. 강력한 캐시 정책이 적용되면 원격 서버에서 리소스를 요청할지 아니면 로컬에서 캐시 리소스를 얻을지 결정합니다.

브라우저에서 강력한 캐싱은 만료(http1.0 사양)와 캐시 제어(http1.1 사양)의 두 가지 유형으로 나뉩니다.

Expires는 http1.0의 사양으로, 리소스의 만료 시간을 나타내는 데 사용되는 요청 헤더 필드이며, 값은 서버에서 반환하는 절대 시간입니다.

브라우저가 처음으로 리소스를 요청할 때 서버 측 응답 헤더는 Expires 응답 필드를 첨부합니다. 브라우저가 다음에 이 리소스를 요청할 때 마지막 만료 필드를 기반으로 캐시된 리소스를 사용합니다. 요청 시간이 서버에서 반환한 만료 시간보다 짧은 경우 캐시된 데이터를 직접 사용합니다.)

Expires에는 클라이언트의 현지 시간이 수정되면 브라우저가 직접 변경하는 단점이 있다고 언급했습니다. Resources는 이 문제를 해결하기 위해 http1.1 사양에서 캐시 제어 필드를 제안하고 있으며 이 필드는 위에서 언급한 Expires보다 우선 순위가 높으며 값은 상대 시간입니다. .

캐시 제어에는 몇 가지 일반적인 응답 속성 값이 있는데,

위에서 언급한 강력한 캐시는 로컬 브라우저에서 캐시를 사용할지 여부를 결정합니다. 브라우저는 강력한 캐시에 도달하지 않으면 협상된 캐시에 도달했는지 확인하기 위해 브라우저에 요청을 보냅니다. 캐시에 도달하면 304 상태 코드가 반환되고, 그렇지 않으면 새 리소스 데이터가 반환됩니다.

협상 캐싱(비교 캐싱이라고도 함)은 서버에서 리소스를 사용할 수 있는지 확인하는 데 사용됩니다. 여기에는 두 개의 필드 세트가 쌍으로 나타나며 브라우저가 처음 요청(Last-Modified 또는 Etag)이 있는 경우 후속 요청은 해당 요청 필드(if-modified-since 또는 if-none-Match)를 전달합니다. 응답 헤더에 Last-Modified 또는 Etag가 없으면 요청 헤더에는 해당 필드가 없습니다.

요청 흐름도를 그려 보면 협상 캐싱이 무엇인지 금방 이해할 수 있습니다.

그 모습은 주로 last -modified의 문제를 해결하기 위한 것입니다. 해결하기 어려운 몇 가지 문제

만료와 캐시 제어가 동시에 존재하는 경우 캐시 제어는 만료와 만료를 덮어쓰게 됩니다. 만료 여부에 관계없이 유효하지 않습니다.

즉, Cache-control >expiration

Strong Cache와 Negotiation Cache가 동시에 존재하는 경우 Strong Cache가 유효한지 먼저 비교합니다. 협상 캐시, 즉 Strong 캐시 > 협상 캐시

협상 캐시 Etag와 last-modified가 동시에 존재하는 경우 Etag를 먼저 비교하고 last-modified가 유효하지 않은 경우, 즉 Etag > last-modified

이 캐시 전략은 만료 또는 캐시 제어 없이 마지막 수정 필드를 사용하여 네트워크 요청을 보내는 경우 브라우저가 기본 캐시를 갖게 됩니다. 정책(currentTime - 마지막 수정) * 0.1

HTTP 경험적 캐싱(캐시 제어 및 만료 헤더 누락) 설명