캐시 기본 동작

다들 웹 페이지를 새로고침을 하거나 잠시 다른곳을 다녀올때? 컴퓨터가 내 방문 경로를 잘 알고있구나 라는 느낌이들 정도로 빠르게 로드된다.

다만 어떤 페이지를 처음 방문할 때는 역시 컴퓨터도 초행길이라 그런지 조금 느릴 수 밖에 없다고 그냥 당연하게 생각하고 있었다.

하지만 이런 차이를 느끼게 하는 것이 바로 캐시라는 것이다.

내가 데이터를 한번 요청했다치자, 다음번에도 똑같은 데이터를 요청할땐 이제 웹 브라우저 자체적으로 쿠키저장소가 있듯이 캐시저장소도 있다.

그 캐시저장소에 데이터가 유효한 채로 저장되어있다면 굳이 서버에 요청하지않고 브라우저에서 꺼내쓰는 메커니즘이다.

이를 통해

• 캐시 유효 시간동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다.
• 브라우저 로딩 속도가 매우 빨라진다.
• 사용자로 하여금 굉장히 빠른 경험을 제공할 수 있다.

그러나 캐시의 시간이 초과되면..?

그땐, 네트워크 다운로드를 감수하고 서버를 통해 데이터를 다시 조회하고 다시 갱신해야한다.

그러나 이를 해결할 수 있는 메커니즘이 있다고 한다.

캐시의 시간이 초과되어 서버에 다시 요청하면 두 가지 상황이 있다.

1. 서버에서 기존 데이터가 변경됨 (당연히 이건 다시 다운받아야함)
2. 서버에서 기존 데이터를 변경하지 않았음 (이걸 해결해보자)

검증 헤더와 조건부 요청 (Last-Modified, if-modified-since)

우선 검증 헤더라는 것은 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터다.

서버에서 데이터를 변경하지 않았을 때, 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.

그러나 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다.

(대략 이런 상황)

이에, HTTP 헤더에 Last-Modified를 추가하자.

그렇다면 서버는 이제 데이터에 대해서 수정이 되었는지에 대한 검증을 할 것이다.

클라이언트도 그럼 요청을 보낼때, Last-Modified와 세트를 이루는 헤더를 보내야한다.

클라이언트에서는 if-modified-since를 보내면, star.jpg에 대해 Last-Modified 값을 비교하면 똑같으면 304(Not Modified)를 내보내며 브라우저에 있는 캐시 그대로 써도된다를 의미하는 시그널을 보낸다.

이를 통해, 캐시 요청 시간이 지났더라도 HTTP 헤더만 보내봄으로써 네트워크 부하를 확 줄일 수 있게 된다.

검증 헤더와 조건부 요청(Not-modified, if-modified-since) 정리

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

정말 획기적인 방안이지만, 역시 단점이 존재한다.

• 1초 미만(0.x초) 단위로 캐시 조정이 불가능하다.
• 날짜 기반의 로직을 사용하게 된다.
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우 (최종적으로 데이터 변경은 안됐지만) 이때도 다시 다운로드한다.
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
  • ex) 스페이스나 주석처럼 큰 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

이를 해결하기 위한 것이 바로 Etag다.

검증 헤더와 조건부 요청 (Etag, If-None-Match)

Etag란, Entity Tag로써 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다.

예를 들어 Etag : "v1.0", Etag : "a2dkfjassf"

이런식으로, 데이터가 변경되면 이 이름을 바꾸어서 변경한다 (Hash를 다시 생성)

ex) Etag: "aaa" -> Etag: "bbbbb"

진짜 단순히 Etag만 보내서 같으면 유지, 다르면 다시 받는것!

이제 HTTP헤더에 Etag라는 것이 추가된다.

그렇다면 클라이언트는 이제 Etag를 유지한다.

지금부터 클라이언트는 캐시가 만료됐을때, 데이터가 Etag를 가지고있다면

If-None-Match를 보낸다.

이게 말이 좀 헷갈리는데, 변경되지 않았으면 304(Not-Modified)를 보내서 변경되지 않았으니 캐시를 그대로 가져다써라 라는 시그널을 주고받는다.

그러니까 부정적 어구들로 성공의 시그널을 주고받는 느낌이다 ㅋㅋ

검증 헤더와 조건부 요청 (Etag, If-None-Match) 정리

• 단순히 Etag만 서버에 보내서 같으면 유지, 다르면 다시 받기
• 캐시 제어 로직을 서버에서 완전히 관리한다.
• 클라이언트는 단순히 Etag 값만을 서버에 제공한다.
  • 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 Etag를 동일하게 유지한다.
  • 애플리케이션 배포 주기에 맞추어 Etag를 모두 갱신한다.

캐시와 조건부 요청 헤더

HTTP에는 캐시를 제어하는 헤더들이 많다.

• Cache-Control: 캐시 제어
• Pragma: 캐시 제어
• Expires: 캐시 유효 기간

★Cache-Control★

• Cache-Control: max-age
  • 캐시 유효 기간, 초단위
• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 오리진 서버에 검증하고 사용하도록
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으니 저장하지마라 (메모리에서 사용하고 최대한 빨리 삭제)

Pragma

별로 사용안함.

• Pragma: no-cache
  • HTTP 1.0 하위호환

Expires

캐시의 만료일을 지정하는데, 이것 역시 HTTP 하위버전에서 호환한다.

ex) expires: Mon, 01 Jan 1990 00:00:00 GMT

그냥 Cache-Control: max-age 쓰자!

프록시 캐시

만약, 한국에서 미국에 있는 원 서버에 접근하려고 한다. 빛의 속도로 1초에 지구 7바퀴 반을 돈다 쳤을때 미국의 원서버와 직접적으로 데이터를 주고받으면 굉~~~장히 느릴 것이다.

이때, Proxy라는 대리인, 대리하여 처리한다는 뜻을 가진 프록시 캐시 서버를 한국 어딘가에 둔다.

그럼 우리는 굳이 미국 컨텐츠를 이용할때, 미국에 있는 원 서버를 이용하지않고 한국 어딘가에 있는 프록시 캐시 서버를 이용하여 응답을 받게 된다.

그림으로 이해하면 대충 이런식이라고 한다.

HTTP 마무리

원래는 1주일만에 마무리하려했는데,,, 자취방에 노트북이 없다보니 ㅜㅜ 회사에서 아니면 글 작성을 못했다..

근데 회사에서도 노트북 사용을 못하는 상황이라 조금 늦어졌다.

그래도 마무리했으니 조금 뿌듯한 것 같고 뭔가 블로그를 매개로 이렇게 복습을 하니까 머리에 더 오래 남게 되는것같다.

끝!