검증 헤더와 조건부 요청

 

📒 검증 헤더와 조건부 요청

다시 요청한 데이터와 이전에 요청했었던 데이터가 같은지 다른지 어떻게 확인하지?

그래서 등장하는 검증 헤더!

검증 헤더에는 크게 2가지가 있는데, Last-Modified와 ETag.

📌 검증 헤더 - Last-Modified

📝 과정

1. 클라이언트의 요청에 서버가 이렇게 검증 헤더를 추가해서 응답을 보냄.

HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60
Last-Modified: 2022년 1월 12일 10:00:00
Content-Length: 34012

lkj123kljoiasudlkjaweioluywlnfdo912u34ljko98udjklasl kjdfl;qkawj9;o4ruawsldkal;skdjfa;ow9ejkl3123123

'Last-Modified' 라는 데이터가 마지막으로 수정된 시간을 추가해서!!

2. 그러면 클라이언트는 데이터의 최종 수정일을 추가로 캐시에 저장함.

3. 이후 다시 요청을 보낼 때, 캐시를 확인해서 'Last-Modified'가 있으면 요청에 if-modified-since: 2020년 11월 10일 10:00:00 라는 요청 헤더를 추가해서 보냄. -> 이런 요청이 조건부 요청

GET /fanxyellow.jpg
if-modified-since: 2022년 1월 12일 10:00:00

4. 서버가 갖고있던 데이터의 최종 수정일과 클라이언트가 보낸 최종 수정일을 비교해서 확인함.

5-1. 수정 안됐으면? 실패! HTTP Body 빼고 304 Not Modified 를 추가한 응답을 보냄.

HTTP/1.1 304 Not Modified
Content-Type: image/jpeg
cache-control: max-age=60
Last-Modified: 2022년 1월 12일 10:00:00
Content-Length: 34012

* 여기서 중요한 것은 HTTP Body가 없다는 것!!! 왜냐하면 수정된 것이 없으니까! 헤더만 응답으로 보내!

클라이언트가 '304 Not Modified'를 확인하면 cache-control 헤더값 갱신하고 캐시 다시 셋팅해서 브라우저 캐시에서 바로 응답 결과를 재사용!

5-2. 수정 됐으면? 성공! 200 OK로 Body포함해서 모든 데이터 다시 보냄. 수정됐으니까 수정본 보내야지!

 

📝 정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면, 304 Not Modified + 헤더 메타 정보만 응답 (Body X) 

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

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

• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

 

📝 단점

• 1초 미만(0.x초) 단위로 캐시 조정 불가능 

• 날짜 기반의 정해진 로직만 사용하므로, 

• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 결국 데이터 결과는 똑같은데 처음부터 다 다시 받아야 함.

 

그래서, 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 (예를 들어 스페이스나 주석처럼 크게 영향이 없는 변경에서는 캐시를 유지하고 싶은 경우)에는 ETag를 사용하면됨.

 

📌 검증 헤더 - ETag

📝 ETag

• Entity Tag

• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 .
예) ETag: "v1.0", ETag: "a2jiodwjekjl3"
• 데이터가 변경되면 이 이름을 바꾸어서 변경함. (Hash를 다시 생성) 

예) ETag: "aaaaa" -> ETag: "bbbbb"

 

📝 과정

 1. 클라이언트가 요청하면 서버가 이렇게 생긴 ETag를 포함한 응답을 보냄.

HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60
ETag: "aaaaaaaaaa"
Content-Length: 34012

lkj123kljoiasudlkjaweioluywlnfdo912u34ljko98udjklasl kjdfl;qkawj9;o4ruawsldkal;skdjfa;ow9ejkl3123123

2. 클라이언트가 역시 응답 결과를 캐시에 저장

3. 이후 요청에서 캐시 시간 초과됐으면 'If-None-Match' 헤더로 ETag를 포함해서 다시 요청을 보냄.

GET /fanxyellow.jpg
If-None-Match: "aaaaaaaaaa"

4. 서버가 받은 ETag와 원래 ETag를 비교

5-1. 수정 안됐으면? 실패! HTTP Body 빼고 304 Not Modified를 추가한 응답을 보냄. 

5-2. 수정 됐으면? 성공! 200 OK로 Body포함해서 모든 데이터 다시 보냄.

 

📝 정리

• 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기! 

• 캐시 제어 로직을 서버에서 완전히 관리 

• 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름) 

• 예) 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지 -> 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

---

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

📝 검증 헤더 (Validator)

• ETag: "v1.0", ETag: "asid93jkrh2l" 

• Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT

 

📝 조건부 요청 헤더

• If-Match, If-None-Match: ETag 값 사용 

• If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용