HTTP 캐시 동작 실험실
첫 GET/200 응답과 뒤따르는 GET 요청을 같은 캐시에 놓고 신선도와 재검증 경로를 계산합니다. 저장 가능 여부, Vary 키, Age, 조건부 헤더와 가상 304·200 결과를 단계별로 확인하세요.
주요 기능
- 개인/공유 캐시의 no-store·private·Authorization 저장 제한 구분
- Date·Age·max-age·s-maxage·Expires로 신선도와 경과 시간 계산
- Vary 대상 헤더와 URL 일치 여부로 재사용 후보 선택
- ETag·Last-Modified로 조건부 요청 생성, 304 메타데이터 일치 확인
- 고정된 신선·만료·저장 금지·Vary 불일치 예제를 네트워크 없이 실행
사용 방법
- 첫 GET 요청의 헤더, 200 응답 헤더와 응답 수신 UTC 시각을 입력합니다.
- 개인/공유 캐시를 고르고 다음 GET까지의 경과 초, 동일 URL 여부와 다음 요청 헤더를 입력합니다.
- 선택적으로 원 서버의 304 또는 200 응답과 304 검증 헤더를 설정합니다.
- 시뮬레이션을 실행해 저장·신선도·조건부 요청 및 타임라인 근거를 확인합니다.
활용 예시
- max-age=60 응답이 정확히 60초 지점에서 재검증되는 이유 확인
- Age가 이미 20초인 CDN 응답의 남은 신선도 계산
- 공유 캐시에서 private·Authorization 응답을 왜 저장하지 못하는지 검토
- Accept-Language가 바뀌어 Vary 캐시 항목과 일치하지 않는 상황 재현
자주 묻는 질문
실제 URL에 요청을 보내나요?
아닙니다. 입력한 헤더와 시간만 브라우저 메모리에서 계산합니다. CDN 설정, 서비스 워커, 브라우저별 정책과 실제 원 서버 응답은 확인하지 않습니다.
no-cache와 no-store는 같은가요?
아닙니다. 이 모델에서 no-store는 응답 저장을 막고, 응답 no-cache는 저장을 허용하되 재사용 전에 원 서버 검증을 요구합니다. 다음 요청의 no-cache도 신선한 저장본에 검증을 요구합니다.
Age와 Date는 어떻게 계산하나요?
수신 시 초기 age는 Age 헤더와 Date 대비 수신 시각 차이의 큰 값이며, 여기에 경과 초를 더합니다. 전송 지연·다단계 캐시의 세부 시각은 입력하지 않아 0으로 가정합니다.
304가 표시되면 실제로 서버가 바뀌지 않은 건가요?
아닙니다. 사용자가 304를 가정하고 동일한 ETag 또는 Last-Modified를 입력한 경우에만 저장 본문을 재사용할 수 있다고 표시합니다. 실제 원 서버의 응답을 받거나 304 전체 헤더 병합을 구현하지 않습니다.
어떤 캐시 규칙을 제외하나요?
GET/200 한 건과 뒤따르는 GET 한 건만 다룹니다. 휴리스틱 신선도, stale-while-revalidate, Range/206, 리다이렉트, 조건부 요청 선행 헤더, 브라우저 파티셔닝과 304 후 메타데이터 병합은 범위 밖입니다. 지원하지 않는 Cache-Control 지시문은 거부합니다.
개인정보 안내
입력은 현재 브라우저 탭 메모리에서만 처리하며 URL로 접속하거나 헤더를 업로드·저장하지 않습니다. Authorization이나 개인식별 값은 넣지 마세요. 조건부 헤더 미리보기에는 입력 ETag가 그대로 표시될 수 있습니다.
댓글과 질문