8. HTTP 헤더 - 캐시와 조건부 요청

캐시 기본 동작

1.1M(헤더+바디)가 전송됨. 

클라이언트에서 요청한 내용을 보고 서버가 실제 이미지와 관련된 바이트 코드를 포함한 응답을 내린다.

또 다시 요청하면 첫 번째처럼 똑같이 1.1MB의 응답을 보내게 되고 캐시가 없으면 데이터가 변경되지 않아도 계속 데이터를 다운받아야 한다. 똑같은 작업을 반복하는 것이다.

 

캐시가 없을 때

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

캐시를 적용한다면 처음 요청했을 때 캐시가 유효한 시간을 cache-control에 설정해서 응답을 보낸다.

웹 브라우저에는 캐시를 저장하는 공간이 있어서 유효한 시간만큼 응답 결과를 캐시에 저장해둔다.

다시 요청할 때는 캐시를 조회한 뒤 시간이 유효한지 확인한다.

유효하면 서버로 가지 않고 캐시에서 가져온다.

 

캐시 적용

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

만약 유효 시간이 초과된다면

다시 서버에 요청을 한다. 서버는 다시 캐시 유효 시간을 담아 보낸다. 다시 네트워크 다운로드가 발생한다.

브라우저는 기존 캐시를 지우고 새 캐시를 덮어 쓴다.

 

캐시 시간 초과

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

 

만약에 캐시만료가 되었을때 클라이언트가 가진 데이터와 서버가 가진 데이터가 같다면 굳이 새로 다운받을 필요가 있을까? 

 

---

검증 헤더와 조건부 요청

 

캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.

 

1. 서버에서 기존 데이터를 변경함

2. 서버에서 기존 데이터를 변경하지 않음

 

캐시 만료후에도 서버에서 데이터를 변경하지 않은 경우

• 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.
• 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하고, 이때 검증 헤더를 사용한다.

Last-Modified: 첫 요청에서 서버가 데이터 최종 수정일을 담아 응답한다.

웹 브라우저는 최종 수정일과 함께 응답 결과를 캐시에 저장한다.

다시 요청할 때 캐시 유효 시간이 초과됐다면

최종 수정일이 있는지 확인하고 if-modified-since 에 담아 서버에 보낸다.

서버는  if-modified-since 를 보고 수정일을 비교한다. 만약 수정되지 않았다면

응답에 304 Not Modified 와 Last-Modified를 담아 보낸다. Body는 빼고 Header만 보낸다. 

0.1MB만큼의 헤더만 전송되고 네트워크 부하가 확 줄어든다.

클라이언트는 304코드를 보고 변경된게 없으니 써도 된다고 인식하고, 재사용 하면서 헤더 데이터를 갱신한다.

 

정리

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

status에서 200이 연한색이면 캐시에서 불러온 것이다.

 

• 검증 헤더

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

Last-Modified , ETag

 

• 조건부 요청 헤더

검증 헤더로 조건에 따른 분기

If-Modified-Since: Last-Modified 사용

If-None-Match: ETag 사용

조건이 만족하면 200 OK

조건이 만족하지 않으면 304 Not Modified

 

If-Modified-Since: 이후에 데이터가 수정되었으면?

• 데이터 미변경 예시

캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00

 

304 Not Modified(캐시로 리다이렉션 해라), 헤더 데이터만 전송(BODY 미포함)

전송 용량 0.1M (헤더 0.1M)

 

• 데이터 변경 예시

캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00

 

 

200 OK, 모든 데이터 전송(BODY 포함)

전송 용량 1.1M (헤더 0.1M, 바디 1.0M)

 

Last-Modified, If-Modified-Since 단점

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

날짜 기반의 정해진 로직 사용한다. a를 b로 수정했다가 다시 a가 되는 경우도 다운받아야한다.

 

ETag, If-None-Match

• ETag(Entity Tag)
• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠

예) ETag: "v1.0", 
ETag: "a2jiodwjekjl3"

 

• 데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)

예) ETag: "aaaaa" -> ETag: "bbbbb"

 

• 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!

첫 요청에 응답할 때 ETag를 담아 보낸다.

웹 브라우저는 ETag 값을 캐시에 저장한다.

시간이 초과됐다면 if-none-match에 ETag 값을 담아 요청한다.

데이터가 수정되지 않았으므로 즉, none-match 조건을 만족하지 않았으므로 실패(헷갈리지만 실패가 맞다)

body 없이 304 Not Modified를 응답한다. Body 전송 안함.

클라이언트는 헤더 데이터를 갱신하고

캐시에서 재사용한다.

 

정리하면

단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받는다.

캐시 제어 로직을 서버에서 완전히 관리하며, 클라이언트는 단순히 ETag 값을 제공할 뿐 캐시 메커니즘은 모른다.

애플리케이션 배포 주기에 맞춰 ETag를 갱신하는 등에 사용할 수 있다.

 

---

캐시 제어 헤더와 조건부 요청 헤더

 

캐시 제어 헤더

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

 

1. Cache-Control = 캐시 지시어(directives)

• Cache-Control: max-age

캐시 유효 시간, 초 단위로 설정한다.

 

• Cache-Control: no-cache

데이터를 캐시해도 되지만, 항상 origin 서버에 바뀌었는지 검증하고 사용한다.

중간에 서버가 있는데, 중간서버에서 하는게 아니라 뒤에 있는 origin 서버에 가야한다.

 

• Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안된다. 메모리에서 사용하고 최대한 빨리 삭제한다.

 

2. Pragma

캐시 제어(하위 호환)

 

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

 

3. Expires

캐시 만료일 지정(하위 호환)

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

캐시 만료일을 초단위가 아니라 정확한 날짜로 지정한다.

HTTP 1.0 부터 사용하며 지금은 초 단위인 Cache-Control: max-age를 권장한다.

Cache-Control: max-age와 함께 사용하면 Expires는 무시한다.

 

• 검증 헤더 (Validator)

ETag와 Last-Modified 가 존재한다.

 

조건부 요청 헤더

If-Match, If-None-Match: ETag 값 사용

If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

 

---

프록시 캐시

클라이언트가 미국에 있는 서버에 접근한다면 시간이 오래 걸린다. 기다려야 한다.

중간에 프록시 캐시 서버를 둔다. CDN 서비스라고 하며 대표적인 것이 AWS Cloud Front다.

요청이 오면 원 서버가 아니라 한국에 있는 프록시 캐시 서버를 거친다. 좀 더 가까이 있으므로 응답 시간이 빨라진다. 처음 요청한 유저는 느리지만 그 다음 요청한 유저는 빠르게 사용할 수 있다. 

예를 들어, 외국 유튜버의 컨텐츠를 볼 때, 한국 사람들이 자주 보는 컨텐츠의 경우 로딩이 빠른데 이는 한국 어딘가에 있는 서버에서 불러오기 때문이다.

프록시 캐시 서버처럼 공용으로 사용하는 곳은 public 캐시, 로컬에서 사용하는 웹 브라우저 캐시는 private 캐시라고 한다.

 

Cache-Control

캐시 지시어(directives) - 기타

• Cache-Control: public

응답이 public 캐시에 저장되어도 된다.

 

• Cache-Control: private

기본 값, 로그인 정보와 같은 응답이 해당 사용자만을 위한 것이므로 private 캐시에 저장해야 한다.

 

아래 두개는 이런게 있다 정도로만 알자.

• Cache-Control: s-maxage

프록시 캐시에만 적용되는 max-age

 

• Age: 60 (HTTP 헤더)

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

 

---

캐시 무효화

 

확실한 캐시 무효화 응답

 

• Cache-Control: no-cache, no-store, must-revalidate
• Pragma: no-cache (HTTP 1.0 하위 호환이 올 수 있으므로)

 

설정과 관계 없이 웹 브라우저가 임의로 캐시를 하는 경우가 있는데 이를 막기 위한 설정이다.

 

캐시 지시어(directives) - 확실한 캐시 무효화

 

• Cache-Control: no-cache

이름과 달리 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용

 

• Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)

 

• Cache-Control: must-revalidate

캐시 만료후 최초 조회시 원 서버에 검증해야함

원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)

must-revalidate는 캐시 유효 시간이라면 캐시를 사용함

 

• Pragma: no-cache

HTTP 1.0 하위 호환을 위해 사용

클라이언트가 no-cache로 서버에 요청하면 프록시 서버는 no-cache이므로 원 서버에 요청을 전달한다.

원 서버는 적절한 응답을 내려준다.

프록시 캐시 서버가 원 서버에 요청을 보내야하는데 순간적으로 네트워크가 단절되어 접근이 불가하다면 설정에 따라 프록시 서버에서 캐시 데이터를 반환할 수 있다.

must-revalidate라면 원 서버에 접근이 불가할 때 504 Gateway Timeout 오류를 보낸다. 

 

예를들어 통장 잔고 등 중요한 정보가 원 서버를 못 탔다고 해서 예전 데이터로 뜬다면 큰 문제가 생기게 되고, must-revalidate를 써야 한다.