✴️ 검증 헤더와 조건부 요청
🤔 캐시 시간이 초과되면?
캐시 유효 시간이 초과해서, 클라이언트가 서버에 데이터를 다시 요청하면 다음 두 가지 상황이 나타난다.
- 서버에서 기존 데이터를 변경함 💛 -> 💚
- 서버에서 기존 데이터를 변경하지 않음 💛
서버에서 기존 데이터를 변경하지 않았다면, 동일한 데이터를 반복해서 전송하는 대신 저장해두었던 캐시를 사용하면 된다.
🤔 그렇다면 서버가 기존 데이터를 변경하지 않았는지는 어떻게 확인할 수 있을까?
이때는 서버 데이터와 캐시 데이터가 같은지 검증하는 데이터인 검증 헤더를 사용한다❗️
1️⃣ Last-Modified
서버는 클라이언트의 요청에 응답하면서 응답 메세지에 Last-Modified 라는 검증 헤더를 추가할 수 있다. 이는 응답 데이터가 마지막으로 수정된 시간을 의미한다.
예시는 한글로 작성되어 있지만, 실제로는 UTC 표기법을 따라야 한다.
이 응답 메세지를 받은 웹 브라우저는 브라우저 캐시에 응답 결과를 저장하고, 캐시 유효 시간과 함께 데이터의 최종 수정일도 저장한다.
이제 캐시 유효 시간이 초과된 상황을 살펴보자.
웹 브라우저는 GET 요청을 하면서 if-modified-since 라는 헤더를 통해 캐시가 가지고 있는 데이터의 최종 수정일을 서버에 전달한다. 이를 조건부 요청이라고 한다.
만약 if-modified-since 값과 서버가 가지고 있는 데이터의 최종 수정일이 동일할 경우 서버는 우선 클라이언트에게 304 Not Modified 상태 코드를 응답하는데, 이는 데이터의 상태 변경이 없다는 뜻이다. 따라서 웹 브라우저는 브라우저 캐시에 저장되어 있는 캐시를 불러와 사용하게 된다.
또한 응답 메세지는 HTTP 본문 없이 헤더만 포함해서 전송한다. 따라서 네트워크 부하가 크게 감소하게 된다는 장점이 있다.
If-Modified-Since 정리
1. 데이터 미변경 예시
- 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00
304 Not Modified를 응답, 헤더 데이터만 전송. (BODY 미포함)
2. 데이터 변경 예시
- 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
200 OK를 응답, 모든 데이터 전송. (BODY 포함)
3. 단점
- 1초 미만 단위로 캐시 조정이 불가능.
➡️ 하지만 1초 미만 단위로 캐시를 조정할 일은 거의 없다고 한다.- 날짜 기반의 로직 사용.
- Ex1> 데이터를 수정해서 날짜가 다르지만, 데이터 내용은 똑같은 경우.
➡️ 이 경우에도 데이터를 전부 재다운로드한다.- Ex2> 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
- 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
2️⃣ E-Tag
E-Tag는 Entity Tag의 약자로, 캐시용 데이터에 임의의 고유한 버전 혹은 이름을 달아두기 위해 사용한다.
Ex) ETag: "v1.0", ETag: "a2jiodwjekjl3"E-Tag는 데이터가 변경되면 Hash를 다시 생성해서 값을 변경한다. 해시는 수정 여부와는 상관 없이, 컨텐츠의 내용이 달라졌는지를 체크한다. 단순하게 정리하면, E-Tag만 보내서 같으면 유지하고, 다르면 다시 받는다.
E-Tag도 Last-Modified와 마찬가지로 서버의 응답 메세지에 ETag 헤더를 사용한다.
이 메세지를 받은 클라이언트는 브라우저 캐시에 응답 데이터를 저장하며, 캐시 유효 시간과 E-Tag를 함께 설정한다.
만약 캐시 유효 시간이 지났다면, 웹 브라우저의 요청 메세지에 If-None-Match 헤더를 통해 캐시가 가지고 있는 E-Tag를 전송한다.
서버가 가지고 있는 E-Tag와 비교해봤을 때 동일하다면 데이터가 수정되지 않은 것이다.
이 경우에 서버는 304 Not Modified 상태 코드와 함께 HTTP 본문 없이 헤더만 클라이언트에게 전송하게 되고, 웹 브라우저는 브라우저 캐시에 저장된 캐시의 유효 기간을 다시 갱신한다.
따라서 이후 웹 브라우저에서 동일한 데이터를 요청했을 때 캐시 유효 시간 이내라면 캐시를 사용할 수 있게 된다.
E-Tag 정리
진짜 단순하게
E-Tag만 서버에 보내서 같으면 유지, 다르면 다시 받기!
- 캐시 제어 로직을 서버에서 완전히 관리한다.
- 클라이언트는 단순히 E-Tag 값을 서버에 제공하기만 한다.
➡️ 클라이언트는 캐시 메커니즘을 모르기 때문.- Ex1> 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 E-Tag를 동일하게 유지한다.
- Ex2> 애플리케이션 배포 주기에 맞추어 E-Tag를 모두 갱신한다.
Reference
