3월 13일 HTTP 캐시 검증헤더와 조건부 요청2

캐시 검증헤더와 조건부 요청2

 

검증헤더

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

-lost modified ,  ETag

 

조건부 검증헤더

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

-if-modified-since : last-modified 사용

-if-modified-since : ETag 사용

-조건을 만족하면 200 ok

-조건을 만족하지 않으면 304 not modified

 

if-modified-since : 이후에 데이터가 수정되었으면? (굳이 따지면 실패)

-데이터 미변경 예시

-캐시 : 2020년 11월 10일 10:00:00 , 서버: 2020년 11월 10일 10:00:00 (미변경)

-304 not modified 헤더 데이터간 전송 (body 미포함)

-전송 용량 0.1m (헤더 0.1 , body 1.0 M)

 

데이터 변경 예시(성공)

-캐시 : 2020년 11월 10일 10:00:00 , 서버: 2020년 11월 10일 11:00:00 (변경)

-200 ok 모든 데이터 전송(body 포함)

-전송 용량 1.1m (헤더 0.1 , body 1.0 M)       

 

last-modified , if-modified-since 단점

-1초미만 (0.?초) 단위로 캐시 조정이 불가능 (이 경우도 다르다고 판단한다)

-날짜 기반의 로직사용

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

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

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

ETag , if-none-match (시간이 아니라 데이터로 판단)

-ETag(Entity Tag) (버전값으로 비교)

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

ex) ETag : "v10" , ETag : "aJiodwi3~"

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

ex) ETag:"a" -> ETag:"b"

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

 

검증헤더 추가, 첫번째 요청

(request)

Get /star.jpg 

 

(response)

HTTP/1.1 200 ok

content-type : image/jpeg

cache-control : max-age=60

ETag : "aa"

content-length : 34012

 

(message)(ETag:"aa")

 

60초가 경과된 후 두번째 요청

(request)

Get /star.jpg

if-none-match : "aa"

(매칭하지 않아야 true)

 

(response)

ETag : "aa"

 

캐시에서 조회

응답결과를 재사용 , 헤더 데이터 갱신 , 시간 연장

 

(response)

HTTP/1.1 304 not modified

content-type : image/jpeg

cache-control : max-age=60

ETag : "aa"

content-Length : 34012

 

(ETag : "aa" 가 같아서 BODY가 없음)

 

ETag , If-none-Match

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

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

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

 

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

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