no-cache면 저장하지 않을까? HTTP 캐시와 304

About this offer

화면을 새로고침했는데 개발자 도구에 304 가 보입니다. 본문을 다시 받지 않았다고 무조건 서버에 요청하지 않은 것은 아닙니다. 이번에는 저장, 재사용, 재검증 을 각각 나눠보겠습니다. 세 동작을 구분하기 저장은 응답을 캐시에 보관하는 일입니다. 재사용은 그 응답으로 다음 요청을 처리하는 일입니다. 재검증은 서버에 기존 응답이 여전히 유효한지 확인하는 일입니다. 이 구분과 지시자의 의미는 HTTP Caching RFC 9111 에서 확인할 수 있습니다. 그림은 저장 가능한 GET 응답의 기본 흐름입니다. 모든 상태 코드와 공유 캐시의 예외를 나타내지는 않습니다. 응답 지시자 핵심 의미 max-age=60 신선도를 판단하는 수명 기준 60초 no-cache 보관할 수 있지만 성공적인 재검증 없이 재사용하지 않음 no-store 해당 요청·응답에 대해 캐시가 저장하지 않도록 지시 private 공유 캐시는 저장하지 않음. 개인 캐시와 구분 ETag로 다시 확인하는 예시 서버가 응답에 ETag: "v1" 을 붙였다고 가정하겠습니다. 다음 요청은 If-None-Match: "v1" 로 현재 표현이 같은지 물을 수 있습니다. 조건이 맞으면 304 Not Modified 를 받아 저장된 본문을 재사용하고, 응답 헤더도 규칙에 맞게 갱신합니다. RFC 9111의 검증 const decide = (clientTag, serverTag) => clientTag === serverTag ? 304 : 200; console.log(decide('"v1"', '"v1"')); console.log(decide('"v1"', '"v2"')); 출력은 304 , 200 입니다. 태그 비교 분기만 검증한 단순 모형입니다. 실제 HTTP 구현은 메서드, 여러 태그, 약한 비교와 다른 조건부 요청 규칙도 처리해야 합니다. 네트워크 서버를 시험한 코드는 아닙니다. 캐시는 응답 하나만 보고 끝나지 않는다 요청의 인증 정보, Vary , 공유 캐시 여부와 저장 가능 조건을 함께 확인해야 합니다. 사용자별 응답을 공용으로 재사용하면 문제가 됩니다. 또 no-store 를 붙였다고 이미 모든 곳에 저장된 과거 복사본이 삭제되는 것은 아닙니다. “캐시를 껐다”보다 어느 계층에서 무엇을 금지했는지 설명하는 편이 정확합니다. 확인 문제 no-cache 는 저장 금지와 같은 말일까요? 304 라면 서버와 통신하지 않았다는 뜻일까요? 서버의 태그가 "v3" 로 바뀌면 위 모형의 결과는 무엇일까요? 답과 해설 아닙니다. 성공적인 재검증 없이 재사용하지 말라는 의미입니다. 아닙니다. 조건부 요청에 대한 서버 응답일 수 있습니다. 기존 클라이언트 태그와 다르므로 200입니다. 실제 응답 본문과 헤더 처리도 필요합니다. 오늘은 저장·재사용·재검증을 각각 한 문장으로 설명해보겠습니다. 내일은 개인 캐시와 공유 캐시를 나누고, 일주일 뒤에는 DNS TTL과 HTTP 신선도가 관리하는 대상을 비교해보면 좋겠습니다. 자료 확인 기준: RFC 9111, 2026-10-04. 코드의 출력은 모형 검증이며 실제 캐시 서버의 보안·성능 시험이 아닙니다. 예제 검증 환경: Node.js v24.13.1.

Offer details

Provider

velog

Source

velog-rss

Score

54.39

Confidence

49%