HTTP 헤더 - 캐시와 조건부 요청

캐시 기본 동작

캐시가 없을 때

• 인터넷 네트워크는 느리고 비싼데, 데이터가 변경되지 않아도 계속 네트워크를 통해 데이터를 다운받아야 한다.

• 브라우저 로딩 속도가 느려 사용자에게 불편함을 준다.

캐시 적용

• 캐시 덕분에 캐시 가능 시간 동안에는 네트워크를 사용하지 않아도 되어 비싼 네트워크 사용량을 줄일 수 있다.

• 브라우저 로딩 속도가 빨라 사용자에게 편리함을 준다.

캐시 시간 초과

검증 헤더와 조건부 요청

1. 서버에서 기존 데이터를 변경한 경우
• 변경한 경우에는 변경된 이미지가 응답으로 오게 될 것이다.

2. 서버에서 기존 데이터를 변경하지 않은 경우
• 변경하지 않은 경우에는 캐시에 저장되어 있는 데이터를 재사용하는 것이 효율적이다. 대신 클라이언트의 데이터(캐시에 저장된 데이터)와 서버의 데이터가 같다는 사실을 확인할 필요가 있다.
 

• 일치할 경우
• 데이터가 아직 수정되지 않았다는 의미이기 때문에 캐시에 저장되어 있던 데이터를 재사용할 수 있다.
• 304 Not Modified 상태코드(너의 캐시로 리다이렉션해라)를 주고, HTTP 메세지 바디(이미지 바이트)없이 HTTP 헤더 메타 정보만 보낸다. 이 정보로 캐시의 메타 정보를 갱신하는 것이다.
• ex) 전송 용량 0.1M (헤더 0.1M)

• 일치하지 않은 경우
• 데이터가 수정되었다는 의미이기 때문에 캐시에 저장되어 있던 데이터를 재사용할 수 없다.
• 200 OK 상태코드를 주고, HTTP 메세지를 통해 데이터 전체를 새로 받게 된다.
• ex) 전송 용량 0.1M (헤더 0.1M, 바디 1.0M)

• 1초 미만의 단위로 캐시 조정이 불가능

• 날짜 기반의 로직이여서 같은 데이터를 수정해서 날짜만 다를 때, 다른 날짜이기 때문에 다른 데이터처럼 인식..

• 서버에서 별도로 캐시 로직을 관리하고 싶을 때 불리

• 캐시 제어 로직을 완전히 서버에서 관리 → 클라이언트는 단순히 ETag 값을 서버에 제공하는 것이기 때문에 캐시 메커니즘을 모름

캐시와 조건부 요청 헤더

캐시 제어 헤더

• cache-control: 여러 지시어를 통해 캐시를 제어함
• max-age 캐시 유효 시간을 초 단위로 작성하는 지시어
• no-cache 데이터는 캐시해도 되지만, 항상 원서버(Origin Server)에 검증하고 사용
• no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨 → 메모리에서 사용하고 최대한 빨리 삭제
• public 응답(데이터)이 public 캐시에 저장되어도 됨
• private 응답(데이터)이 해당 사용자만을 위한 것임, 원래 기본값으로 private 캐시에 저장해야 함
• must-revaildate 캐시 만료 후 최초 조회시, 원서버(Origin Server)에 검증해야 함 → 원서버에 접근 실패시 반드시 504 Gateway Timeout 오류 발생

• pragma: 캐시 제어 헤더인데, HTTP 1.0 하위 호환을 원할 때만 사용

• expires: 캐시 만료일을 정확한 날짜로 지정하는 것인데, HTTP 1.0부터 사용한 거라서 지금은 cache-control: max-age를 권장함

검증 헤더 (Validator)

• ETag

• last-modified

조건부 요청 헤더

• if-match, if-none-match → ETag 값 사용

• if-modified-since, if-unmodified-since → last-modified 값 사용

프록시 캐시

캐시 무효화

• cache-control: no-cache, no-store, must-revalidate

• pragma: no-cache