먼저 캐시란 무엇입니까? 

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

https://www.freecodecamp.org/news/what-is-cached-data/ 

군사 유통 네트워크

컴퓨터 과학에서 이러한 "공급품"은 자원이라고 하며, 여기서 자원은 스크립트, 코드 및 문서 내용입니다. 후자는 텍스트, 정적 데이터, 미디어 및 하이퍼 링크와 같은 "자산"이라고 하는 경우가 많지만 여기서는 한 가지 용어 인 resource를 사용합니다.

캐시와 다른 유형의 리포지토리의 차이점 

캐시의 기본 목적은 웹 페이지 리소스 검색 속도를 높이고 페이지 로드 시간을 줄이는 것입니다. 

캐시의 또 다른 중요한 측면은 비교적 새로운 데이터가 포함되도록 하는 것입니다.

이 기사에서는 브라우저 캐싱과 CDN (Content Delivery Network)이라는 두 가지 일반적인 캐싱 방법에 대해 설명합니다.

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

예를 들어 Amazon Glacier는 데이터를 저렴하게 저장하지만 빠르게 검색하지 않도록 설계된 데이터 리포지토리입니다. 반면에 SQL 데이터베이스는 융통성 있고 최신 상태이며 빠르도록 설계되었지만, 캐시만큼 빠르지 않고 저렴하지는 않습니다.

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

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

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

자원 검색 속도는 본질적이지만 자원이 신선해야 할 필요성도 있습니다. 부실 리소스는 오래되어 더 이상 유효하지 않을 수 있습니다.

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

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

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

캐시 파열 

Sarah Shaffer의 사진 / Unsplash

캐시 버스 팅은 브라우저가 새로운 리소스 만 가져 오도록 하는 서버 측 기술입니다. 간접적으로 이 작업을 수행합니다.

캐시 버스 팅은 극적으로 들릴지 모르지만 실제로는 아무 것도 터뜨리지 않으며 브라우저에 이미 캐시 된 것을 건드리지 않습니다. 모든 캐시 버스 팅은 자원이 완전히 새로운 것처럼 브라우저에 표시되는 방식으로 원래 자원의 URI를 변경합니다. 새로운 것처럼 보이기 때문에 브라우저 캐시에 없습니다. 캐시 된 리소스의 이전 버전은 계속 캐시되지만 결국에는 다시 액세스 할 수 없게 됩니다.

www.foobar.com/about.html에 foobar.com에 대해 알고 싶은 웹 페이지가 있다고 가정 해 봅시다. 해당 페이지를 방문하면 해당 페이지 및 페이지와 관련된 리소스가 브라우저에 의해 캐시 됩니다.

나중에 foobar.com은 Quxbaz 회사에서 구입했으며 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 요청을 사용하는 것보다 빠릅니다. 하나 대신 두 개의 요청을 발행 할 필요가 없기 때문입니다.

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

Cache-Control 

요청에 응답 할 때 서버는 캐싱 할 때 어떤 동작을 적용해야 하는지 나타내는 헤더 필드를 브라우저로 보냅니다. https://en.wikipedia.org/wiki/Uniform_Resource_Identifier에서 페이지를 로드 하면 헤더 레코드에 응답이 포함됩니다.

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

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

s-maxage 및 max-age는 0으로 설정됩니다. s-maxage 값은 캐시가 있는 프록시 서버에 대한 것이고 max-age는 브라우저에 대한 것입니다. max-age 만 설정하면 캐시 된 리소스가 즉시 만료되지만 동일한 브라우저 세션에서 페이지를 다시로드 하는 동안 여전히 리소스가 오래 될 수 있습니다.

오래된 자원은 HEAD 요청을 통해 재확인 될 수 있으며, 응답에 따라 GET 또는 POST 요청이 뒤따를 수 있습니다. must-revalidate 지시문은 브라우저에 캐시 된 자원이 무효 인 경우 유효성을 검증하도록 명령합니다.

이 경우 max-age가 0으로 설정되므로 캐시 된 리소스는 일단 수신 되면 즉시 무효가 됩니다. 두 지시문의 조합은 단일 지시문 no-cache와 동일합니다.

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

캐시 제어 지시문은 매우 광범위하고 때로는 혼란스러워 – 자체 주제입니다. 지시문의 전체 문서 목록은 여기에서 찾을 수 있습니다.

E-tag 

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

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

캐싱에 영향을 주는 다른 헤더 태그 

헤더 태그가 만료되고 마지막으로 수정 된 것은 오래되었지만 여전히 대부분의 서버에서 이전 브라우저와의 호환성을 위해 전송됩니다. 예를 들면 :

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

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

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