8. HTTP 헤더 2 – 캐싱 및 조건부 요청

캐시가 없을 때

• 데이터가 변경되지 않더라도 네트워크를 통해 지속적으로 데이터를 다운로드해야 합니다.
• 인터넷 네트워크는 매우 느리고 비쌉니다.
• 브라우저가 느리게 로드됩니다.
• 느린 사용자 경험

적용된 캐시

• 요청이 들어오면 서버에서 캐시 제어:최대 연령=60 다음과 같이 캐시가 유효한 시간을 지정합니다.
• 응답 결과를 브라우저 캐시에 저장(60초 이내 유효)
• 2차 요청 들어오면 캐시 만료 시간 확인 후 유효한 경우 캐시에서 조회(네트워크 x 필요)
• 캐싱 덕분에 캐시 가능한 시간 동안 네트워크를 사용할 필요가 없습니다.
• 비용이 많이 드는 네트워크 사용량을 줄일 수 있습니다.
• 브라우저가 매우 빠르게 로드됩니다.
• 빠른 사용자 경험
• 3번째 요청이 들어오면 유효기간이 만료됩니다. 캐시 시간 초과만약 그러하다면?
• 응답 결과를 다시 캐시에 저장합니다.
• 캐시의 유효 기간이 초과되면 서버에서 데이터를 검색하고 캐시를 업데이트합니다.
• 이때 네트워크 다운로드가 다시 발생했습니다.
• 그러나 클라이언트가 보유한 데이터와 서버가 보유한 데이터가 변경되지 않은 경우 동일합니까?

캐시 시간 초과

• 캐시 만료 시간이 초과되어 다시 서버에 요청하면 다음 두 가지 상황이 발생합니다.
  1. 서버의 기존 데이터 변경 → 캐시 다시 조회 및 업데이트
  2. 서버의 기존 데이터는 변경되지 않습니다.
     • 캐시된 데이터가 변경되지 않았는지 확인할 수 있어야 합니다. → 확인 헤더 추가

인증 헤더

• 서버 → 브라우저 전송 및 브라우저 캐시에 저장
• 캐시에 (마지막 변경: 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 이전 버전과 호환 가능