데이터나 값을 미리 복사해 놓는 임시 장소
- 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우 사용
- 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간없이 더 빠른 속도로 데이터에 접근 가능
- 캐시는 운영 체제, 네트워킹 계층(콘텐츠 전송 네트워크(CDN), DNS 등), 웹 애플리케이션 및 데이터베이스를 비롯한 다양한 기술 계층에 걸쳐 적용 및 활용 가능
클라이언트에게 웹 콘텐츠를 제공할 때 사용하는 캐시
- 캐싱하여 디스크 읽기와 서버 로드를 배제하면 이미지, html 문서, 동영상 등의 웹 리소스 검색과 관련된 대부분의 지연 시간을 크게 줄일 수 있다.
- 서버 측 웹 캐싱은 일반적으로 프론트에 위치한 웹 서버의 웹 응답을 보존하는 웹 프록시를 활용하여 로드 및 대기 시간을 효과적으로 줄임.
- 클라이언트 측 웹 캐싱에는 이전에 방문한 웹 콘텐츠의 캐싱된 버전을 유지하는 브라우저 기반 캐싱이 포함될 수 있음
클라이언트가 웹 사이트를 방문하면 브라우저가 이미지 및 웹 사이트 데이터와 같은 특정 리소스를 캐시라는 저장소에 저장해 놓는 것.
-
웹 브라우저에서 웹 사이트 리소스를 저장해 서버에서 다시 가져오지 않아도 됨
ex. 웹 사이트의 배경 이미지를 캐시에 로컬로 저장하면, 사용자가 해당 페이지를 두 번째로 방문할 때 이미지가 사용자의 로컬 파일에서 로드되므로 페이지가 훨씬 빠르게 로드
-
일반적으로 GET에 대한 응답만을 캐싱
-
브라우저는 Time To Live(TTL)라고 하는 지정된 기간 동안만 이러한 리소스를 저장
TTL이 만료된 후 사용자가 캐시된 리소스를 요청하면 브라우저는 서버에 다시 연결하여 리소스의 새 복사본을 다운로드해야 함
-
리소스를 보존하고 인터넷에서 사용자 경험을 향상시키는 좋은 방법이지만, 캐시 제어가 없으면 매우 취약
브라우저와 웹 서버는 각 리소스의 TTL을 어떻게 알 수 있을까?
HTTP 요청 및 응답에는 각각 헤더라고 하는 일련의 키값 쌍이 찍혀 있다.
이러한 헤더에는 각 통신에 대한 중요한 정보가 많이 포함되어 있고, 캐시 제어 헤더는 HTTP 요청과 응답 모두에 표시될 수 있다.
-
Cache-control
클라이언트가 동일한 웹 사이트를 다시 방문할 때, 리소스를 로컬 캐시에서 로드할 것인지 아니면 브라우저가 새로운 리소스에 대한 요청을 서버에 보내야 하는지 여부를 결정하는 규칙을 설정
-
Cache-Control: private응답은 클라이언트에서만 캐시할 수 있고, CDN이나 프록시와 같은 중개 에이전트에서는 캐시 불가능.
많은 경우가 개인 데이터가 포함된 리소스 -
Cache-Control: publicprivate과 반대로 리소스가 모든 캐시에 저장될 수 있음을 의미
이것은 HTTP 인증, 혹은 보통 캐시 가능하지 않은 응답 상태 코드를 지닌 페이지가 이제 캐시되어야 할 경우 유용 -
Cache-Control: no-store응답은 어디에도 캐시 불가능
클라이언트가 데이터를 요청할 때마다 새 복사본에 대한 요청을 원본 서버로 보내야 함을 의미
일반적으로 은행 계좌 정보와 같이 아주 중요한 데이터가 포함된 리소스용으로 예약되어 있음 -
Cache-Control: no-cache업데이트된 버전이 있는지 먼저 확인하지 않고는 요청된 리소스의 캐시된 버전을 사용할 수 없음을 의미
(이는 일반적으로 ETag를 사용하여 수행)📄 ETag
요청할 당시에 리소스 버전에 고유한 토큰이 포함되어 있는 또 다른 HTTP 헤더
이 토큰은 리소스가 업데이트될 때마다 원본 서버에서 변경 -
Cache-Control: max-age=<seconds>Time to Live(TTL), 즉 리소스가 다운로드된 다음 캐시에서 제공될 수 있는 시간(초)을 지정
-
한 명 이상의 사용자에 의해 재사용되는 응답을 저장하는 캐시
- 웹 프록시 서버를 통해 제공하는 캐시
- 조회가 많이 되는 리소스들은 몇 번이고 재사용되어 네트워크 트래픽과 레이턴시를 줄여줌