HTTP 통신을 이해해보자 -8

박가현·2023년 6월 5일
1

HTTP

목록 보기
8/8
post-thumbnail

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



캐시가 없을 때 발생하는 현상

  1. 클라이언트가 서버에게 star라는 이미지를 요청했다고 가정
  2. 만약 헤더 0.1M , 바디 1.0M여서 총 1.1M용량이라고 가정
  3. 클라이언트는 네트워크를 사용해서 이미지를 다운받고 star이미지가 필요하면 다시 한번 요청한다
  4. star 이미지는 변경 되지 않았음에도 서버는 다시 한번 이미지 데이터를 보내며(1.1M 용량을) 응답한다

이렇게 데이터가 변경되지 않아도 계속해서 같은 데이터를 응답해야하고 웹 브라우저는 네트워크를 사용해서 다시 한번 데이터를 다운로드 받아야한다

→ 실제 인터넷 네트워크는 매우 느리고 비싸기에 브라우저 로딩 속도가 느리고, 느린 사용자 경험을 할 수 있다


캐시

캐시

캐시는 데이터나 값을 미리 복사해놓는 임시장소로 위와 같은 상황을 해결할 수 있다

❓캐시가 있다면

  1. 서버는 star 이미지를 보낼 때 cache-control : max-age = 60 라는 헤더를 같이 보낸다
  2. 이 헤더는 캐시의 유효한 시간을 의미하고 60초동안 캐시가 유효하다는 것을 알 수 있다
  3. 브라우저는 응답 결과를 캐시에 저장하고 다시 한번 star 이미지를 사용할 때 요청이 아닌 브라우저 캐시에서 사용할 수 있다

실제 네트워크에서 연하게 표시되는것은 캐시에서 가져오는 데이터이고 status code 옆에 (from memory cache)가 적혀있다

✅캐시 장점

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

❓캐시의 유효시간이 초과되었다면

  1. 클라이언트가 요청을 보내기 전에 캐시에 해당 데이터가 존재하는지 확인하는데 만약 유효시간이 초과되었다면 서버를 통해 다시 데이터를 조회하고 캐시를 갱신한다

하지만 만약에 유효시간이 초과되었지만 기존 데이터가 변경되지 않은 상황이라면?

→ 유효시간이 초과되어도 기존 데이터가 변경되지 않았다면 다시 사용할 수 있다

서버는 데이터를 응답할 때 Last-Modified라는 헤더도 함께 전송한다 이는 데이터가 마지막에 수정된 시간을 의미한다

브라우저는 캐시에 데이터를 저장할 때 데이터 최종 수정일 (Last-Modified)를 저장하고 유효시간이 초과되어 다시 데이터를 요청할때 if-modified-since라는 요청헤더에 최종 수정일을 담아 전송한다

만약 데이터가 변경되지 않았으면 서버는 상태코드 304로 http body가 없는 상태에서 응답을 보낸다 ( 1.0M을 전송하지 않은것)

브라우저는 이미지 데이터를 전달받고 응답 결과를 캐시에 재사용하면서 헤더의 메타 데이터를 갱신한다( 다시 cache- control:max -age의 값인 유효시간을 갱신)

이는 매우 실용적인 해결책으로 자주 사용되는 매커니즘이다


검증헤더와 조건부 요청

검증헤더

  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  • Last-Modified, ETag

조건부 요청 헤더

  • 검증 헤더로 조건에 따른 분기
  • if-Modified-Since : Last-Modified 사용
  • If - None - Match :ETag 사용

Last-Modified, if-Modified-Since 단점

1초 미만 단위로 캐시 조정이 불가능하고 날짜 기반의 로직을 사용한다

만약 star 이미지를 circle 이미지로 수정후 원래의 star 이미지로 수정했다면 데이터는 수정되지 않았음에도 last-modified가 변경되어 데이터가 변경되었다고 판단한다

ETag

캐시용 데이터에 임의의 고유한 버전을 달아두는 것으로 데이터가 변경되면 이 이름을 바꾸어서 변경한다 캐시 제어로직을 서버에서 완전히 관리되는 것이다

( ex 애플리케이션 배포때마다 ETag를 바꾸자와 같이 규칙을 정해놓으면 캐시 제어로직을 서버에서 완전히 관리할 수 있다)



캐시 제어 헤더

Cache - Control

  • Cache-Control : max -age :캐시 유효시간, 초 단위
  • Cache-Control : no-cache : 데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용한다 ( 중간에 프록시 서버가 아닌)
  • Cache-Control : no-store : 데이터에 민감한 정보가 있으므로 저장하면 안되는 정보를 의미한다 브라우저가 임의로 캐시를 하기도 해서


프록시 캐시

한국에 있는 클라이트가 미국에 있는 원 서버에 직접 요청을 하면 너무 오래걸린다는 단점이 있다

그래서 프록시 캐시 서버를 도입하였고 이런걸 cdn 서비스라한다

그러면 우리는 프록시 캐시 서버에 접근하기도 하는데 이는 응답 시간이 빠른 장점이 있다

클라이언트 캐시를 private 캐시라하고 프록시 캐시를 public 캐시라고 한다

아래와 같은 캐시 지시어가 존재한다

  • Cache-Control : public → 응답이 public 캐시에 저장되어도 됨
  • Cache-Control : private → private 캐시에 저장해야함
  • Cache-Control : s-maxage → 프록시 캐시에만 적용되는 max-age
  • Age:60 → 원서버에서 응답 후 프록시 캐시내에 머문 시간


캐시 무효화

  • must revalidate

ex) 클라이언트 브라우저에서 데이터 요청을 하여 프록시 캐시에서 원서버로 가는 순간 네트워크가 단절되었다고 가정 그러면 오류가 뜨는 것보다 옛날 데이터라도 보내는 것이 낫다고 생각해서 200과 함께 과거 데이터를 보낼 수도 있음

하지만 must-revalidate는 원 서버에 접근할 수 없는 경우 항상 504 오류를 발생시킨다

profile
프론트엔드 공부일지

0개의 댓글