캐시(Cache)

HTTP 캐시는 웹 성능 최적화의 핵심이다.
같은 리소스를 매번 서버에서 내려받지 않고, 클라이언트나 중간 프록시 서버가 저장한 데이터를 재사용하는 구조이다.

1. 캐시가 필요한 이유

•	네트워크 비용 절약
•	서버 부하 감소
•	웹 페이지 로딩 시간 단축
•	사용자 경험 개선

2. Cache-Control 주요 옵션

1) max-age

Cache-Control: max-age=60

• 캐시가 60초 동안 유효하다는 의미
• 유효 시간 동안은 네트워크 요청 없이 캐시 데이터를 바로 사용

2) no-cache

Cache-Control: no-cache

• 데이터를 캐시할 수는 있음
• 하지만 사용하기 전 반드시 원 서버에 검증(ETag)해야 함

저장은 가능하지만 검증 없이 사용은 불가.

3) no-store

Cache-Control: no-store

• 아예 저장조차 하지 않음
• 보안성 높은 데이터(개인정보, 금융 데이터 등)에 필수

4) Expires

Expires: Mon, 01 Jan 2025 00:00:00 GMT

• 캐시 만료 시간(절대 시간) 지정
• HTTP/1.1에서는 Cache-Control이 우선순위 더 높음

3. Last-Modified / If-Modified-Since

Last-Modified

Last-Modified: 2024-12-01 00:00:00 GMT

서버가 리소스가 마지막으로 변경된 시점을 알려줌.

If-Modified-Since

클라이언트가 다음 요청 때:

If-Modified-Since: 2024-12-01 00:00:00 GMT

서버가 변경된 내용이 없으면…

→ 304 Not Modified 응답
→ 캐시 데이터 재사용

4. ETag / If-None-Match (더 정교한 캐싱)

파일 해시 기반으로 변경 여부 판단.

서버:

ETag: "abc123"

클라이언트:

If-None-Match: "abc123"

변경 없음 → 304 Not Modified

5. 프록시 캐시

• 브라우저 캐시 → private 캐시
• 프록시(중간 캐시 서버) → public 캐시

public 캐시 허용:

Cache-Control: public

개인별 캐시만 허용:

Cache-Control: private

s-maxage
프록시 캐시만 별도 캐싱 시간 지정

Cache-Control: s-maxage=120

6. 캐시를 완전히 막고 싶을 때

로그인 정보나 중요한 페이지는 캐시되면 안 된다.

Cache-Control: no-cache, no-store, must-revalidate

7. no-cache 동작 예시

1.	클라이언트 요청 (no-cache + ETag 포함)
2.	캐시 서버는 원 서버에 검증 요청
3.	서버가 304 Not Modified 응답
4.	캐시 서버는 저장해둔 데이터 재사용

검증 후 캐시 사용 구조이다.