HTTP 캐싱 — 두 번째 요청은 왜 이렇게 빠를까

Cache-Control · ETag · 304 Not Modified · 강제 캐시(fresh)와 조건부 재검증(revalidation)

1. 캐시가 노리는 두 가지 낭비

• 왕복 시간(latency) — 서버가 서울, 나는 부산이면 요청·응답 한 번에 수십 ms. 이미지가 50개면 그게 쌓인다.
• 전송량(bandwidth) — 안 바뀐 2MB 이미지를 매번 다시 받는 건 순수 손해.

HTTP 캐시는 이 둘을 단계적으로 줄인다. 가장 센 방법은 “묻지도 말고 그냥 로컬 것 써”, 그다음은 “바뀌었는지만 물어보고, 안 바뀌었으면 본문은 받지 마”.

2. 신선도(freshness): 안 물어봐도 되는 시간

서버가 Cache-Control: max-age=60 을 주면, 브라우저는 그 응답을 받은 뒤 60초 동안은 “신선하다(fresh)” 고 보고 네트워크를 아예 건드리지 않는다. 이때 개발자 도구 Network 탭에 (disk cache), (memory cache) 라고 뜨고 시간은 0 ms에 가깝다.

60초가 지나면 캐시는 “상했다(stale)” 상태가 된다. 버리는 게 아니라, 다음 요청 때 서버에 “아직 유효해?” 하고 재검증한다(3절).

3. 데모 ①: 신선도 타이머와 캐시 HIT / MISS

아래는 브라우저가 logo.png 를 반복 요청하는 상황이다. [요청 보내기] 를 눌러 보라. 캐시가 fresh면 요청이 서버까지 가지 않고(HIT), stale이거나 비어 있으면 서버까지 간다(MISS / 재검증).

해 보기: max-age=10 으로 두고 빠르게 두 번 → 두 번째는 HIT(0 ms). 11초 기다렸다 다시 → stale이라 서버로 가지만 파일이 그대로면 304(본문 0 KB). 중간에 서버 파일 수정 후 요청하면 200(전체 전송).

4. 재검증(revalidation): "바뀐 것만 알려줘"

캐시가 stale이 되면 브라우저는 저장해 둔 검증자(validator) 를 요청 헤더에 실어 보낸다.

304 Not Modified 응답은 상태줄과 헤더뿐, 본문이 없다. 그래서 왕복 1번은 들지만 2MB 대신 몇백 바이트만 오간다. 그리고 브라우저는 기존 캐시의 신선도 타이머를 리셋한다.

5. 데모 ②: ETag 조건부 요청 직접 조립

왼쪽에서 요청을 만들고 [전송] 하면 서버가 어떻게 판단하는지 실제 헤더로 보여준다.

# 여기에 실제 요청/응답 헤더가 표시됩니다

6. 브라우저가 캐시를 쓰는 순서 (요약)

def fetch(url):
    entry = cache.get(url)

    # ① 저장된 게 있고 아직 신선하면 → 네트워크 0회
    if entry and entry.age < entry.max_age and not entry.no_cache:
        return entry.body          # HIT  (disk/memory cache)

    # ② 없거나 stale → 조건부 요청으로 재검증
    req = Request(url)
    if entry:
        req.headers["If-None-Match"]     = entry.etag
        req.headers["If-Modified-Since"] = entry.last_modified

    resp = network.send(req)

    if resp.status == 304:       # 안 바뀜: 본문 없음
        entry.refresh(resp.headers)  # 신선도 타이머 리셋
        return entry.body

    cache.store(url, resp)            # 200: 새 본문 + 새 헤더 저장
    return resp.body

7. 실무에서 자주 쓰는 조합