HTTP 헤더2 - 캐시와 조건부 요청(검증 헤더와 조건부 요청1)

반응형

캐시 시간 초과

 

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

 

 

캐시 시간 초과

 

- 캐시 만료후에도 서버에서 데이터를 변경하지 않는다.

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

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

캐시가 만료되서 클라이언트에서 서버로 다시 요청했는데 알고보니까 서버에서 데이터를 안 바꾼겁니다. 여기서 잘 생각해보면 데이터를 완전히 전송하는 대신에 저장해 두었던 로컬 캐시를 재사용할 수 있습니다.왜냐하면 데이터가 안 변했기 때문입니다. 그런데 클라이언트에 있는 이 캐시 데이터랑 서버에 있는 캐시 데이터가 안 바꼈다는 사실을 확인할 수 있는 방법이 필요합니다.

 

 

 

그래서 이 검증헤더라는게 들어가게 됩니다. Last-Modfied라는 것을 추가할 수 있게 됩니다. 저것은 데이터가 마지막에 수정된 시간을 표시해주는겁니다. 시간은 UTC 표기법으로 적힙니다.

웹 브라우저는 이렇게 작동하게 됩니다. 응답 결과를 캐시에 저장해주고요. 60초 유효하다고 적어놓고 하나 더 적어 놓게 됩니다. 데이터 최종 수정일을 넣게 됩니다.

 

 

 

60초가 지나면 이 검증헤더가 있는데요. 60초가 초과 되었으니까 다시 서버에 요청을 보내야겠죠. 위 캐시를 보니까 Last-Modified가 있으니 요청에 if-modified-since라는 http 요청 헤더를 붙인 다음에 거기에다가 날짜 헤더를 붙이게 됩니다. 

그러면 서버에서는 그 데이터가 수정이 되었는지 안 되었는지 검증을 할 수 있게 되는겁니다. 보니까 날짜에 변경이 거의 없으면 데이터가 수정이 안된 겁니다.

 

 

수정이 안되면 위처럼 HTTP 응답을 만들 때 304 Not Modified라고 내보내요. 이거는 변경 된게 없다고 보내는겁니다. 그리고 중요한게 있습니다! 그거는 HTTP Body가 없습니다. 그게 무슨 말이냐면 위 사진 예를 보면 0.1M인 HTTP 헤더는 놨두고 1.0M인 HTTP 바디는 그냥 놨두는겁니다. 왜냐하면 바뀐점이 없기 때문입니다. 이제는 바디 빼고 헤더부분만 보내니 네트워크 부화가 매우 줄겠죠.

 

서버에서 웹 브라우저를 받을 때, 304 Not Modified구나. 응답 결과를 재사용하게 됩니다.

 

 

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

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

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

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

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

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

- 매우 실용적인 해결책