HTTP 헤더2

본 자료는 김영한님의 강의 모든 개발자를 위한 HTTP에서 내용을 정리한것입니다.

캐시와 조건부 요청

만약 유저가 다시 star.jpg를 똑같이 요청한다면? => 1.1M의 전송을 똑같이 다시 보낸다.

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
• 인터넷 네트워크는 매우 느리고 비싸다.
• 브라우저 로딩 속도가 느리다.
• 느린 사용자 경험.

똑같은 두번째 요청이 일어난다면? cache-control의 max-age동안(캐시가 유효 할 동안) 브라우저 캐시에서 조회한다.

• 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크를 줄일 수 있다.
• 브라우저 로딩 속도가 빠르다.
• 빠른 사용자 경험.

만약, 똑같은 요청이지만 캐시 유효 시간 검증을 초과 했다면??

• 캐시 유효 시긴이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
• 이때 다시 네트워크 다운로드가 발생

캐시 유효시간이 초과해서 서버에 다시 요청하면 두가지 상황이 나타난다.
1 . 서버에서 기존 데이터를 변경함 : 다시 다운 받는게 맞고 그냥 계속 진행이 되면 됨..
2 . 서버에서 기존 데이터를 변경하지 않음 : 문제의 상황. 처음부터 다시 다운로드 받을 필요가 있는가?

검증 헤더

• 캐시 만료후에도 서버에서 데이터를 변경x
• 저장해 두었던 캐시를 재사용 할 수 있다.
• 단 클라이언트의 데이터와 서버 데이터가 다르지 않다는 "검증"이 들어가야 된다.
  서버에서 내려줄때
  last-modified: Fri, 04 Feb 2022 15:42:30 GMT
  요청이 들어갈때
  if-modified-since: Fri, 04 Feb 2022 15:42:30 GMT
• 데이터 최종 수정일이 다르지 않다면 서버에서는 판단을 내려서 HTTP 304 Not Modified를 내림.
• 데이터를 주고 받지만, 아주 작은 용량들만 서로 주고받는다. 네트워크 부하가 확 줄음.
• 캐시를 다시 조회해서 사용하게 된다.

정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디 x)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 실용적인 해결책

검증헤더와 조건부 요청

• 검증 헤더

  • 캐시 데이터와 서버 데이터가 같은지 검증. (last-modified, ETag)

• 조건부 요청 헤더

  • 검증 헤더로 조건에 따른 분기
  • if-modified-since : last-modified 사용
  • if-None-Match: ETag사용
  • 조건이 만족하면 200 OK
  • 만족하지 않으면 304 Not Modified

  modified의 단점

• 1초 미만(0.x)초 단위로 캐시 조정이 불가능

• 날짜 기반의 로직 사용

• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우(A->B->A로 다시 되돌렸지만 날짜는 달라짐.)

• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 -> ex) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

ETag, if-none-match

• ETag(Entity Tag)
• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 ex) ETag: "v1.0"
• 데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)(A->B->A로 다시 돌아올시 같은 Hash가 나옴)
• 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기.
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 단순히 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)

캐시 제어 헤더

1. Cache-Control : 캐시 제어
2. Pragma : 캐시 제어(하위 호환)
3. Expires : 캐시 유효 기간(하위 호환)

Cach-Control - 모든 걸 다 할 수 있음. (캐시 지시어)

• Cache-Control: max-age => 캐시 유효 시간, 초 단위
• Cache-Control: no-cache => 데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용
• Cache-Control: no-store => 데이터에 민감한 정보가 있으므로 저장하면 안됨.(메모리에서 사용하고 빠르게 삭제)

Pragma

• Pragma: no-cache
• HTTP1.0 하위 호환. (사실상 안씀)

Expires 캐시 만료일 지정

• expires: Mon, 01 Jan 1990 00:00:00 GMT
• 캐시 만료일을 정확한 날짜로 지정
• HTTP 1.0부터 사용
• 지금은 더 유연한 Cache-Control:max-age 권장
• Cache-Control: max-age와 함께 사용하면 Expires는 무시

정리

검증 헤더 (Validator)

• ETag: "v1.0", ETag: "asid93jkrh2l"
• Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT

조건부 요청 헤더

• If-None-Match, If-Match: ETag 값 사용
• If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

프록시 캐시

Origin 서버 - 실제 소스가 있는 서버(origin 서버)

• 한국에 있는 클라이언트가 미국에 있는 origin 서버에 계속 왔다갔다 해야되면 느리다.

• 중간에 프록시 서버라는 것을 마련. 훨씬 가까운 곳(여기선 한국이라 하겠다)에 서 데이터를 주고 받는다.

  

프록시 캐시 도입

Cache-Control: public => 응답이 public 캐시에 저장되어도 됨.
Cache-Control: private => 응답이 해당 사용자만을 위한 것. private 캐시에 저장해야함(기본값)
Cache-Control: s-maxage => 프록시 캐시에만 적용되는 max-age
Age: 60(HTTP 헤더) => origin 서버에서 응답 후 프록시 캐시 내에 머문 시간.(일반적인 사용자나 개발자는 볼 일이 없다. 프록시 서버를 운영하는 회사에서 사용하는 것..)

캐시 무효화

확실한 캐시 무효화 응답

• Cache-Control: no-cache
  Cache-Control: no-store
  Cache-Control: must-revalidate

• Pragma: no-cache (HTTP 1.0 하위 호환)
  => 캐시가 되면 안되는 상황에서 이렇게 다 넣어 줘야 된다.

  다른 것은 이미 봤으니 must-revalidate를 확인해 보겠다.
  Cache-Control: must-revalidate

  • 캐시 만료후 최초 조회시 origin 서버에 검증 해야함.
  • origin 서버 접근 실패시 반드시 오류가 발생해야함. (504 Gateway Timeout)
  • must-revalidate는 캐시 유효 시간이라면 캐시를 사용함

얼핏 살펴보니 no-chache와 must-revalidate가 비슷해 보이는데 왜 must-revalidate가 필요한가?

• no-chache로 보낸 상황에서 순간 네트워크 단절 -> orgin 서버 접근 불가.
  = > origin 서버에 접근 할 수 없는 경우 프록시 캐시 서버 설정에 따라서 캐시 데이터를 반환할 수 있음. (Error or 200 OK, 오래된 데이터라도 보내주자.)
• must-revalidate도 마찬가지로 순간 네트워크 단절 - > origin서버 접근 불가 -> 항상 오류가 발생 . 504 Gateway Timeout이 발생.