개요
- 1차적으로는 http 헤더 옵션보고 브라우저가 디스크 캐싱 (200 from memoery or disk cache)하고 2차적으로는 서버에서 304 Redirect로 로 대응
- 리소스가 캐시 내에 저장되고 나면, 이론적으로는 영원히 캐시에 의해 서비스될 수도 있습니다. 캐시는 유한한 저장 공간을 가지므로 아이템들은 주기적으로 스토리지에서 제거됩니다. 이런 과정을 캐시 축출(cache eviction)이라고 부릅니다. 반면 어떤 리소스들은 서버 상에서 변경될 수 있고, 캐시가 갱신되어야 합니다. HTTP가 클라이언트-서버 프로토콜이므로, 리소스가 변경됐을 때 서버는 캐시와 클라이언트에 접근할 수 없습니다; 서버는 리소스에 대한 만료 시간을 알려줄 수밖에 없습니다. 만료 시간 이전에는, 리소스가 유효(fresh)합니다; 만료 시간 이후의 리소스는 실효(stale)됩니다. 축출 알고리즘은 대개 실효된 리소스보다 유효한 리소스에 특권을 부여합니다. 실효된 리소스는 축출되거나 무시되지 않는다는 것을 알아두시기 바랍니다; 캐시가 실효된 리소스에 대한 요청을 받은 경우, 이 리소스가 실제로 아직 유효한지 아닌지를 확인하기 위해 If-None-Match (en-US)와 함께 요청을 전달합니다. 만약 그렇다면, 서버는 요청된 리소스 본문을 전송하지 않고 304 (Not Modified) 헤더를 돌려보내 대역폭을 절약합니다.
캐시의 생명주기
- Cache-Control 헤더에 따라서 결정된다
max-age
max-age=초- 유효 시간 전에는 서버에 요청 보내지 않고
브라우저 안의 디스크나 메모리 캐시 사용
- Expires 헤더로도 캐시 유효시간 표현 가능
- "max-age" 혹은 "s-max-age" 있으면 무시된다
- 한번 브라우저에 캐싱되면 서버가 지우기는 쉽지 않다
유효시간이 지난 이후는 재검증
- 유효기간이 지나면 재검증, 재검증 결과 브라우저가 가지고 있는 캐시가 유효하다면, 서버는 [304 Not Modified] 요청
- [304 Not Modified] 요청은 http 본문을 포함안해서 엄청 빠르다
- 재검증 request 헤더들
- 재검증은 response로 온 ETag 와 Last-Modified 값을 사용한다
- If-None-Match
- 캐시된 리소스의 ETag 값과 현재 서버 리소스의 ETag 값이 같은지 확인
- If-Modified-Since
- 캐시된 리소스의 Last-Modified 값 이후에 서버 리소스가 수정되었는지 확인
max-age=0이면 재검증을 해야하지만 일부 모바일 브라우저는 웹 브라우저 끄기 전까지 리소스를 만료안하는 경우가 있다 -> 이런 경우 필요하다면 no-store옵션 사용
no-cache와 no-store 옵션
private과 public 옵션