[HTTP][HEADER][캐시와 조건부 요청]

캐시가 없을 때 

첫번 째 요청시 http헤더 0.1m http바디 1.0m 일 때 1.1m를 응답으로 반환하고 그 반환값이 브라우저에 나타나고,

두번째 요청시 똑같이 1.1Mbyte를 반환한다 매번 요청시 마다 1.1mbyte를 다운로드해야한다 그럴 경우

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

2.인터넷 네트워크는 매우느리고 비싸다

3.브라우저 로딩속도가 느리다(느린 사용자 경험)

 

캐시가 적용됐을때 cache-control (캐시가 유효한 시간(초))

첫번 째 요청시 http헤더 0.1m , http바디 1.0m일때 1.1를 응답으로 반환하고 그 반환값이 브라우저에 나타나고,

웹브라우저 안에 캐시저장소에 캐시유효시간만큼 저장소에 있다가 유효시간 내에 요청을 하면 따로 다운받지 않고 저장소에서 값을 가져옴(네트워크를 탈 필요가 없음)

1.캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도된다

2.비싼 네트워크 사용량을 줄일 수 있다.

3.브라우저 로딩 속도가 매우 빠르다(빠른 사용자 경험)

 

캐시 시간초과시

웹브라우저는 캐시저장소에서 유효시간 지난걸 확인후 서버에 요청을하게 됨 서버는 1.1m를 응답하며 2번과 똑같이 캐시 시간을 넣어서 보내줌, 캐시저장소에서는 기존에 있던 유효시간지난 캐시는 지워지고 새롭게 발급받은 캐시를 저장함

 

만약 똑같은 이미지를 새로 받을 경우 네트워크사용량도 느려지고 비싸질테니 기존에 있던 캐시저장소의 데이터값과 서버에서 응답해주는 데이터값이 똑같을 경우 새로받지않고 네트워크사용량을 줄이면서 이용할 방법이 있다. >> 검증헤더와 조건부 요청

데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.

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

>>서버에서 응답할때 데이터가 마지막에 수정된 시간 Last-Modified : 2022-10-10-10:00UTC 을 추가로넣어서 웹브라우저에 응답하고 캐시저장소에 캐시 유효시간 + 데이터 최종수정일이 함께 저장이된다.

웹브라우저에서 캐시 유효시간이 지난후 서버에 다시 데이터를 요청할 때 if-modified-since:2022-10-10-10:00UTC 를 함께 보낸다 서버에서 데이터 최종 수정일이 변경이 된지 안된지 날짜를 보고 확인후 변경이 안됏으면 HTTP헤더에 304Not Modified라고 적고 HTTP Body가 없이 0.1M(HTTP 헤더)만 전송함 >> 캐시저장소에서 응답결과를 재사용하고 헤더 데이터를 갱신 >> 캐시저장소에서 캐시를 사용해서 웹브라우저에 띄움

검증헤더와 조건부 요청 정리 

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

304Not Modified + 헤더 메타 정보만 응답(바디 x)

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

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

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

 

검증 헤더와 조건부 요청

검증 헤더 

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

Last-Modified, ETag

조건부 요청헤더

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

If-Modified-Since : Last-Modified사용

If-None-Match:ETag사용

조건이 만족하면 200 ok

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

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

캐시 : 2022년10월10일 10:00:00vs 서버 :2022년 10월10일10:10:00

200 OK ,모든 데이터 전송(Body포함) 전송 용량 1.1M(헤더 0.1m 바디 1.0m)

Last-Modified, If-Modified-Since 단점

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

날짜 기반의 로직 사용

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

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

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

 

ETag, If-None-Match

Etag(Entity Tag)

캐시용 데이터에 임의의 고유한 버전 이름을 달아둠

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

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

예) ETag : "aaaa" > ETag : "bbbb"

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

 

정리

캐시 제어 로직을 서버에서 완전히 관리

클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)

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

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

 

캐시제어 헤더

캐시-컨트롤(Cache-Control) : 캐시 제어

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

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

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

 

프라그마(Pragma) : 캐시제어(하위 호환)

익스프라이스 : 캐시 유효기간(하위 호환)

 

프록시 캐시

원 서버 직접 접근(예를들어 미국에 있는 서버에서 데이터를 전송 받는다할때 0.5초걸리지만 프록시 캐시를 적용시에는 미국에 있는 서버가 한국에 있는 서버에 데이터를 쏴주면 한국에 있는 웹 브라우저가 미국에 있는 서버에 갈 필요 없이 한국에 있는 프록시 캐시에서 데이터를 전송 받아오기 때문에 시간이 짧아진다.

캐시 지시어(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(HTTP1.0하위 호환)

Cache-Control : no-cache : 데이터는 캐시해도 되지만, 항상 원서버에 검증하고 사용(이름에 주의)

웹브라우저가 캐시저장소에서 캐시를 요청할때 no-cache + ETag가 붙어있으면 프록시 캐시서버로 요청하게 되고 프록시 캐시에선 nocashe가 붙어있으므로 원서버로 보냄(검증을위해) 그럼 원서버가 응답해주고 프록시캐시가 웹브라우저에 응답해주면 캐시저장소에서 웹브라우저로 캐시데이터를 응답값으로 줌

만약 프록시 캐시에서 원서버로 요청을 할 때 순간 네트워크 단절로 인해 원서버 접근이 불가할때 프록시 캐시에서 예전 정보라도 반환하게끔 설정을 해놓았으면 원서버의 데이터를 응답하지 않고 프록시 캐시에 남아있는 데이터를 응답값으로 웹브라우저에 보내줌

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

Cache-Control : must-revalidate : 캐시 만료후 최초 조회시 원 서버에 검증해야함 , 원서버 접근 실패시 반드시 오류가 발생해야함(504 Gateway timeout) , must-re validate는 캐시 유효 시간이라면 캐시를 사용함