웹의 본질에 따라 WB<->WS(혹은 WAS,통칭) 은 요청<->응답 을 한다. 이 과정에서 몇가지 이슈가 있는데 이번 포스팅에서는 첫번째, 웹 서버의 부하 및 조회 성능 개선을 다뤄보겠다. 🚗 💨 💨
WB에서 WS로 요청을 보내고 WS에서 결과를 생성하는 도식도는 다음과 같다. 생성과 전송에 각 3초씩 쓰여 WB는 총 6초후 응답을 받게 된다. 이때, 시간 뿐 아니라 네트워크 자원도 사용하게 된다.

만약 동일한 요청에 대한 동일한 응답을 매번 위와 같이 생성하여 반환한다고 생각해보자. 비용과 자원을 모두 낭비하여 매우 비효율적일 것이다. 결론적으로

중간 저장소인 캐시를 사용하면 WS입장에서는 매번 생성 후 반환하지 않아도 되서 1번 문제를 완화시킬 수 있고, WB입장에서는 그 시간동안 기다리지 않아도 되니 2번 문제가 개선된다.
WB와 WS 사이 중간 임시 저장소이다. 캐시에 이전에 생성된 결과 즉, 재활용하려는 동적 웹 페이지 결과를 저장한다. 유식한 말로, WB와 WS 사이에 HTTP Cache를 놓고, 그곳에 재활용하려는 HTTP Resource 결과를 저장한다.
캐시는 일시적 저장소이기 때문에 목적에 맞게 활용해야 한다.
개별 WB에 종속되어, 해당 사용자만을 위한 데이터를 저장한다. 로그인 정보, 개인화 설정 등 사용자 맞춤형 데이터가 이에 해당한다.
☑️ Disable cache

✅ Disable cache

캐시를 비활성화하면 서버는 항상 최신 데이터를 제공해야 하므로 네트워크 지연이 발생할 수 있다.
WB-WS 사이에 있어, 모든 웹 브라우저 유저 다수를 위한 것. 이는 HTTP Cache 헤더로 제어하는지 직접하는지에 따라 프록시 캐시와 관리형 캐시로 나뉜다.
(1) proxy cache

Cache-Control로 (HTTP Cache 헤더)를 통해 제어한 경우이다.
(2) 관리형 캐시
개발자가 직접 어떤 데이터들을 캐싱할지 업로드, 삭제, 배포 및 제어한다.
웹 브라우저와 서버 간의 반복적인 데이터 요청은 서버 부하와 응답 지연을 일으킨다. 캐시는 이러한 문제를 줄이기 위해 사용되는데, 한 번 받은 데이터를 저장해 빠른 재사용을 가능하게 한다. Private Cache는 사용자 맞춤형 데이터를, Shared Cache는 여러 사용자에게 공통된 데이터를 캐싱한다. Cache-Control 헤더는 캐시된 데이터의 관리를 위해 HTTP 통신에서 사용된다. 캐시는 웹의 성능을 향상시키고 자원 사용을 최적화하는 데 중요한 역할을 한다.