반응형

검증 헤더와 조건부 요청1

  • 캐시 유효 시간이 초과해서 서버에 다시 욫어하면 다음 두 가지 상황이 나타난다.
    • 1. 서버에서 기존 데이터를 변경함
    • 2. 서버에서 기존 데이터를 변경하지 않음

 

이렇게 두 가지 상황이 나타난다.

1번의 경우, 기존 데이터가 변경되었으므로, 다운을 통해 캐시를 갱신 해서 고객에게 보여주는 것이 맞을 것이다.

그런데, 2번처럼, 만약에 60초를 초과해서 서버에 다시 요청을 했는데,
기존이랑 똑같은 별사진을 다시 다운로드 받는다면, 비효율 적일 것이다.

이러한 비효율적인 문제를 해결하는 것이 "검증헤더와 조건부 요청" 이다.

캐시 시간 초과되었을 때, 캐시 만료후에도 서버에서 데이터를 변경하지 않았다면,

  • 캐시 만료후에도 서버에서 데이터를 변경하지 않음
  • 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.
  • 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다.

 

GET/star.jpg를 요청하면, 서버에서 cache-control;max-age=60 이라고 헤더에 캐시유효시간을 지정해서 내려준다.
그리고 헤더에 추가로 Last-Modified: 2020년 11월 10일 10:00:00 이라고 추가하면,
이 데이터가 마지막에 수정된 시각을 알려주는 것이다.(예제라 한글로 적었으나, UTC 표기법으로 적어야한다.)

이렇게 해서 응답을 내려주면,

그러면, 웹브라우저는,
응답 결과를 당연히 캐시에 저장하고,
60초 유효하다는 것도 저장한다.
그리고 하나를 더하는데, 이 데이터의 최종 수정일은 2020년 11월 10일 10시다 라는 "Last-Modified" 응답까지 기록한다.

 

60초가 지나지 않았다면, 요청을 할 때 해당 캐시를 사용할 것이다.

그런데, 만약에 60초(캐시유효시간)가 지났다고 가정해보자.

 

HTTP 요청을 보낼때, 60초가 되었으므로 다시 서버에 요청을 보내야 하는데,
"이 캐시를 보니까 "Last-Modified"가 있네?" 라고 하면,
웹브라우저가 서버에 요청을 보낼 때,
if-modified-since 라는 HTTP요청 헤더를 붙인 다음에, 여기에다가 Last-Modified의 날짜를 붙인다.
"내가 캐시로 들고있는 데이터의 최종 수정일은 이거에요!"라고해서 서버에 넘긴다.

그러면 서버에서 해당 요청을 받았는데,
"if-modified-since라고 왔네?" 라고 하면서 서버에서 어떻게 하냐면,

"서버인 나에게 star.jpg가 있는데, 내가가진 star.jpg의 데이터 죄종 수정일이 2020년 11월 10일 10시야"
클라이언트가 요청한 데이터의 최종 수정일과 서버가 가진 데이터의 최종 수정이 되었는지 안되었는지 검증을 할 수 있는 것이다.

두개의 날짜가 같다면, "날짜가 똑같으니까 너꺼는 아직 써도돼!" 라고 알려줄 수 있는 것이다.

수정이 안되면, HTTP 응답을 만들 때, 304 Not Modified 를 내보낸다.
그리고, cache-control은 그대로 가고, Last-Modified를 다시 내보낸다.

중요한건, HTTP Body가 없다.

HTTP 헤더가 대략 0.1M,
HTTP 바디가 대략 1.0M 였는데,

HTTP 바디를 빼버린 것이다.

왜냐하면, 수정된 것이 없기 때문이다.

그렇게 해서 응답을 만들어서 전송한다.

기존에는 1.1M로 응답했는데, 이제는 바디를 다 빼고 헤더부분만 전송하는 것이다.

그러면 네트워크 부하가 줄어들 것이다.

 

그렇게하면,웹브라우저에서 받았을 때,

"304 Not Modified네? 이거는 이 캐시가 안바꼇으니까 내가 써도 되는구나!"라고 인식을 하고,
cache-control (캐시유호시간)값을 갱신해서 캐시를 다시 세팅하고,

이제 이 캐시에서 데이터를 불러와서 사용하게 된다.

 

검증 헤더와 조건부 요청

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

 

Last-Modified 이부분이 검증헤더이다.

이게 조건부 요청이고,

 

이 두개를 조합해서 이 캐시가 진짜 서버에서 갱신이 되었는지 안되었는지 맞춰보고 확인할 수 있는 것이다.

 

실제로 이미지를 새로고침해보면 304를 확인할 수 있다.

반응형