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

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

 

1. 캐시 기본 동작

[캐시가 없을 때]

첫 번째 요청

두번째 요청 -> 서버에서 똑같이 요청 받아서 응답 내려줌

 

단점)

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

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

- 브라우저 로딩 속도가 느림

- 느린 사용자 경험

 

[캐시 적용]

- 캐시 유효한 시간 (cache-control: max-age)동안 star.jpg가 웹브라우저 + 브라우저 캐시에 응답결과를 저장

- 두 번째 요청때 캐시에서 먼저 확인하고 가져옴 

 

장점)

- 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨

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

- 브라우저 로딩 속도가 매우 빠름

- 빠른 사용자 경험

 

세번째 요청 - 캐시 시간 초과

- 똑같이 캐시 데이터 내려주고 캐시 덮어 씌우면서 캐시 초기화

- 이 과정에서 네트워크는 그대로 씀

 

캐시 시간 초과

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

- 이때 다시 네트워크 다운로드가 발생

 

* 캐시데이터와 서버데이터가 시간 초과되었어도 똑같을 때 데이터 다시 받을 필요가 있을까?

---

2. 검증 헤더와 조건부 요청1

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

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

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

 

상황) 캐시 만료후에도 서버에서 데이터를 변경하지 않음

- 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 가능

- 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요

 

[검증헤더 추가]

첫번째 요청

- 응답 헤더에 Last-Modified : 2020-11-10 10:00:00

- 응답 결과를 캐시에 저장 / 캐시 데이터 최종 수정일 2020-11-10 10:00:00

 

두번째 요청 - 캐시 시간 초과

- 캐시 최종 수정일 (Last Modified)

- 요청을 보낼때 if-modified-since 헤더 추가해서 보냄

- 서버에서 데이터 최종 수정일을 비교 (검증 가능)

(1) 수정이 안된 경우 -> 304 Not Modified / HTTP body가 없음

(2) 수정이 된 경우   -> 다시 응답 보내고 캐시 저장

 

정리)

- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면

- 304 Not Modified + 헤더 메타 정보만 응답 (Body X)

- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신

- 클라이언트는 캐시에 저장되어있는 데이터 재활용

- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드

- 매우 실용적인 해결책

---

3. 검증 헤더와 조건부 요청2

단점)

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

- 날짜 기반의 로직 사용

- 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우

- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

   ex) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고싶은 경우

 

ETag, if-None-Match

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

   ex) ETag: "v1.0", ETag: "a1b2c3"

- 데이터가 변경되면 이 이름을 바꿔 변경 (Hash를 다시 생성)

   ex) ETag: "aaa" -> ETag: "bbb"

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

 

[검증헤더추가]

ETag로 비교

 

정리)

- ETag만 서버에 보내서 같으면 유지 / 다르면 다시 받기

- 캐시 제어 로직을 서버에서 완전히 관리 (클라이언트는 단순히 이 값을 서버에 제공, 클라이언트는 캐시 매커니즘을 모름) 

   ex) 애플리케이션 배포 주기에 맞춰 ETag 갱신

         서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag 동일하게 유지

---

4. 캐시와 조건부 요청 헤더

(1) Cache-Control : 캐시 지시어 (directives)

 

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

- Cache-Control : no-cache : 데이터는 캐시해도 되지만 항상 원(origin)서버(캐시 프록시 서버가 아닌 찐서버)에 검증하고 사용

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

 

(2) Pragma

- Pragma : no-cache

- HTTP 1.0 하위호환

(잘 안씀)

 

(3) Expires

- 캐시 만료일을 정확한 날짜 지정 가능 -> 별로임, 초단위가 더 유연함

- 지금은 더 유연한 Cache-Control:max-age 권장 (둘이 같이 쓰면 Expires 무시)

 

검증 헤더

- ETag: "v 1.0", ETag: "abc"

- Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT

 

조건부 요청 헤더

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

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

---

5.  프록시 캐시

원 서버 직접 접근 (origin server)

프록시 캐시 도입

* 사람이 많이 보는 영상이 다운이 빠른 이유

* 웹브라우저 (private캐시) , 프록시 캐시 서버(public 캐시)

 

Cache-Control: public : 응답이 public 캐시에 저장되어도 됨

Cache-Control: private : 응답이 해당 사용자만을 위한것, pirvate 캐시에 저장해야함 (default)

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

Age: 60 (HTTP 헤더) : origin 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

---

6.  캐시 무효화

확실한 캐시 무효화 응답

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 VS must-revalidate]

1) no-cache

 

* no-cache로 보냈는데 순간적으로 원서버와의 네트워크 단절된다면?

-> 옛날 데이터라도 보여주자는 설정이 있음 (응답 가능) 200 OK (or Error)

 

2) revalidate

- 원 서버에 접근할 수 없는 경우 항상 오류가 발생해야함!

- 응답) 504 Gateway Timeout