[ http ] 09. HTTP 헤더(2) - 캐시와 조건부 요청1
캐시 기본 동작
일단 캐시를 이해하기 위해서 캐시가 없을 경우를 봐보자
캐시가 없을 때
- 첫 번째 요청
1.1M의 star.jpg라는 그림을 클라이언트는 받게 된다.
그러면 첫 번째 요청이 끝나고 캐시가 없을 때의 두 번째 요청 시에는 어떻게 될까?
- 두 번째 요청
똑같은 크기의 응답을 보낼 것이다.
이렇게 캐시가 없을 때는 어떤 특징이 있는지 보면
- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
- 인터넷 네트워크는 매우 느리고 비싸다.
- 브라우저 로딩 속도가 느리다.
- 느린 사용자 경험
이제 캐시가 적용된 경우를 확인해보자
캐시 적용
- 첫 번째 요청
응답을 보내게 되고
캐시 저장소에 60초 유효한 캐시를 저장한다.
이제 이 상태에서 두 번째 요청을 보내면 어떻게 될까?
- 두 번째 요청
클라이언트는 캐시를 먼저 찾아보고 유효시간 안에 요청한 정보가 있으면 바로 캐시에서 가져온다.
이렇게 해서 캐시 적용시 특징은
- 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
- 비싼 네트워크 사용량을 줄일 수 있다.
- 브라우저 로딩 속도가 매우 빠르다.
- 빠른 사용자 경험
- 세 번째 요청(캐시 시간 초과)
이제 캐시 유효 기간이 초과된 경우 요청한다면 어떻게 될까?
캐시 유효 시간이 초과 됐으므로
처음 요청과 같게 된다.
캐시 시간 초과
- 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고. 캐시를 갱신한다.
- 이때 다시 네트워크 다운로드가 발생한다.
검증 헤더와 조건부 요청1
캐시 유효 시간이 초과해서 서버에 다시 요청하면 어떤 상황들이 있을까?
1. 서버에서 기존 데이터를 변경하지 않음
2. 서버에서 기존 데이터를 변경함
ex)
먼저 서버에서 기존 데이터를 변경하지 않았을 때를 봐 보자
1. 서버에서 기존 데이터를 변경하지 않음(캐시 시간 초과 시)
- 생각해보면 데이터를 전송하는 대신 저장해 두었던 캐시를 재사용 할 수 있다.
- 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요
- 검증 헤더 추가
데이터가 같다는 것을 검증 하기 위한 검증 헤더를 추가하고 첫 번째 요청을 봐보면
첫 번째 요청
요청을 받고
캐시에 저장한다.
두 번째 요청(캐시 시간 초과)
먼저 캐시를 확인하고 캐시가 시간 초과됐는지 확인하고 초과 됐다면 요청을 보내야 한다.
그런데 데이터 최종 수정일(2020년 11월 10일 10:00:00)이라는 데이터가 있는 것이 확인되었다. 그러면
요청을 서버로 보낼때 if-modified-since라는 헤더로 최종 수정일을 넘긴다.
그리고 서버가 이 날짜를 보고 수정일을 확인하고 수정이 안됐다면
기존 데이터를 그대로 쓰면 되므로 Body는 따로 보내지 않고 헤더만 보내게 된다.
이제 요청을 확인했으니 다시 60초 유효하고 브라우저는 캐시에서 해당 데이터를 이용하게 된다.
2. 서버에서 기존 데이터를 변경함
반대로 데이터가 변경되었다면 Last-Modified 를 변경하고 Body를 통해 바뀐 데이터를 전송해서 받으면 된다.
이제 정리를 해보면
- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답(body x)
- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
- 클라이언트는 캐시에 저장되어 있는 데이터 재활용
- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
- 매우 실용적인 해결책이다.
하지만 이 방법의 단점 중 하나는 1초 미만 단위로 캐시 조정이 불가하다는 점이다 이를 개선한 것으로 ETag가 있다.