캐시와 조건부 요청

캐시

• 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소

캐시의 장점

• 비싼 네트워크 사용량을 줄일 수 있다.
• 빠른 브라우저 로딩 속도로 사용자에게 편의를 제공한다.
• 캐시 덕분에 캐시 가능 시간동안은 네트워크를 사용하지 않아도 된다.

캐시가 없다면?

• 비싼 인터넷 네트워크 비용을 계속 지불해야 한다.
• 브라우저 로딩 속도가 느리기 때문에 사용자가 불편할 수 있다.
• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.

캐시의 기본 동작과정

• 먼저, 첫번째 요청시 클라이언트가 웹 브라우저를 통해
  서버에 데이터를 요청한다. (GET / starts.jpg)
• 그러면 서버는 데이터와 함께 캐시의 유효시간을 같이 전달해준다.

HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60 <!--유효시간 60초-->
Content-Length: 34012

1k2k2j19jd-2jlkmmne023u29v9m2312v...

• 웹 브라우저의 브라우저 캐시를 저장해두는 곳에 응답결과를 캐시에 저장한다.
• 후에 두번째 요청이 들어왔을 때,
  먼저 캐시를 찾아보아서 응답속도를 크게 높일 수 있다.
• 캐시 시간 초과가 되었다면?
  • 물론 유효시간이 끝나고 요청이 되었다면, 다시 전송하게 되고 캐시를 갱신한다.⇒ 만약 이 과정에서 데이터가 바뀌지 않았다면, 교환할 필요가 있을까?

캐시 시간 초과

• 위 문제를 해결할 수 있는 것이 바로 검증 헤더와 조건부 요청이다.
• 클라이언트에서 요청을 보낼 때 검증 헤더를 추가해 요청을 보내게 된다.

HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60 <!--유효시간 60초-->
Last-Modified: 2022년 03월 20일 10:00:00
Content-Length: 34012

1k2k2j19jd-2jlkmmne023u29v9m2312v...

• 후에 유효시간이 만료되고 다음 요청이 들어왔을 때,
  if-modified-since: 2022년 03월 20일 10:00:00 이라는 헤더를
  브러우저 캐시에서 가져와 서버에게 전달해주게 된다.
• 서버에서는 데이터의 최종 수정일과 위 데이터를 비교하여 응답을 보낸다.

HTTP/1.1 304 Not Modified
Content-Type: image/jpeg
cache-control: max-age=60 <!--유효시간 60초-->
Last-Modified: 2022년 03월 20일 10:00:00
Content-Length: 34012

• 이번 응답에서는 body 없이 데이터를 보내게 되고,
  데이터를 갱신하고 사용하게 된다.
• 결과 정리
  • 304 Not Modified + 헤더 메타 정보로만 응답하게 되어
    네트워크 부하가 매우 줄어들게 된다.
  • 메타 정보만 갱신하고, 데이터는 클라이언트 캐시에 저장되어 있는
    데이터를 재활용 하게 되는 것이다.

⇒ If-Modified-Since, Last-Modified 를 이용했을 때의 단점

• 둘 다 날짜 기반의 로직을 사용한다.
  • 데이터를 수정하여 날짜가 달라도
    데이터가 다르지 않을 때도 다르다고 판단할 수 있다.
• 임의로 캐시 제어 로직을 조절할 수 없다.

이를 해결할 수 있는 ETag를 사용한 방식이있다.

• ETag(Entity Tag)
  • 캐시용 데이터에 임의의 고유한 버전 이름을 설정할 수 있다.
  • ex_) ETag: “v1.0”, ETag: “BB_GG”
• 이번에도 위와 같은 요청을 보내는 걸로 예시를 들어보겠다(GET / starts.jpg)

HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60
ETag: "aaabbbccc"
Content-Length: 34012

1k2k2j19jd-2jlkmmne023u29v9m2312v...

• 서버에서는 ETag와 함께 캐시의 이름을 지정하여 응답을 하게된다.
• 후에 두번째 요청부터는 브라우저 캐시에서 ETag 이름을 보내게 된다.
• GET / starts.jpg
If-None-Match: “aaabbbccc”
• 서버에서는 If-None-Match를 통해서 데이터가 같은지 확인하고

HTTP/1.1 304 Not Modified
Content-Type: image/jpeg
cache-control: max-age=60
ETag: "aaabbbccc"
Content-Length: 34012

• 같은 이름이기 때문에 304 Not Modified와 함께 body 없이 응답을 보내게 된다.
• 서버가 캐시 제어 로직을 완전하게 관리할 수 있다!

[정리] 검증 헤더와 조건부 헤더

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

캐시 제어 헤더 종류

• Cache-Control
  • max-age
    • 캐시 유효시간을 초단위로 설정한다.
  • no-store
    • 데이터에 민감한 정보가 있으므로 저장하면 안된다.
  • no-cache
    • 데이터는 캐시해도 되지만 항상 원 서버에서 검증하고 사용해야한다.
  • must-revalidate
    • 캐시가 만료되고 최초 조회시 원 서버에서 무조건 검증을 거치고 사용해야한다.
  • 만약 중간에 인터넷이 끊겨 원 서버에서 검증을 못거치게 된다면?
    • no-cache는 200 OK와 함께 오래된 데이터라도 보여줄 수 있다.
    • must-revalidate는 무조건 검증을 거쳐야하기 때문에 에러를 발생시켜야한다.
• Pragma
  • no-cache
  • 하위 호환 버전으로서 잘 사용되진 않는다.
• Expires
  • 캐시 만료일을 정확하게 지정할 수 있다.
  • 유연성을 중시하기 때문에 Cache-Control: max-age 사용 권장함.
• 확실한 캐시 무효화를 위해서는 아래와 같이 사용하여야 한다.

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

프록시 캐시

• 원래 서버가 매우 먼 곳에 있어 응답속도가 느릴 수 밖에 없는 상황
• 프록시 캐시 서버를 통해서 이 응답속도를 해결 할 수 있다.
  • CDN 서비스, 웹 캐시 서버 등을 사용
  • 데이터를 캐시해두는 서버를 가까운 곳에 두는 느낌
    즉, 미국에 있다면 한국 지사를 만들어두는 느낌이라 생각하면 좋을 것 같다.
• 관련 헤더
  • Cache-Control
    • public - 응답을 public 캐시에 저장함
    • private - 응답을 private 캐시에 저장해야함 (기본값)
    • s-maxage - 프로시 캐시에만 적용되는 max-age
    • age - 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간

Http에서 캐시를 이용하는 방법에 대해서 알아보았다.