첫째, 캐시 란 무엇입니까?

일반적으로 캐시 ( "현금"이라고 발음)는 저장소 유형입니다. 저장소를 저장소 저장소라고 생각할 수 있습니다. 군대에서 이것은 임무를 수행하는 데 필요한 무기, 식량 및 기타 물품을 보관하는 것입니다.

컴퓨터 과학에서 이러한 "공급품"은 리소스라고하며 리소스는 스크립트, 코드 및 문서 콘텐츠입니다. 후자는 텍스트, 정적 데이터, 미디어 및 하이퍼 링크와 같은 "자산"이라고도하지만 여기서는 리소스 라는 용어를 사용 합니다 .

캐시와 다른 유형의 저장소의 차이점

캐시의 주요 목적은 웹 페이지 리소스 검색 속도를 높이고 페이지로드 시간을 줄이는 것입니다. 캐시의 또 다른 중요한 측면은 비교적 새로운 데이터를 포함하도록하는 것입니다.

이 기사에서는 브라우저 캐싱 과 CDN ( Content Delivery Networks ) 의 두 가지 일반적인 캐싱 방법을 다룹니다 .

캐시 외에도 다른 저장소가 웹 아키텍처에서 작동합니다. 종종 이들은 방대한 양의 데이터를 보유하도록 설계되었습니다. 그러나 그들은 검색 성능에 초점을 맞추지 않습니다.

예를 들어 Amazon Glacier는 데이터를 저렴하게 저장하지만 빠르게 검색하지 못하도록 설계된 데이터 리포지토리입니다. 반면에 SQL 데이터베이스는 유연하고 최신이며 빠르도록 설계되었지만 저렴하지 않으며 일반적으로 캐시만큼 빠르지는 않습니다.

브라우저 캐시 : 메모리 캐시

메모리 캐시는 브라우저가 실행되는 컴퓨터에 로컬로 리소스를 저장합니다. 브라우저가 활성화되어있는 동안 검색된 리소스는 컴퓨터의 실제 메모리 (RAM)에 저장되며 하드 드라이브에도 저장됩니다.

나중에 웹 페이지를 다시 방문 할 때 정확히 동일한 리소스가 필요한 경우 브라우저는 원격 서버 대신 캐시에서 리소스를 가져옵니다. 캐시는 빠른 메모리에 로컬로 저장되므로 해당 리소스를 더 빨리 가져오고 페이지를 더 빨리로드합니다.

자원 검색의 속도는 매우 중요하지만 자원이 신선해야 할 필요성도 있습니다. 오래된 리소스는 오래되어 더 이상 유효하지 않을 수있는 리소스입니다.

브라우저의 작업 중 일부는 캐시 된 리소스가 오래된 것을 식별하고 해당 리소스를 다시 가져 오는 것입니다. 웹 페이지에는 일반적으로 리소스가있을 수 있으므로 일반적으로 캐시에 오래된 버전과 최신 버전이 혼합되어 있습니다.

브라우저는 캐시에서 오래된 것이 무엇인지 어떻게 알 수 있습니까?

대답은 간단하지 않지만 캐시 무효화 및 HTTP 헤더 필드의 두 가지 주요 접근 방식이 있습니다.

캐시 무효화

캐시 무효화는 브라우저가 새 리소스 만 가져 오도록하는 서버 측 기술입니다. 이것은 간접적으로 수행됩니다.

캐시 무효화는 극적으로 들릴 수 있지만 실제로는 아무것도 무효화하지 않으며 브라우저에 이미 캐시 된 항목도 건드리지 않습니다. 모든 캐시 무효화는 리소스가 완전히 새로운 것으로 브라우저에 표시되도록 원본 리소스의 URI를 변경합니다. 새 것처럼 보이기 때문에 브라우저의 캐시에 없습니다. 캐시 된 리소스의 이전 버전은 여전히 캐시되지만 결국 시들어 죽어 다시 액세스 할 수 없습니다.

내가 www.foobar.com/about.html알고 싶은 foobar.com에 대한 모든 정보 를 제공 하는 웹 페이지가 있다고 가정 해 보겠습니다. 해당 페이지를 방문하면 해당 페이지와 관련 리소스가 브라우저에 의해 캐시됩니다.

나중에 Quxbaz 회사가 foobar.com을 매각하고 about 페이지의 콘텐츠가 크게 변경됩니다. 브라우저의 캐시는 새로운 콘텐츠를 가지지 않을 것이지만, 여전히 가지고있는 콘텐츠가 최신이라고 믿고 다시 가져 오지 않을 것입니다.

Quxbaz 웹 관리자 인 귀하는 모든 새 콘텐츠가 푸시되도록하기 위해 무엇을합니까?

브라우저는 캐시에서 항목을 찾기 위해 URI에 의존하기 때문에 리소스의 URI가 변경되면 브라우저가 서버에서 해당 리소스를 가져 오기 전에 본 적이없는 것과 같습니다.

따라서 리소스 URI를 www.foobar.com/about.html에서 www.foobar.com/about2.html(또는 www.quxbaz.com/about.html)로 변경하면 브라우저는 해당 URI와 관련된 캐시 리소스를 찾지 못하고 서버에서 전체 가져 오기를 수행합니다. 리소스는 이전 URI의 원본과 실질적으로 동일 할 수 있지만 브라우저는이를 알지 못합니다.

하지만 페이지 이름을 변경할 필요는 없습니다. URI에는 정의에 따라 쿼리 문자열도 포함되어 있으므로 URI에 버전 매개 변수를 추가 할 수 있습니다 www.foobar.com/about.html?v=2hef9eb1..

이 경우 버전 매개 변수 v 는 컨텐츠가 변경 될 때마다 새로 생성 된 해시 값으로 새로 설정되거나 서버 재시작과 같은 다른 프로세스에 의해 트리거됩니다. 브라우저는 쿼리 문자열이 변경되었음을 확인하고 쿼리 문자열이 반환되는 항목에 영향을 미칠 수 있으므로 서버에서 최신 리소스를 가져옵니다.

책갈피에서 이전 URI에 직접 액세스하는 경우 이러한 기술 중 어느 것도 작동하지 않습니다. 브라우저가 마지막으로 캐시 된 요청 (또는 캐시 된 리소스가 만료 됨)에서 URI를 재 검증하도록 지시하지 않는 한 캐시를 새로 고치기 위해 전체 가져 오기를 수행하지 않습니다. 다음 주제로 넘어갑니다.

HTTP 헤더 필드

모든 리소스 요청에는 헤더라고하는 일부 메타 정보가 함께 제공됩니다. 반대로 모든 응답에는 연관된 헤더 정보도 있습니다.

경우에 따라 브라우저는 응답 헤더 값을보고 후속 요청 헤더에서 해당 값을 변경합니다. 이러한 헤더 값 중에는 브라우저에서 리소스 캐싱이 수행되는 방식에 영향을주는 값이 있습니다.

HEAD 요청 및 조건부 요청

HEAD 요청은 잘린 GET 또는 POST 요청과 유사합니다. 전체 리소스를 요청하는 대신 HEAD 요청은 전체 요청에서 반환되는 헤더 필드 만 요청합니다.

리소스의 헤더는 일반적으로 관련 리소스 데이터 (응답의 "본문")보다 훨씬 작습니다 (총 바이트 수). 헤더 정보는 브라우저가 캐시에있는 리소스의 최신 성을 확인할 수 있도록 충분히 정보를 제공합니다.

HEAD 요청은 종종 서버 리소스의 유효성을 확인하는 데 사용됩니다 (즉, 리소스가 여전히 존재하고있는 경우 브라우저가 마지막으로 액세스 한 이후에 업데이트 되었습니까?). 브라우저는 HEAD 요청이 리소스가 유효 함을 나타내면 캐시에있는 내용을 사용하고, 그렇지 않으면 전체 GET 또는 POST 요청을 수행하고 반환 된 내용으로 캐시를 새로 고칩니다.

조건부 요청으로 브라우저는 캐시 된 리소스의 최신 성을 설명하는 헤더의 필드를 보냅니다. 이번에는 서버가 브라우저의 캐시가 아직 최신 상태인지 확인합니다.

그렇다면 서버는 리소스의 헤더 정보 만 포함하고 리소스 본문 (데이터)없이 304 응답을 반환합니다. 브라우저의 캐시가 오래된 것으로 확인되면 서버는 전체 200 OK 응답을 반환합니다.

이 메커니즘은 HEAD 요청을 사용하는 것보다 빠릅니다. 하나가 아닌 두 개의 요청을 발행 할 필요가 없기 때문입니다.

위의 내용은 매우 복잡한 프로세스를 단순화합니다. 캐싱과 관련된 많은 미세 조정이 있지만 모든 것이 헤더 필드를 통해 제어되며 가장 중요한 것은 캐시 제어입니다.

캐시 제어

요청에 응답 할 때 서버는 캐시 할 때 어떤 동작이 조정되어야하는지 나타내는 헤더 필드를 브라우저에 보냅니다. 에서 페이지를로드하면 //en.wikipedia.org/wiki/Uniform_Resource_Identifier응답의 헤더 레코드에 다음이 포함됩니다.

cache-control: private, s-maxage=0, max-age=0, must-revalidate

private 은 브라우저 만 문서 콘텐츠를 캐시해야 함을 의미합니다.

s-maxage 및 max-age 는 0 으로 설정됩니다 . S-에 maxage 반면 값은 캐시와 프록시 서버이다 있는 maxage가 브라우저를위한 것이다. max-age 만 설정 하면 캐시 된 리소스가 즉시 만료되지만 동일한 브라우저 세션에서 페이지를 다시로드하는 동안 (부실한 경우에도) 여전히 사용될 수 있습니다.

부실 리소스는 HEAD 요청을 통해 재 검증 될 수 있으며 응답에 따라 GET 또는 POST 요청이 뒤따를 수 있습니다. 반드시 재 검증 지시어가 오래된 경우 캐시 된 자원을 재 검증하도록 브라우저에 명령한다.

이후 최대 사용 기간이 설정되어 0 이 경우, 캐시 된 자원은 즉시 오래된 한 번받은 것입니다. 두 지시문의 조합은 단일 지시문 no-cache 와 동일 합니다 .

두 가지 설정은 브라우저가 동일한 세션에 있는지 여부에 관계없이 항상 캐시 된 리소스를 재 검증하도록합니다.

캐시 제어 지시문은 매우 광범위하고 때로는 혼란 스럽습니다. 그 자체로 주제입니다. 문서화 된 전체 지침 목록은 여기에서 확인할 수 있습니다.

전자 태그

이것은 서버가 전송하고 브라우저가 다음 요청까지 보유하는 토큰입니다. 이것은 브라우저가 리소스의 캐시 수명이 만료되었음을 알고있는 경우에만 사용됩니다.

E- 태그는 서버에서 생성 된 해시 값으로, 리소스의 실제 파일 이름과 서버에서 마지막으로 수정 한 날짜를 시드로 사용하는 경우가 많습니다. 리소스 파일이 업데이트되면 수정 된 날짜가 변경되고 새 해시 값이 생성되어 요청에 대한 응답 헤더로 전송됩니다.

캐싱에 영향을 미치는 기타 헤더 태그

헤더 태그 가 만료 되고 최종 수정 된 항목 은 모두 사용되지 않지만 이전 브라우저와의 하위 호환성을 위해 대부분의 서버에서 여전히 전송됩니다. 예 :

expires: Thu, 01 Jan 1970 00:00:00 GMT last-modified: Sun, 01 Mar 2020 17:59:02 GMT

여기서 만료 날짜는 0 번째 날짜로 설정됩니다 (역사적으로 UNIX 운영 체제에서). 이는 max-age = 0 과 마찬가지로 리소스가 즉시 만료됨을 나타냅니다 . Last-modified는 리소스에 대한 최신 업데이트가 언제 이루어 졌는지 브라우저에 알립니다. 그러면 캐시 값을 사용하는 대신 다시 가져와야하는지 여부를 결정하는 데 사용할 수 있습니다.

브라우저에서 캐시 새로 고침 강제

하드 재 장전이란 무엇입니까?

하드 리로드는 콘텐츠, 스크립트, 스타일 시트, 미디어 등 페이지의 모든 리소스를 강제로 다시 가져옵니다. 거의 모든 것이 맞죠?

글쎄, 일부 리소스는 페이지에 명시 적으로 포함되지 않을 수 있습니다. 대신, 일반적으로 명시 적 모든 항목이로드 된 후에 동적으로 가져올 수 있습니다.

브라우저는 이런 일이 발생할 것이라는 사실을 미리 알지 못하며, 그럴 경우 나중에 요청 (일반적으로 스크립트에 의해 시작됨)은 가능한 경우 해당 리소스의 캐시 된 사본을 계속 사용합니다.

캐시 지우기 및 하드 다시로드 란 무엇입니까?

이 작업은 하드 리로드와 동일한 효과를 갖는 전체 브라우저 캐시를 지우지 만 추가적으로 동적으로로드 된 리소스도 가져 오게합니다. 결국 캐시에 아무것도 없으므로 선택의 여지가 없습니다!

콘텐츠 전송 네트워크 : 지리적 위치 캐시

CDN은 단순한 캐시 그 이상이지만 캐싱은 작업 중 하나입니다. CDN은 지리적으로 분산 된 위치에 데이터를 저장하므로 지리적으로 로컬 브라우저를 오가는 왕복 시간이 줄어 듭니다.

브라우저 요청은 근처의 CDN으로 라우팅되므로 응답 데이터가 이동해야하는 물리적 거리가 단축됩니다. CDN은 또한 많은 양의 트래픽을 처리 할 수 있으며 일부 유형의 공격에 대한 보안을 제공합니다.

CDN은 인터넷의 백본 (대문자)의 일부인 노드 인 IXP (Internet Exchange Point)를 통해 리소스를 가져옵니다. 호스트 서버 대신 CDN으로 이동하도록 요청 라우팅을 설정하는 단계가 있습니다. 다음 단계는 CDN에 웹 사이트의 현재 콘텐츠가 있는지 확인하는 것입니다.

예전에는 대부분의 CDN이 푸시 방식을 지원했습니다. 웹 사이트는 새로운 콘텐츠를 CDN 허브로 푸시 한 다음 지리적으로 분산 된 노드에 배포했습니다.

오늘날 대부분의 CDN은 위에서 설명한 (또는 이와 유사한) 캐싱 프로토콜을 사용하여 1) 새 리소스를 다운로드하고 2) 기존 리소스를 새로 고칩니다. 브라우저에는 여전히 캐시가 있으며 변경 사항은 없습니다. CDN이하는 일은 새로운 리소스를 더 빠르게 전송하는 것입니다.