컴퓨터 공학에서 캐시(Cache)는 “자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 저장소” 라고 정의 한다. 캐시는 원본 데이터에 접근하는 시간을 절약하여, 데이터를 불러오는 속도를 높이기 위해 사용하는 것이다.
웹 에서의 캐시(Cache)도 일반적으로 다르지 않다. 웹 통신의 성능을 향상 시켜주기 위해 사용한다. 웹에서 사용되는 HTTP Cache 에 대해 자세히 알아보자
HTTP Cache❓
웹(WEB)은 클라이언트(웹 브라우저)와 웹 서버가 서로 요청과 응답을 주고 받는 것의 연속이라고 할 수 있다.
그렇기에 웹의 성능은 요청을 보냈을 때, 얼마나 빠르게 응답을 받을 수 있느냐에 따라 결정된다고도 할 수 있다.
웹에서 사용하는 캐시(Cache)를 “HTTP Cache“ 라고 한다.
HTTP Cache를 사용하여 이전에 가져왔던 Resource(이미지, 영상 등)를 재사용 함으로 성능을 향상 시켜줄 수 있다.
어떤 문제를 해결할까?
⚠️ 매번 요청에 따른 웹 브라우저와 웹 서버의 부하
웹 브라우저는 같은 상황에 대해서도 매번 웹 서버에게 요청해서 결과를 받아와야 한다.
그리고, 해당 요청에 대해 웹 서버 는 매번 웹 브라우저의 요청에 대해 결과를 만들고, 응답을 보내줘야 한다.
게다가 여러 클라이언트에서 하나의 웹 서버에 같은 요청을 무수히 반복해서 많이 보내게 되면 웹 서버는 과부하로 지쳐버리게 될 것이다.
군대에서 삽질하던 추억을 한번 생각해보라…
그래서 웹 브라우저와 웹 서버는 생각했다.
“똑같은 걸 왜 귀찮게 계속 다시 받아와야해??”
⚠️ 웹 페이지 로드 성능 개선
이러한 반복적으로 보내는 요청의 크기가 작다면 상관이 없을 수 있겠지만, 크기가 큰 요청을 계속 반복적으로 하다보면 웹 브라우저나, 웹 서버나 힘들 수 밖에 없어진다.
이것은 웹 페이지의 성능에 아주 밀접한 영향을 미치게 된다.
크기가 큰 요청을 보내게되면, 네트워크 환경에 따라 결과를 받아오기까지 오랜 시간이 걸리게 될 수 있다.
요청을 보내고, 응답을 하기까지 오래 걸리게 되면, 사용자 입장에서 웹 페이지가 늦게 로드 되는 경험을 하게 될 수 밖에 없다.
또한 이것은 웹 서버 입장에서도 할 이야기가 많아진다.
웹 브라우저와 웹 서버의 각자의 입장을 살펴보자.
“웹 브라우저 “ : 결과 “반환” 비용(시간, 네트워크)를 줄이자
if ( 웹 브라우저는 매번 똑같은 100MB 짜리 고양이 영상을 웹 서버로부터 받아온다면… )
- 네트워크 트래픽 및 비용 발생 문제
- 100MB 다운로드 완료까지 긴 대기시간 후에야 시청 가능 문제
이전에 받았던 100MB 짜리 고양이 영상을 재사용한다면?
- 네트워크 트래픽 및 비용 감소
- 100MB 다운로드 완료의 긴 대기시간 없이 바로 시청 가능 = 유저 경험 증진
“웹 서버” : 결과 “생성” 비용(노동, 자원)를 줄이자
if ( 웹 서버는 매번 똑같은 100MB 짜리 고양이 영상을 만들어서 웹 브라우저에게 보내준다면 )
- 수백,수천개의 요청에 대한 반복 연산
- 반복적인 서버자원(CPU, Memory)을 과도하게 소비 문제 발생
이전에 만들어놓았던 100MB 짜리 고양이 영상을 재사용한다면?
- 불특정 다수의 웹 브라우저에게도 캐시된 자원 제공 가능
- 반복적인 서버자원(CPU, Memory)이 필요 없이, 여유가 생김
- 수백,수천개의 요청을 간단히 처리 가능
그래서 웹 브라우저와 웹 서버는 반복되는 요청에 대해 부담을 나누기 위해 “HTTP 캐시(Cache)” 라는 개념을 도입했다.
HTTP Cache는 다시 생각해보면 웹 브라우저와 웹 서버 사이 임시 중간 저장소 라고 할 수 있다.
HTTP Cache에 재활용하려는 Resource를 임시로 저장해두었다가 같은 요청에 대해 다시 재사용함으로 성능을 높이고 과부하의 문제를 조금이나마 해결하게 되었다.
HTTP Cache 종류
HTTP Cache는 크게 임시로 저장하는(캐싱한) 데이터를 “누가 필요로 하는가”에 따라 나눌 수 있다.
해당 데이터를 특정된 한명을 위한(Private) 것인지, 불특정 다수(Public)를 위한 것인지 구분하여 Cache를 사용한다.
사설 캐시 (Private Cache) : 웹 브라우저
“한 명의 사용자만 사용하는 캐시”
브라우저에 저장되는 캐시로, 브라우저 캐시(Cache)라고도 한다.
한번 웹 서버에 요청을 보내 응답을 받으면, 해당 요청을 웹 브라우저 캐시 저장소에 저장해둔다. 그리고 일정 기간동안 추가적인 요청없이 다시 똑같은 요청을 보내지 않고, 사용할 수 있도록 해준다.
브라우저 캐시는 웹 서버에서 보낸 응답 header를 통해 제어된다.
→ 웹 서버 : “웹 브라우저 너가 저장해”
공유 캐시 (Shared Cache) : 웹 브라우저와 웹 서버 사이에 위치
“한 명 이상의 사용자가 재사용할 수 있도록 응답을 저장하는 캐시”
“이 외에도 게이트웨이 캐시, CDN, 리버스 프록시 캐시 그리고 로드 밸랜서 등 더 다양한 캐시가 있다.”
HTTP Cache의 동작 원리
캐시는 임시(반영구적) 저장을 위한 전략이자 실시간을 아예 포기하자는것이 아닌 준실시간을 보장하는 정책이다.
- 준실시간 : 캐시해놓은 데이터가 너무 오래된 데이터가 되지 않도록 특정 주기에 따라 재검증을 해주어야한다.
- 재검증 : 캐시한 데이터의 원본 주인인 웹 서버가 설정한 특정 주기에 따라, 캐시한 데이터가 오래됐는지 검증
- 검증 방법 : 조건부 요청 사용 = 재검증 기준이 되는 값을 서버에게 보낸다.
HTTP Cache 재검증 기준
1. Last-Modified : 수정일(시간) 기반
2. ETag : 고유값(해시) 기반
HTTP Cache 제어
“Cache-control 헤더를 통한 세부 설정”
[Cache-Control](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Cache-Control) HTTP/1.1 기본 헤더 필드는 요청과 응답 양측 모두에 있어 캐싱 메커니즘을 위한 디렉티브를 지정하는데 사용됩니다. 이 헤더 필드가 제공하는 여러 디렉티브들로 캐싱 정책을 정의하고자 한다면 이 헤더를 사용하시기 바랍니다.
Cache-Control: no-store
Cache-Control: private
Cache-Control: public
Cache-Control: max-age=31536000
Cache-Control: must-revalidate정리 : HTTP Cache 이점
- 웹 서버 입장에서
- 웹 서버 부하 완화
- 반복 연산 감소 : 웹 서버가 동적 웹 페이지를 생성하는 연산을 하지 않아도 된다 ← 캐시가 반환
- 트래픽 분산 : 웹 서버가 모든 요청 트래픽을 받아내지 않아도 된다 ← 캐시가 일부 트래픽 분담
- 부분 DDoS 방어
- 웹 서버 부하 완화
- 웹 브라우저 입장에서
- 네트워크 트래픽 감소 (레이턴시 및 네트워크 대역폭 사용 감소)
- 유저 경험 증진
참고
