원인 중 상위 20% 가 전체 결과의 80% 를 만든다

최근 접근한 데이터는 다시 접근할 확률이 크다

최근 접근한 데이터 주변 공간에 다시 접근할 확률이 크다

/*
시간 지역성 - 배열의 원소에 접근하는 인덱스로 사용되는 변수 i
공간 지역성 - 배열의 0 ~ 9 번 째 요소 
*/

const arr = [];

for (let i = 0 ; i < 10 ; i++) {
  arr[i] = i;
}

캐시는 CPU 칩 안에 들어가는 작고 빠른 메모리다. 프로세스가 매번 메인 메모리에 접근해 데이터를 받아오면 시간이 오래 걸리기 때문에, 캐시에 자주 사용하는 데이터를 담아두고, 해당 데이터가 필요할 때 프로세서가 메인 메모리 대신 캐시에 접근하도록 해 처리 속도를 높인다.

자주 찾을 것 같은 데이터를 어딘가에 저장해서 시간을 절약하자!

통상적으로 원래의 데이터 저장소보다 빠르고, 자주 액세스되는 데이터를 보유

하드웨어, 운영체제, 웹 브라우저, 웹 애플리케이션 등에서 다양하게 사용

캐싱은 웹 브라우저부터 웹서버와 하드디스크 및 CPU에 이르기까지 모든 곳에 적용된다.

네트워크를 통해 무언가를 가져오는 작업은 느린 동시에 비용도 많이 든다. 클라이언트의 요청과 응답의 복사본을 저장했다가 동일한 URL에 대한 요청이 있으면 서버에 다시 요청하지 않고, 저장해 둔 리소스를 서빙하거나 재사용하는 것을 웹 캐시(web cache)라 한다

• latency 절약 - 서버에 요청을 하고 기다릴 필요가 없기 때문에 시간이 절약된다.
• 네트워크 트래픽 절약 - 리소스를 재사용하기 때문에 클라이언트가 사용하는 대역폭이 줄어든다. 만약 데이터 통신에 비용이 든다면, 비용을 절감할 수 있다.

CDN (Contents Delivery Network), Proxy Server (Forward Proxy, Reverse Proxy, web accelerator ···. ), load balancer, browser cache···.

단일 사용자를 위한 캐시이다. 브라우저에 저장되는 캐시로, 뒤로 가기, 앞으로 가기, 새로 고침등 방문했던 페이지에 사용된다.

다수의 사용자를 위한 캐시이다. 인기글 같이 많이 조회가 되는 리소스들을 저장한다.

캐시 키 : 요청 메서드 + 대상 URI 　 　 GET /files

• GET 요청의 성공한 결과: HTML, JS, CSS, 이미지 등 정적 리소스 파일에 대한 GET 요청이 성공했을 때의 결과 200 OK
• 영구적인 리다이렉트: 301 응답
• 페이지를 찾을 수 없음: 404 응답
• 완전하지 않은 결과 : 206 (부분적인 컨텐츠) 응답
• 캐시 키로 사용하기에 적절한 무언가가 정의된 경우의 GET 이외의 응답 (?)

브라우저 캐시는 하드 디스크나 메모리의 한 부분에 저장한다. 브라우저가 수행하는 모든 HTTP 요청은 먼저 요청하기 전에 사용할 수 있는 유효한 캐시된 응답이 있는지 확인하기 위해 브라우저 캐시로 전송한다. 일치하는 응답이 있으면 캐시에서 읽는다.

캐시에 사용하는 다음의 API는 모든 브라우저에서 지원된다.

• Cache-Control : 어떻게, 얼마나, 누가 캐시할지
• ETag : 브라우저에서 만료된 응답에 대해 리소스가 바뀌었는지에 대한 유효성 검사
• Last-Modified : ETag와 동일. 하지만 토큰이 아닌 시간을 기준으로 유효성 검사

이점

• 서버 측에서는 해당 요청에 대한 응답 리소스를 다 보내주지 않아도 된다
• 브라우저는 요청에 대한 응답을 기다리지 않아도 된다
• 데이터 통신에 드는 비용을 절감할 수 있다

메모리 캐시는 브라우저를 닫을 때까지 컨텐츠 사용하고, 디스크 캐시는 영구적으로 동작한다.

😃 브라우저가 어떻게 정하는지는 모르겠음

브라우저가 만드는 모든 HTTP 요청은 먼저 브라우저 캐시로 라우팅되어, 네트워크 요청 전 사용할 수 있는 캐시된 응답이 있는지 확인한다. 캐시된 응답이 있고, 유효하다면 요청을 보내지 않고 해당 응답을 읽어 사용한다 → 레이턴시 및 트래픽 절감

1. 응답 헤더가 캐시에 보관하지 말라고 지시하면 캐시하지 않는다.
2. 요청이 인증 또는 보안 (예 : HTTPS) 인 경우, 공유 캐시에 캐시하지 않는다.
3. 다음과 같은 경우에는 캐시한 리소스를 사용한다.
   • 만료 시간이나 유효 시간이 헤더에 있고, 여전히 캐시의 유효 시간이 남아있을 때
   • 캐시가 최근에 표시를보고 비교적 오래 전에 수정 된 경우 (?)
4. 리소스의 캐시가 만료됐을 때, 서버는 이를 검증하여 여전히 사용해도 되는지 알려준다.
5. 특정 상황 (예 : 네트워크와의 연결이 끊어진 경우)에서 캐시는 서버에 검증하지 않고, 만료된 캐시를 사용한다.

ETag나 Last-modified 가 응답 헤더에 없다면, 일반적으로 캐시할 수 없다고 간주된다. (항상 그런건 아님)

캐시에서 유효 시간과 검증은 컨텐츠를 재사용에 있어 중요하다. 캐시에서 유효기간이 만료되었을 경우, 서버에서 새로운 리소스를 응답받아 사용할 수 있지만, 유효성 검사를 통해 리소스가 변경되지 않았을 경우 캐시된 응답을 사용한다.

HTTP/1.1 스펙에서 요청 헤더와 응답 헤더의 조합으로 제어한다.

Cache-Control: no-store
Cache-Control: no-cache, no-store, must-revalidate

Cache-Control: no-cache

• no-store: 어디서든 캐시하지 마라

  매 요청이 서버로 전송되고 응답 받음

• no-cache: 매번 사용하기 전 서버에 사용해도 되냐고 물어봐라

  Etag가 있을 경우, 캐시된 응답의 유효성을 검사하는 데 한 번 통신하지만, 리소스가 변경되지 않은 경우 다운로드받지 않을 수 있다.

• must-revalidate : 만료된 캐시만 물어봐라

Cache-Control: private
Cache-Control: public

• public 응답은 모든 곳에서 저장될 수 있다.

  보통 명시적인 캐싱 정보 max-age 가 응답이 어느 경우에도 캐시 가능하다고 나타내므로, 명시하지 않아도 된다. HTTP 인증으로 보호된 페이지는 private로 설정되어 공유 캐시에 저장되지 않는다. 이 경우에 public으로 명시적으로 설정하면 인증이 된 상태에도 캐시한다.

• private

  브라우저만 캐시하도록 설정한다. 이 경우에 공유 캐시 (ex, proxy) 에서는 캐시할 수 없다.

Cache-Control: max-age=60

캐시한 응답을 사용할 수 있는 최대 시간 (초)이다. 위의 경우 60초 동안 캐시되어 재사용할 수 있다.

Etag와 Last-Modified 를 이용해 만료된 리소스에 대해 재검증을 요청한다.

처음 요청 후 120초가 지난 후에 동일한 리소스에 대해 새 요청을 했다고 가정해보자. 브라우저는 로컬 캐시를 확인하고 이전 응답을 찾는다. 하지만 브라우저는 이전 응답이 만료되어 사용할 수 없다. 이 시점에서 브라우저는 새 요청을 보내고 전체 리소스를 다시 다운로드할 수 있다. 하지만, 리소스가 변경되지 않은 경우 이미 캐시에 있는 동일한 정보를 다운로드 할 이유가 없기에 이 작업은 비효율적이다.

Etag 의 유효성 검사 토큰은 이 문제를 해결하기 위해 나왔다. 서버는 일반적으로 리소스에 해시나 토큰을 생성하고 반환한다. 토큰이 유효하다면, 리소스가 변경되지 않았기 때문에 다운로드를 건너 뛸 수 있다.

If-None-Match: 해당 리소스의 Etag 값 

브라우저는 만료된 리소스를 재 요청시, HTTP 요청 헤더에 ETag 토큰을 자동으로 추가한다. 서버는 현재 리소스와 비교하여 토큰을 검사하고, 토큰이 변경되지 않았다면 캐시한 리소스를 계속 사용하라는 304 Not Modified 응답을 반환한다. 응답을 전송시에 전송할 데이터가 거의 없으므로, 요청된 리소스를 다시 보내는 것보다 훨씬 빠르고, 통신 비용을 절감할 수 있다.

Cache-control: max-age=N

위의 경우 캐시의 유효 수명은 N과 동일하다. 만약 이 헤더가 없다면, Expires 헤더를 검사한다. Expires 헤더도 없다면 Last-Modified 헤더를 찾는다. 유효 수명은 다음과 같이 계산된다. 위에 있을수록 우선 순위가 높다.

유효 수명

= max-age

= Expires 헤더 - Date 헤더

= ( Date 헤더 - Last-Modified 헤더 ) / 10

최대한 많은 응답을 최대한 길게 캐시하고, 각 응답에 재검증이 가능하도록 유효성 검사를 하자!

Cache-Control: max-age=31536000

캐시된 리소스는 캐시 유효 수명만큼 별다른 이유(사용자가 브라우저 캐시를 지움)가 없을 때까지 해당 캐시를 재사용한다. 효율적으로 서빙하기 위해 캐시 기간을 길게 잡았는데, 웹페이지를 수정했다면 어떨까? 서버는 요청을 받지 않는 이상, 클라이언트에게 업데이트된 사실을 알릴 수 없다. 이 경우에는 캐시되지 않은 브라우저는 업데이트된 웹페이지를 사용하지만, 캐시된 브라우저는 이전 버전의 파일을 사용해 업데이트 되지 않은 웹 사이트를 보게 될 수 있다. 최대한 길게 캐시하면서, 빠른 업데이트를 할 수 있을까? 파일의 내용이 변경되면 브라우저가 캐시된 기존 파일을 사용하지 않고 새로운 파일을 내려받도록 해야 한다.

리소스의 URL을 변경하고, 컨텐츠가 변경될 때마다 사용자가 새응답을 다운받도록 하면 된다.

• HTML

  no-cache 설정은 매 요청마다 재검증을 통해 컨텐츠가 변경된 경우에만 최신 버전을 가져오게 한다. html 안에 link나 script 태그 안에 있는 css, js 파일 경로가 포함되기 때문에 이 파일들의 컨텐츠가 변경되면, 페이지의 HTML 또한 변경되어 요청시 업데이트 된 내용을 다운로드하게 된다.

• CSS, JS

  CDN 등이 캐시할 수 있다. 위의 경우에 CSS가 업데이트되면 html 내의 URL도 변경되기 때문에 1년이라는 긴 시간후에 만료되도록 설정할 수 있다.

MDN - HTTP caching

브라우저의_캐시_매커니즘

웹 캐쉬- 갓대희의 작은공간

HTTP 캐싱

웹 캐싱의 숨겨진 요소들

웹 캐시(WEB Cache)란 무엇인가?

The hidden components of Web Caching

[10분 테코톡] 🐻큰곰의 Cache

Caching Tutorial

Express.js 서버는 왜 304를 반환하는 걸까?

Express.static()

Module ngx_http_headers_module