티스토리 뷰

Backend/꾸준히 TIL

HTTP 헤더 2 - 캐시와 조건부 요청헤더 & 프록시 캐시 & 캐시 무효화

개발하는 후딘 2025. 11. 24. 13:23

728x90

📝 강의출처: 모든개발자를 위한 HTTP 웹 기본지식 / 김영한

개발주제 블로그 스터디 포스팅: 1회차

캐시와 조건부 요청헤더

캐시제어 헤더

Cache-Control: 캐시제어
Pragma: 캐시제어(하위호환)
Expires: 캐시 유효기간(하위호환)

Cache-Control - 캐시제어 / 캐시 지시어(directives)

Cache-Control max-age: 캐시 유효시간, 초 단위
Cache-Control no-cache: 데이터는 캐시해도 되지만 항상 원(origin)서버에 검증하고 사용
- ETag와 Last-Modified 헤더를 이용하여 조건부 요청을 하여, 서버에 있는 데이터와 동일한지 서버한테 검증을한다. 서버 검증의 결과에서 304 NotModified 응답받으면, 로컬에 저장된 캐시데이터를 사용한다.
- 원서버(origin server): 캐시데이터를 검증할때, 중간서버(프록시서버)에 캐시데이터 검증을 하는게 아니라 데이터를 가지고 있는 서버에게 요청을 해야한다.
Cache-Control no-store: 민감한 정보의 데이터라면 캐시에 저장하면 안됨. (메모리에서만 사용하고 최대한 빨리삭제)
- 캐시는 하드디스크에 저장되는 편이다.

Pragma - 캐시제어 (하위호환)

Pragma: no-cache
HTTP 1.0 하위호환
하위호환은 현재에서는 사용하지 않음 - 옛날 버젼의 브라우저에서만 하위호환이 필요한경우만 사용

Expires - 캐시만료일 지정(하위호환)

캐시 만료일을 정확한 날짜로 지정
HTTP 1.0 부터 사용
더 유연한 Cache-Control: max-age 를 권장
- 초단위가 훨씬 유연함.
- Cache-Control: max-age 와 함께 사용하면 Expires는 무시
하위호환은 현재에서는 사용하지 않음 - 옛날 버젼의 브라우저에서만 하위호환이 필요한경우만 사용

프록시 캐시

현재 사용하고 있는 프록시캐시? ⇒ CDN(Content-Deliver-Network)과 aws cloudfront가 해당!

한국 사람들이 잘 안보는 외국 콘텐츠의 경우 빨리 못봄
한국 사람들이 자주보는 콘텐츠라면 빠르게 볼 수 있다.
글로벌 서비스에서 많이 활용된다.

프록시 캐시: 프록시 서버가 자주 요청되는 데이터의 사본을 저장하여 성능을 높이는 기술

웹콘텐츠에 대한 응답 속도를 빠르게 하여 원서버의 부하를 줄이는 역할
저장방식
- 메모리 캐시: 시스템 메모리에 저장하여 응답속도가 빠르지만 메모리 용량에 따라 크기 제한이 있다.
- 디스크 캐시: 디스크 스토리지에 저장하여 메모리 캐시보다 응답속도는 느리지만, 저장공간이 크기때문에 더 많은 데이터를 저장할 수 있다.

프록시 서버: 클라이언트와 서버 사이의 중개자 역할

보안 및 익명성: 사용자의 실제 IP주소를 숨겨 개인정보 보호에 기여한다.
접근제어: 특정 웹사이트 접근을 차단하거나 허용하는 정책을 적용할 수 있다.
로드밸런싱: 여러 서버로 요청을 분산시켜 부하를 줄인다. (리버스 프록시)
종류는 포워드프록시, 리버스 프록시가 존재한다.

포워드 프록시

클라이언트와 인터넷 사이에 위치하여 클라이언트의 요청을 대신 서버에 전달한다.
사용용도
- 캐싱: 자주사용되는 콘텐츠를 캐시하여 네트워크 성능을 향상시킨다.캐싱된 데이터에 대한 요청이 발생하면 원서버에 대한 부하가 감소하고 네트워크 병목현상도 감소할 것이다.
  - 클라이언트 입장에서 원서버에 비해 프록시 서버가 물리적으로 더 가까운 위치에 있다면 전송시간이 단축된다.
    자주사용되는 HTML, JS, CSS, 이미지와 같은 정적파일들을 원서버로부터 캐싱하고, 클라이언트가 요청할때 원서버로 요청하는대신 가지고 있는 캐시로 응답할 수 있다.
- 특정 콘텐츠 액세스 제한: 조직이나 기업 네트워크에서 특정 웹사이트로의 접근을 제한하거나 차단할 수 있다.
  - 사내망에서도 보안을 위해서 특정 웹사이트 접속을 차단할 수 있다.
    또한 아동이나 청소년에게 유해한 웹사이트를 프록시서버를 통해서 차단할 수 있다.
  - 내부망에 프록시서버를 두어 특정 컨텐츠에 대한 액세스를 제한할 수 있다.
- 익명성 및 보안: 실제 클라이언트의 IP주소를 숨기고 프록시 서버의 IP로 요청하므로 서버는 클라이언트의 실제 정보를 알 수 없다.
  - 클라이언트의 요청은 포워드 프록시 서버를 통과할때 암호화된다.
  - 암호화된 요청은 다른서버를 통과할때 필요한 최소한의 정보를 갖게되는데 이는 클라이언트 IP를 감춰주는 보안효과가 있다.
  - 모든요청이 프록시 서버를 통해 발생하므로 클라이언트의 IP가 노출되는 것을 원치 않을 경우에 사용된다.

리버스 프록시

원서버 직접 접근 - 거리가 멀수록 통신속도가 느리다. (원서버: 실제 데이터를 갖고있는 서버)

프록시 캐시(프록시 서버)가 중간에 있다면 - 원서버보다 가까우므로 프록시 캐시에서 불러온다. 만일 프록시캐시에도 없는 데이터를 요청해야된다면 그때는 프록시가 원서버에게 요청을 해야한다.

프라이빗 캐시: 웹브라우저나 로컬에 저장
퍼블릭 캐시: 공용으로 사용되는 캐시서버

캐시 무효화

캐시무효화 전략은 캐시된 데이터의 최신성(일관성)을 보장하고 오래된 데이터로 인한 문제를 방지하는 것을 목표로한다.

확실한 캐시 무효화 응답할 때 필요한 헤더들 (Pragma는 과거 브라우저에도 반영을 하기위해서)은 다음과 같다.

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache (HTTP 1.0 하위호환)

캐시지시어

Cache-Control: no-cache
데이터는 캐시해도 되지만, 항상 원서버에서 검증하고 사용
Cache-Control: no-store
데이터에 민감한 정보는 디스크 캐시에 저장하면 안됨. 메모리에서 사용하고 최대한 빨리 삭제
Cache-Control: must-revalidate
- 캐시 만료후 최초 조회시 원서버에 검증해야함
- 원서버 접근 실패시 반드시 오류가 발생해야함 504(Gateway Timeout)
- must-revalidate는 캐시 유효시간이라면 캐시를 사용함

Cache-Control: no-cache 기본동작

캐시데이터가 만료됐을때 다시 요청하려면캐시서버도 원서버에게도 데이터를 검증을 요청 해야한다.
즉 원서버가 검증을 해야한다.
클라이언트는 캐시서버에 요청하지만, 캐시서버가 바로 응답하는게 아니라 캐시서버도 원서버에게 데이터 검증을 요청해야한다. 반드시 원서버한테서 데이터 검증을 요청해야한다.

Cache-Control: no-cache VS Cache-Control: must-revalidate

그런데 만일 원서버로 접근이 불가능할때 no-cache와 must-revalidate의 차이점이 두드러진다.

no-cache의 경우는 원서버로 접근이 불가능하여 데이터검증을 할 수 없다면 프록시 캐시에서 저장된 데이터로 응답하도록 한다.

반면 must-revalidate는 반드시 원서버에서 검증을 거쳐야하므로 504(Gateway Timeout) 에러를 발생한다.