캐시가 없을 때
- 데이터가 변경되지 않더라도 네트워크를 통해 지속적으로 데이터를 다운로드해야 합니다.
- 인터넷 네트워크는 매우 느리고 비쌉니다.
- 브라우저가 느리게 로드됩니다.
- 느린 사용자 경험
적용된 캐시
- 요청이 들어오면 서버에서 캐시 제어:최대 연령=60 다음과 같이 캐시가 유효한 시간을 지정합니다.
- 응답 결과를 브라우저 캐시에 저장(60초 이내 유효)
- 2차 요청 들어오면 캐시 만료 시간 확인 후 유효한 경우 캐시에서 조회(네트워크 x 필요)
- 캐싱 덕분에 캐시 가능한 시간 동안 네트워크를 사용할 필요가 없습니다.
- 비용이 많이 드는 네트워크 사용량을 줄일 수 있습니다.
- 브라우저가 매우 빠르게 로드됩니다.
- 빠른 사용자 경험
- 3번째 요청이 들어오면 유효기간이 만료됩니다. 캐시 시간 초과만약 그러하다면?
- 응답 결과를 다시 캐시에 저장합니다.
- 캐시의 유효 기간이 초과되면 서버에서 데이터를 검색하고 캐시를 업데이트합니다.
- 이때 네트워크 다운로드가 다시 발생했습니다.
- 그러나 클라이언트가 보유한 데이터와 서버가 보유한 데이터가 변경되지 않은 경우 동일합니까?
캐시 시간 초과
- 캐시 만료 시간이 초과되어 다시 서버에 요청하면 다음 두 가지 상황이 발생합니다.
- 서버의 기존 데이터 변경 → 캐시 다시 조회 및 업데이트
- 서버의 기존 데이터는 변경되지 않습니다.
- 캐시된 데이터가 변경되지 않았는지 확인할 수 있어야 합니다. → 확인 헤더 추가
인증 헤더
- 서버 → 브라우저 전송 및 브라우저 캐시에 저장
- 캐시에 (마지막 변경: 2020년 10월 11일 10:00:00) 저장됨 (인증 헤더)
조건부 요청
- 캐시 시간 초과(수정된 경우: 2020년 11월 10일 10:00:00) 발송 (조건부 요청)
- 고쳐지지 않는다면? → 본문 없이 헤더만 보내기 → 용량을 대폭 줄일 수 있습니다!
정리하다
- 캐시 만료일 이후에도 서버의 데이터가 업데이트되지 않은 경우,
- 304 Not Modified + 헤더 메타 정보 전용 응답(BodyX)
- 클라이언트는 서버에서 보낸 응답 헤더 정보로 캐시 메타 정보를 업데이트합니다.
- 클라이언트가 캐시된 데이터 회수
- 결과적으로 네트워크 다운로드가 발생하지만 작은 헤더만 발생합니다.
- 매우 실용적인 솔루션
헤더 및 조건부 요청 유효성 검사
- 인증 헤더
- 캐시된 데이터와 서버 데이터가 동일한 데이터인지 확인
- 마지막 변경, 상표
- 조건부 요청 헤더
- 유효성 검사 헤더가 있는 조건 분기
- If-수정된 이후 : 마지막 수정 시간 사용
- 일치하지 않는 경우 : Etag 사용
- 200 조건이 충족되면 OK
- 304 조건이 충족되지 않으면 수정되지 않음
If-Modified-Since : 이후에 데이터가 수정되었습니까?
- 데이터 변경 예
- 캐시: 2020년 11월 10일 10:00:00 & 서버: 2020년 11월 10일 10:00:00
- 304 Not Modified, 헤더 데이터만 전송(BODY 없음) → 304: 리디렉션(= 캐시로 이동)
- 전송용량 0.1M(헤더 0.1M, 바디 1.0M)
- 데이터 변경 예
- 캐시: 2020년 11월 10일 10:00:00 및 서버: 2020년 11월 10일 11:00:00
- 200 OK, 모든 데이터 전송(BODY 포함)
- 전송용량 1.1M(헤더 0.1M, 바디 1.0M)
Last-Modified, If-Modified-Since 단점
- 1초 미만(0.x초) 단위로 캐시 튜닝을 할 수 없습니다.
- 날짜 기반 논리 사용
- 데이터 수정 날짜는 다르지만 동일한 데이터를 수정한 결과가 동일한 경우(A→B→A)
- 서버에서 별도의 (임의) 캐싱 로직을 관리하고 싶은 경우
- ex) 공백이나 주석과 같은 사소한 변경에 의해 영향을 받지 않고 캐시를 유지하려는 경우.
Etag, 일치하지 않는 경우
- 엔터티 태그(Etags)
- 캐시된 데이터에 대한 임의의 고유한 버전 이름
- 예) Etag: “v1.0”, Etag: “a2jiodwjekjl3” (파일에 해시 추가)
- 데이터가 변경되면 이름을 변경하여 변경(Hash 재생성)
- 예) Etag: “aaaaa” → Etag: “bbbbb”
- Etag를 보내고, 같으면 보관하고, 같지 않으면 다시 가져가는 정말 간단한 방법입니다(날짜보다 훨씬 편리함)
정리하다
- 정말 간단합니다. ETag를 서버로 보내고, 같으면 보관하고, 다르면 다시 받아오면 됩니다.
- 서버에서 완전히 관리하는 캐시 제어 로직
- 클라이언트는 이 값을 서버에 제공할 뿐입니다(클라이언트는 캐싱 메커니즘을 인식하지 못함).
- 전임자)
- 오픈 베타 기간 3일 동안 파일이 변경되더라도 서버는 ETag를 변경하지 않고 유지합니다.
- 모든 ETag는 애플리케이션 배포 주기에 따라 업데이트됩니다.
캐싱 및 조건부 요청 헤더
- 캐시 제어 : 캐시 제어
- Pragma : 캐시 제어(역호환성)
- 만료: 캐시 유효 기간(하위 호환성)
캐시 제어
- 캐시 제어: 최대 연령
- 캐시 유효 시간(초)
- 캐시 제어: 캐시 없음
- 데이터는 캐싱될 수 있지만 항상 검증되고 원본 서버와 함께 사용됩니다.
- 캐시 제어: 스토리지 없음
- 데이터에는 민감한 정보가 포함되어 있으므로 저장해서는 안 됩니다.
- (메모리에서 사용하고 가능한 한 빨리 삭제하십시오)
실용주의
- Cache-Control(이전 버전과 호환)
- 프라그마: 캐시 없음
- HTTP 1.0과 하위 호환 → 거의 사용되지 않음
만료됨
- 캐시 만료 날짜를 정확한 날짜로 설정(하위 호환성)
- 만료: 1990년 1월 1일 월요일 00:00:00 GMT
- HTTP 1.0부터 사용
- 이제 더 유연한 캐시 제어: max-age 권장
- Cache-Control: max-age와 함께 사용하면 만료가 무시됩니다.
정리하다
- 유효성 검사기 헤더
- ETag: “v1.0”, ETag: “asid93jkrh2l”
- 마지막 수정: 2020년 6월 4일 목요일 07:19:24 GMT
- 조건부 요청 헤더
- If-Match, If-None-Match: Etag 값 사용
- If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용
프록시 캐시
- 서버에 직접 액세스
- 원본 서버
- 프록시 캐시 서버에 대한 액세스(공용 캐시) 로컬 또는 웹 브라우저에 저장된 캐시(개인 캐시)
- 한국 어딘가…
- 프록시 캐시 서버 – 미국의 원본 서버
캐시 제어/캐시 지시어 – 기타
- 캐시 제어: 공개
- 응답은 공개 캐시에 저장될 수 있습니다.
- 캐시 제어: 비공개
- 응답은 해당 사용자에게만 해당됩니다. 개인 캐시에 저장해야 함(기본값)
- 캐시 제어: s-maxage
- max-age는 프록시 캐시에만 사용됩니다.
- 연령: 60세(HTTP 헤더)
- 원본 서버 응답 후 프록시 캐시에서 소요된 시간(초)
캐시 무효화
캐시 제어/보장된 캐시 무효화 응답
| 캐시 제어: 캐시 없음, 스토리지 없음, 재검증해야 함 프라그마: 캐시 없음 |
- 캐시 제어: 캐시 없음, 스토리지 없음, 재검증해야 함
- 프라그마: 캐시 없음
- HTTP 1.0 이전 버전과 호환 가능
- 캐시 제어: 캐시 없음
- 데이터는 캐싱될 수 있지만 항상 검증되고 원본 서버에서 사용됩니다(이름 참고!).
- 원본 사이트에 도달할 수 없는 경우 캐시 서버의 설정에 따라 캐시된 데이터가 반환될 수 있습니다.
- (오류 대신 이전 데이터를 보여줍시다!)
- 캐시 제어: 스토리지 없음
- 데이터에는 민감한 정보가 포함되어 있어 저장해서는 안됩니다(메모리에 사용 후 가능한 한 빨리 삭제).
- 캐시 제어: 재검증해야 함
- 캐시가 만료된 후 첫 번째 쿼리는 원본 서버로 인증해야 합니다.
- 원본 사이트에 액세스할 수 없으면 확실히 오류 보고 – 504(게이트웨이 시간 초과)
- must-revalidate는 캐시 만료 시간인 경우 캐시를 사용합니다.
- 프라그마: 캐시 없음
- HTTP 1.0 이전 버전과 호환 가능