캐시 검증헤더와 조건부 요청
1.캐시 유효시간이 초과해서 서버에 다시 요청하면 다음 두가지 상황이 나타난다.
-서버에서 기준데이터를 변경함 (정말 데이터가 바뀐경우)
-서버에서 기준데이터를 변경하지 않음
캐시 시간초과(이미 클라이언트가 가진 데이터를 또 받아야 하는지 검증)
검증헤더
-캐시 만료 후에도 서버에서 데이터를 변경하지 않음
-생각해보면 데이터를 전송하는 대신에 저장해 두었다 캐시를 재사용 할수도 있다,
-단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 방법이 필요하다.
캐시 검증헤더 추가
첫번째 요청
(request)
Get /star.jpg
(response)
HTTP/1.1 200 ok
content-type : image/jpeg
cache-controller : max-age=60
Last-Modified : 2020년 11월 10일 , 10:00:00 //데이터가 마지막에 수정된 시간
content-length : 34012
서버에서 위 결과대로 캐시저장소에 캐시를 저장한다.
60초간 유효하고
데이터의 최종수정일이 2020년 11월 10일 , 10:00:00로 기록되어있다
두번째 요청 - 캐시 시간초과
(request)
Get /star.jpg
요청시에 캐시저장소를 뒤지는데 만약 캐시가 만료되었다면
그땐 데이터의 최종 수정일을 확인한다. (2020년 11월 10일 , 10:00:00)
캐시 시간초과로 인해 클라이언트는 다시 서버에 요청을 보내게 되는데
이때 요청HTTP 헤더에 캐시의 최종 수정일을 같이 보낸다.
(request)
Get /star.jpg
if-modified-since : 2020년 11월 10일 , 10:00:00
그럼 최종수정일값을 서버쪽 데이터와 비교한다.
(server)
last-modified : 2020년 11월 10일 , 10:00:00
서버는 if-modified-since 와 last-modified를 비교하고 이를 검증이라 한다.
만약 이 값이 같다면 데이터를 수정하지 않고 응답하는데
(response)
HTTP/1.1 304 not modified
content-type : image/jpeg
cache-control : max-age=60
last-modified : 2020년 11월 10일 , 10:00:00
content-length : 34012
* if-modified-since 와 last-modified가 동일할 경우 메시지를 반환하지 않는다.
또한 이미지를 다시 다운로드 하지않게 때문에 용량도 소모하지 않는다.
304는 변경한 값이 없을때 반환 last modified를 다시 반환한다.
이때 HTTP BODY는 포함시키지 않는다.
그럼 캐시가 위 응답을 받고 다시 캐시를 60로 유효하게 하고
if-modified-since를 갱신하게 된다,
검증해더와 조건부 요청
정리
-캐시 유효 시간이 초과해도 서버의 데이터가 갱신되지 않으면 데이터를 다시 다운받지 않게 한다.
-304 not found + 헤더 메타 정보만 응답 (메시지 바디를 보내지 않음 , 데이터 축소)
-클라이언트는 서버가 보낸 응답 헤더 정보를 캐시의 메타정보 갱신
-결과적으로 네트워크 다운로드가 발생은 되자만 용량이 적은 헤더 정보만 다운로드
-매우 실용적인 해결책
(request)
if-modified-since
이 값과
(response)
last-modified
이 값을 비교해 갱신되었는지 확인하는것을 검증 헤더라 한다.
f12에서 상태값이 진한건 서버 연한건 캐시에서 불러온 값을 의미한다,
'HTTP' 카테고리의 다른 글
3월 13일 HTTP 캐시 조건부 헤더 (0) | 2023.03.13 |
---|---|
3월 13일 HTTP 캐시 검증헤더와 조건부 요청2 (0) | 2023.03.13 |
3월 13일 HTTP 헤더2 (0) | 2023.03.13 |
3월 10일 HTTP 쿠키 (0) | 2023.03.10 |
3월 10일 HTTP 일반정보 (0) | 2023.03.10 |