HTTP 캐싱

이전에 가져온 리소스를 로컬에 저장하고 클라이언트가 리소스를 요청할 때 해당 리소스를 응답하는 기술이다. 비용 절감, 성능 향상의 이점이 있다.

캐시의 종류

Private browser caches(사설 브라우저 캐시)

• 단일 사용자

• 브라우저 캐시가 사용자에 의해 HTTP를 통해 다운로드된 모든 문서들을 가지고 있다.

• 서버에 대한 추가적인 요청 없이 뒤로 가기, 앞으로 가기, 저장, 소스로 보기 등을 위해 방문했던 문서들을 만드는 데 사용된다.

Shared proxy caches(공유 프록시 캐시)

• 여러명의 사용자가 재사용하는 응답을 저장한다.
• 예) ISP나 회사에서 웹프록시를 설치해 조회가 많이 되는 리소스들은 몇 번이고 재사용할 수있도록 만든다.

그외

• 게이트웨이 캐시
• CDN
• 리버스 록시 캐시
• 로드 밸런서

CDN: 클라이언트가 물리적으로 멀리 떨어져 있으면 컨텐츠를 다운로드 받을 때 시간이 오래 걸린다. 클라이언트와 가까운 곳에 위치한 캐시 서버에 컨텐츠를 저장(캐싱)하고 컨텐츠 요청 시에 캐시 서버가 응답하여 빠르게 컨텐츠를 받을 수 있다. 즉, 물리적으로 떨어져 있는 클라이언트에게 컨텐츠를 더 빠르게 제공할 수 있는 기술이다.

캐싱 동작의 대상

• 주로 GET에 대한 응답을 캐싱한다.
• 일차 캐시키
  • 요청 메서드
  • 대상 URI
• 캐싱 엔트리 폼
  • 요청된 결과: HTML 문서, 이미지, 파일과 같은 리소스를 포함하는 GET 요청에 대한 200(OK) 응답
  • 301 응답: 영구적인 이동
  • 404: 페이지 찾을 수 없음
  • 206: 부분적인 컨텐츠 응답
  • 기타 GET 외 응답(캐시 키로 사용하기에 적절한 무언가가 정의되었을 때)

URI(Uniform Resource Identifier, URI): 통합 자원 식별자로, 인터넷 에 있는 자원을 나타내는 유일한 주소이다. URI의 하위개념으로 URL, URN이 있다.

캐시 관련 헤더

Cach-control 헤더의 옵션

• no-store: 응답을 캐시할 수 없으며 매 요청마다 전체를 가져온다.
• no-cache: 캐시를 사용하기 전 서버에 확인을 받도록 한다. (이 캐시 진짜 써도 되니..?)
• must-revalidate 만료된 캐시만 서버에 확인을 받도록 한다.
• private: 공유 캐시에 저장해도 된다.
• private: 공유 캐시에 저장하면 안 되고 브라우저와 같은 특정 사용자 환경에만 저장해야 한다.
• max-age: 캐시 유효시간. 리소스가 신선하다고 간주될 최대 시간(freshness lifetime이라고 부른다)을 지정하는 명령어이다. 그 시간을 지나면 만료된 것으로 여겨진다.

그 외 헤더

• Age: max-age 시간 내에서 얼마나 경과했는지 초 단위로 알려준다.
• Expires: 응답 컨텐츠가 언제 만료되는 지 알려주는 헤더. Cache-Control의 max-age가 있는 경우 이 헤더는 무시된다.
• Etag: HTTP 컨텐츠가 바뀌었는 지 검사할 수 있는 헤더. 같은 주소의 리소스라도 컨텐츠가 달라졌으면 Etag도 다르다. 이 값을 통해 클라이언트가 서버의 응답 내용이 달라진 것을 알게 되어 캐시를 지우고 새 컨텐츠를 받을 수 있게 된다.
• If-None-Match: 클라이언트가 서버에게 Etag가 달라졌는 지 검사해서 다를 경우에 컨텐츠를 보내주라는 뜻이다. Etag가 다르다는 건 컨텐츠가 달라졌다는 뜻이기 때문에 바뀐 바뀐 컨텐츠를 보내주게 된다. Etag가 같다면 304 Not Modified(변경사항 없음)를 응답하고 클라이언트는 기존 캐시를 그대로 사용한다.
• Pragma: HTTP/1.1의 Cache-Control 헤더가 생기기 전에 HTTP/1.0에서 대용 헤더로 사용되었다. 기능은 유사하다.
• Vary: 동일한 URL에 대해 요청을 하더라도 요청한 사용자의 특징(User Agent, Accept Encoding, Origin 등)에 따라 서로 다른 응답을 하기 위해 존재하는 헤더.
  • User-Agent: 캐싱하고 있는 컨텐츠의 최초 User-Agent 정보가 일치하지 않으면 캐싱된 컨텐츠를 전달하지 않는다. 예를 들어 모바일 유저에게 데스크톱 버전을 실수로 서브하는 일을 피하도록 해준다.

Freshness(신선도)

캐시는 리소스를 로컬에(혹은 웹프록시에) 저장해 클라이언트가 서버에 리소스를 요청할 때마다 다운로드 하지 않고 캐시에 있는 리소스를 바로바로 보내기 때문에 빠르게 웹페이지가 로드된다(성능이 향상된다). 그러나 여기서는 신선도(Freshness)의 문제가 있다. 서버에서 리소스를 수정했는데도 기존 리소스를 가져온다면 수정이 반영되지 않을 것이다. 그렇다면 성능을 챙기면서 어떻게 적정 수준의 신선도를 유지할 수 있을까?

• cache eviction(캐시 추출): 저장소는 한정되어 있으니 캐시도 주기적으로 제거된다.
• 서버에서 리소스를 업데이트한다면? 리소스 만료 시점에 대해 통신해야 한다. 이 만료시점 이전까지는 리소스가 신선하다고 간주된다.
• 그러나 신선하지 않은 리소스가 바로 추출되거나 무시되는 것은 아니다. 캐시가 캐시가 신선하지 않은 리소스에 대한 요청을 받으면 해당 리소스가 서버의 리소스와 차이가 있는지 확인하기 위해 If-None-Match 요청을 서버에 보낸다.
• 서버는 이 요청을 받고 서버의 리소스가 수정이 되었는지 확인하고 수정되지 않았으면 해당 리소스 전송 없이 304(Not Modified)라고 응답한다.

• 신선도 lifetime 계산하기

  

• 만료시간 = responseTime + freshnessLifetime - currentAge

Reference

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=ko

https://www.zerocho.com/category/HTTP/post/5b594dd3c06fa2001b89feb9

https://tech.kakao.com/2017/10/23/wcache-2/