반응형
웹 브라우저 캐시의 개념과 작동 원리 상세 설명
웹 브라우저 캐시는 웹사이트의 정적 리소스(HTML, CSS, JS, 이미지 등)를 로컬 디스크에 저장함으로써, 동일한 리소스에 대한 불필요한 네트워크 요청을 줄이고, 웹사이트 로딩 속도를 높이기 위한 핵심 기술입니다.
캐시의 주요 목적
- 페이지 로딩 속도 향상: 사용자는 동일한 리소스를 다시 다운로드하지 않고 로컬에서 불러올 수 있으므로 속도가 빨라집니다.
- 서버 트래픽 감소: 중복 요청이 줄어들어 서버 부하가 감소합니다.
- 모바일 네트워크 비용 절감: 사용자 측 데이터 사용량도 줄어듭니다.
웹 브라우저 캐시의 동작 구조와 흐름
1. 최초 요청 시
- 사용자가 웹사이트에 처음 접속하면, 브라우저는 서버로 HTML, CSS, JS 등 각종 리소스를 요청합니다.
- 이때 서버는 응답 헤더에 Cache-Control, ETag, Last-Modified, Expires 등의 정보를 포함시켜 브라우저가 이 리소스를 캐싱할 수 있는 조건을 전달합니다.
2. 브라우저의 캐시 저장
- 브라우저는 리소스를 다운로드한 후, 로컬 디스크에 캐시 파일을 저장하고,
- 저장 경로: 일반적으로 운영체제의 사용자 디렉토리 내부에 브라우저 전용 디렉토리가 존재합니다.
- 저장 대상: JS, CSS, 이미지 파일, 폰트 등
3. 재접속 시 처리 흐름
- 브라우저는 URL을 요청하기 전에, 로컬 캐시에 저장된 리소스를 먼저 확인합니다.
- 캐시 유효 조건에 따라 다음 2가지 방식 중 하나로 처리됩니다:
1) Fresh 캐시 (유효함)
- Cache-Control: max-age=31536000 등으로 설정된 만료 시간이 남아있는 경우
- 브라우저는 서버에 요청을 보내지 않고, 로컬 캐시만 사용합니다. (0 RTT 응답)
2) Stale 캐시 (만료됨)
- 브라우저는 조건부 요청(Conditional Request)을 서버에 전송하여 유효성 검사를 요청합니다.
- If-None-Match: "etag값" → 서버는 ETag와 비교
- If-Modified-Since: 날짜 → 서버는 Last-Modified와 비교
- 서버 응답:
- 변경 없음 → 304 Not Modified와 함께 본문 없이 응답 (브라우저는 기존 캐시 사용)
- 변경됨 → 새 리소스를 다운로드하고 캐시 갱신
HTTP 캐시 관련 헤더 상세 정리
Cache-Control (HTTP 1.1)
- max-age=초: 캐시 유효 시간
- no-cache: 캐시에 저장되긴 하지만 매 요청마다 서버 확인 필요
- no-store: 절대 저장 금지 (보안 데이터 등)
- public: 공유 캐시(프록시)도 저장 가능
- private: 브라우저 개인 캐시에만 저장 가능
Expires (HTTP 1.0)
- 리소스의 만료 시점을 명시 (절대 시간)
- Cache-Control이 함께 존재하면 무시됨
ETag
- 리소스의 고유 식별자 (서버가 리소스마다 생성한 해시값 등)
- 브라우저는 이를 저장하고, 서버에 조건부 요청 시 비교
Last-Modified
- 리소스 최종 수정 시각
- If-Modified-Since 요청 헤더와 짝을 이룸
실무에서의 캐시 활용 전략
1. 정적 리소스 캐싱
- Cache-Control: max-age=31536000, immutable 등의 헤더로 장기 캐싱 설정
- JS, CSS 파일은 빌드 시 해시값 포함 (e.g., main.abc123.js) → 변경 시 캐시 무효화
- HTML 문서는 일반적으로 no-cache로 설정 (실시간 콘텐츠 반영 필요)
2. 캐시 무효화(Cache Busting)
- 파일명에 버전 또는 해시 포함 (Webpack, Vite 등에서 자동 처리)
- URL 쿼리 스트링 사용: main.js?v=2.0.1
3. API 응답 캐싱
- 실시간 데이터가 아닌 경우, API 응답에도 ETag 또는 Cache-Control을 포함하여 네트워크 효율 개선
- 예: 상품 목록, 공지사항 등 빈번히 바뀌지 않는 데이터
4. SSR (Server Side Rendering)과 캐싱
- Cache-Control: public, max-age=60 → 사용자의 첫 요청에 대해 SSR 결과를 공유 캐시 서버(예: CDN)에서 60초간 재사용
- 서버와 CDN 사이에서도 stale-while-revalidate 정책을 적용 가능
고급 캐싱 전략
1. Lazy Update 캐싱 (Stale-While-Revalidate)
- 사용자에게는 기존 캐시 데이터를 즉시 제공하면서, 백그라운드에서 최신 데이터를 요청하여 캐시를 갱신합니다.
- Cloudflare, Fastly, Vercel 등 CDN에서 지원됨
2. Service Worker 기반 캐싱
- 브라우저 내에서 개발자가 직접 캐시 전략을 제어 가능
- 오프라인 지원 및 복잡한 캐싱 시나리오 구현 가능
- 예: Cache First, Network First, Stale While Revalidate 등 전략 구성 가능
요약
- 웹 브라우저 캐시는 성능 최적화의 핵심 도구이며, HTTP 헤더를 통해 정교하게 제어할 수 있습니다.
- 정적 리소스는 장기 캐싱 + 파일명 해시, 동적 콘텐츠는 조건부 요청 + ETag/Last-Modified 방식으로 전략을 나누는 것이 실무의 기본입니다.
- Lazy Update나 Service Worker를 활용하면 복잡한 캐싱 요구사항도 처리할 수 있습니다.
- 면접 질문으로 자주 등장하는 포인트는 Cache-Control 헤더 조합, ETag의 조건부 요청 동작, 캐시 무효화 전략입니다.
반응형
'CS 공부일지 > 네트워크 공부일지' 카테고리의 다른 글
웹 브라우저 저장소 총정리: 쿠키, 세션스토리지, 로컬스토리지의 차이점 (0) | 2025.04.13 |
---|---|
LocalStorage vs 캐시 vs 오리진 정책: 웹 저장소와 보안 핵심 (0) | 2025.04.12 |
TLS 핸드셰이크: 데이터 보안을 위한 필수 과정 (0) | 2025.04.12 |
HTTPS와 TLS의 차이점 및 보안 기능 (0) | 2025.04.12 |
HTTP/2와 HTTP/3의 차이점: 성능 및 보안 차이 분석 (0) | 2025.04.11 |