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

🌳 캐시 기본 동작

🍃 캐시가 없는 경우

star.jpg 이미지를 처음 요청했을 경우 서버는 1.1M를 전송함 (헤더 0.1M, 바디 1.0M이라고 가정)

또 다시 똑같은 요청을 했을 경우 서버는 똑같이 1.1M를 전송함

 

이런 방식의 문제점

    ▪ 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함

    ▪ 인터넷 네트워크는 매우 느리고 비쌈

    ▪ 브라우저 로딩 속도가 느림 = 느린 사용자 경험

 

🍃 캐시를 적용한 경우

star.jpg 이미지를 처음 요청했을때 서버는 기존 1.1M HTTP 메시지에 캐시와 관련된 정보를 추가하여 전송함

ex) cache-control: max-age=60      //60초 동안 캐시가 유효함

이를 받은 웹 브라우저는 캐시 저장소에 이 응답 결과를 캐시로 저장함

60초 이내에 동일한 요청을 한다면 네트워크 없이 캐시 저장소에서 바로 받을수 있음

반대로 60초가 초과된 시간에 동일한 요청을 한다면 요청이 서버에게 가고, 서버는 캐시 정보가 포함된 1.1M HTTP 메시지를 다시 전송함

즉, 캐시 유효 시간이 초과하면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신함

 

따라서, 

    ▪ 캐시 덕분에 캐시 유효 시간동안 네트워크 필요 X

    ▪ 비싼 네트워크 사용량 줄일 수 있음

    ▪ 브라우저 로딩 속도가 빠름 = 빠른 사용자 경험

 

그런데, 

만약 서버에서 새로 받은 데이터가 기존에 가진 캐시와 동일하다면?

똑같은 데이터를 또 다운로드하는 것은 무겁고 불필요한 작업이 아닐까?

 

🌳 검증 헤더와 조건부 요청

🍃 예시 상황

서버에서 데이터를 줄 때 최종 수정일(Last-Modified)도 전달 -> 클라이언트의 캐시 저장소에 이 정보도 같이 저장됨

여기서 Last-Modified는 검증 헤더!

서버에서 보낸 메시지 예시

 

클라이언트가 서버에게 동일한 요청을 할 때 (이때 유효시간은 초과됨), 캐시에 저장된 최종 수정일 정보를 같이 넘김

여기서 if-modified-since는 조건부 요청!

클라이언트에서 보낸 메시지 예시

만약 최종 수정일이 변경되지 않았다면 서버는 body가 없는 304 Not Modified 메시지를 전송함 (헤더만 전송하기 때문에 부담이 줄어듬) -> 클라이언트는 캐시에 저장되어 있는 데이터를 재활용

 

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

검증 헤더

캐시 데이터와 서버 데이터가 같은지 검증하는 데이터

    ▪ Last-Modified: 최종 수정일

      단점 1) 1초 미만 단위로 캐시 조정 불가능

      단점 2) 날짜 기반 로직 사용 (데이터는 A->B->A 로 동일해도 날짜가 갱신되었기 때문에 다시 다운로드)

    ▪ ETag: 고유한 버전 이름

      데이터가 변경되면 이 이름을 바꿈 -> 단순하게 ETag 같은지 다른지만 확인하면 됨

      장점 1) 데이터 기반 로직 사용 (데이터가 변경되지 않으면 다운로드 X)

      장점 2) 캐시 제어 로직을 서버에서 완전히 관리함 (클라이언트는 단순히 값만 전달할 뿐 메커니즘 모름)

      활용) 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

 

      

조건부 요청 헤더

조건이 만족하면 200 OK (body에 갱신된 데이터 포함), 만족하지 않으면 304 Not Modified

    ▪ If-Modified-Since (Last-Modified용)

    ▪ If-None-Match (Etag용)

 

🍃 캐시 제어 헤더 

    ▪ Cache-Control: 캐시 제어

      max-age: 캐시 유효 시간, 초 단위

      no-cache: 데이터는 캐시해도 되지만, 오리진 서버에 검증하고 사용

      no-store: 데이터에 민감한 정보가 있으므로 저장하면 안됨

    ▪ Pragma: 캐시 제어 (하위 호환)

    ▪ Expires: 캐시 유효 기간 (하위 호환)

      캐시 만료일을 정확한 날짜로 지정

      max-age와 함께 사용하면 Expires는 무시 (max-age가 더 유연함)

 

🌳 프록시 서버

프록시 캐시 서버에 접근하게 함. 프록시 서버는 여러 개로, 클라이언트와 더 가까이에 존재하므로 오리진 서버와 직접 접근하는 것보다 훨씬 빠름. 

웹 브라우저에 저장되는 캐시를 private 캐시, 프록시 캐시 서버에 저장되는 캐시를 public 캐시라고 함

 

캐시 지시어

    ▪ Cache-Control: public: 응답이 public 캐시에 저장돼도 됨

    ▪ Cache-Control: private: 응답이 해당 사용자만이 위한 것임, pricate 캐시에 저장해야 함(기본값)

    ▪ Cache-Control: s-maxage: 프록시 캐시에만 적용되는 max-age

    ▪ Age: 60: 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

 

🌳 캐시 무효화

확실한 캐시 무효화 응답 (아래의 값 모두 사용해야 함)

    ▪ Cache-Control: no-cache: 캐시해도 되지만, 항상 오리진 서버에 검증하고 사용

    ▪ Cache-Control: no-store: 데이터에 민감한 정보가 있으므로 저장하면 안됨

    ▪ Cache-Control: must-revalidate: 캐시 만료 후 최초 조회시 원 서버에 검증해야 함

     실패시 반드시 504 Gateway Timeout 오류 발생해야 함

     캐시 유효 시간이라면 캐시를 사용함

    ▪ Pragma: no-cache (HTTP 1.0 하위 호환)

 

 

---

참고자료

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의