Today I Learned_221117

HTTP

인프런 HTTP 강의 수강

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

캐시 기본 동작

캐시가 없을 때? -> 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.

캐시 적용

헤더에 cache-control -> 캐시가 유효한 시간을 초 단위로 설정할 수 있다.

캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다.

브라우저 캐시를 참조하여 사용한다.

캐시 유효 시간이 초과하면(stale) 서버를 통해 데이터를 다시 조회하고 캐시를 갱신 -> 네트워크 다운로드가 다시 발생

리소스는 그대로인데 전체를 다시 다운로드 받는다. 너무 손해 아닐까?

유효 기간이 지났는데 서버가 가진 데이터 / 클라이언트가 가진 데이터가 같다면?

검증 헤더와 조건부 요청 1

캐시 유효 시간이 초과했을 때, 두 가지 상황이 발생할 수 있다 -> 데이터가 변경되는 경우 / 데이터가 변경되지 않는 경우

-> 검증 헤더가 이 문제를 해결할 수 있음

검증 헤더

클라이언트의 캐시 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법

Last-Modified: 데이터가 마지막으로 수정된 수정일(UTC)

클라이언트 헤더에 if-modified-since(조건부 요청)를 보내면(캐시가 가지고 있는 데이터 최종 수정일) -> 서버의 데이터 최종수정일과 비교 -> 맞으면 서버에서 304 Not Modified를 리턴하고 브라우저 캐시 사용

최종적으로는 body를 제외한 header만 전송이 된다.

정리

• 캐시 유효 시간이 초과해도 서버의 데이터가 not modified이면 -> 304 및 헤더 정보만 리턴
  • 클라이언트는 캐시의 메타 정보를 갱신 및 정보 재활용
  • 네트워크 다운로드 발생(요청/응답)하긴 하나, 용량이 적은 정보만 다운로드 받는다.

검증 헤더와 조건부 요청 2

검증 헤더 : 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터(Last-Modified, ETag)

조건부 요청 헤더 : 검증 헤더로 조건에 따른 분기를 서버에게 요청

• 조건이 만족하면 200 OK, 만족하지 않으면 304 Not Modified 리턴
  • If-Modified-Since -> Last-Modified
  • If-None-Match -> ETag

If-Modified-Since

• 이 이후에 데이터가 수정되었는지?
  • 수정 안되었으면 304 Not Modified
  • 수정 되었으면 200 OK
• 단점
  • 초 단위로 초 미만 단위는 조정할 수 없다.
  • 날짜 기반 로직 사용 - 데이터 자체는 수정이 안 되었는데 날짜만 바뀐 경우 대응을 못 한다
  • 크게 컨텐츠에 영향을 끼치지 않는데 굳이 캐시를 갱신해야 하나?

If-None-Match

• ETag -> Last-Modified의 단점을 보완
• ETag : Entity Tag
• 캐시 데이터에 임의의 고유 버전 이름을 달아둔다 - 데이터가 변경되면 ETag 이름을 바꿔 변경(hash 다시 생성)
• 해시는 파일이 동일하면 같은 결과가 나온다
• ETag가 같으면 유지, 다르면 다시 받기
• 클라이언트가 If-None-Match로 보낸 ETag값이 같다? - 304 Not Modified 보낸다
  • If-None-Match 말이 이상해보이지만, ETag값이 달라야 200 OK (전체 다운로드)가 진행된다.

정리

• ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기 -> 캐시 제어 로직을 서버에서 완전히 관리(클라이언트는 캐시 매커니즘을 모른다)
• 서버가 파일이 변경되어도 ETag를 유지하는 등 서버에서 캐시 제어 로직을 관리할 수 있다.

캐시와 조건부 요청 헤더

Cache-Control

캐시 제어. 캐시 지시어(directives)

• Cache-Control: max-age
  • 초 단위의 캐시 유효 시간(보통은 길게 잡는다)
• Cache-Control: no-cache
  • 데이터 캐시하지 말라는 건가?
  • 데이터는 캐시해도 되는데, 항상 캐시를 쓰기 전에 If-Modified-Since 등 조건부 요청을 해서 로컬에 있는 캐시 데이터를 무조건 검증하고 쓰라는 듯.
  • 서버의 데이터가 바뀌었는지, 바뀌지 않았는지 검증해야 한다.
  • 항상 원 서버에 검증 - 중간의 캐시 프록시 서버를 거치는 것이 아니라 원래 서버까지 가서 검증을 진행한다.
• Cache-Contro: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안된다
  • 메모리에서 사용하고 최대한 빨리 삭제해야 한다.
  • no-cache / no-store 헷갈리면 안 된다!

Pragma

no-cache처럼 동작하며, HTTP 1.0 하위호환이다.

Expires

캐시 만료일 지정(하위 호환). 초 단위가 아니라 만료일을 날짜로 지정하는 것

지금은 Cache-Control:max-age 권장하며, max-age와 함께 사용하면 Expires는 무시된다.

검증 헤더와 조건부 요청 헤더

• 검증 헤더(Validator)
  • ETag, Last-Modified
• 조건부 요청 헤더
  • If-Match, If-None-Match
  • If-Modified-Since, If-Unmodified-Since

프록시 캐시

CDN 서비스(AWS CloudFront)

요청이 오면 원 서버에 직접 요청하는 것이 아니라 프록시 서버에 접근하도록 요청을 한다.

public 캐시 : 프록시 서버 등, 중간에서 공용으로 사용하는 캐시

private 캐시 : 웹 브라우저나 로컬에 저장되는 캐시

Cache-Control 캐시 지시어

• Cache-Control: public
  • 응답이 public캐시에 저장되어도 됨
  • 공용으로 사용하는 이미지 등
• Cache-Control: private
  • 응답이 해당 사용자만을 위한 것. 중간 public 캐시가 아닌 private 캐시에 저장되어야 함
  • 기본값
  • 로그인 정보 등
• Cache-Control: s-maxage
  • 프록시 캐시에만 적용되는 max-age
• Age: 60
  • 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간

캐시 무효화

확실히 캐시 무효화를 할 수 있는 응답들이 있음

이 페이지는 절대 캐시가 되면 안된다면 이걸 다 넣어야 함

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache

• Cache-Control: no-cache
  • 데이터를 항상 원 서버에 검증하고 사용
  • 원 서버에 접근할 수 없는 경우, 캐시 서버 설정에 따라서 200 OK를 보내줄 수 있음 (프록시 캐시에 저장된 데이터)
• Cache-Control: no-store
• Cache-Control: must-revalidate
  • 캐시 만료 후 최초 조회 시 원 서버에 검증해야 함
  • 원 서버에 접근할 수 없는 경우, 항상 오류가 발생 (504 Gateway Timeout)
• Pragma: no-cache
  • 혹시 모를 HTTP 1.0에서 올 요청을 피해야 하므로
  • HTTP 1.0은 Cache-Control: no-cache를 모른다