HTTP

20240515 HTTP (9) - 캐시와 검증 헤더와 조건부 요청(Last-Modified)

개발자 백구 블로그 2024. 5. 15. 13:05

캐시가 없다면?

- 데이터가 변경되지 않아도 계속 네트워크를 통해 데이터를 다운로드 받아야 한다.

- 인터넷 네트워크는 상대적으로 PC인메모리나 하드데스크에 비해 매우 느리고 비싸다.

- 브라우저 로딩 속도가 느리다.

 

하지만 캐시를 적용한다면?

캐시가 없을 경우와 다르게 한번 요청 한 값을 브라우저 캐시 저장소에 저장하고 유효한 시간(cache-control) 동안 유효하게 된다. 그럼 후에 두 번째 요청을 할 때 캐시를 먼저 찾아본 후, 유효시간 내라면 캐시에서 바로 가져올 수 있다.

 

그래서 캐시를 적용하면 위의 문제들이 해결이 된다!

- 캐시 유효기간동안 네트워크를 사용하지 않아도 된다.

- 비싼 네트워크 사용량을 줄일 수 있다.

- 브라우저 로딩 속도가 매우 빠르다.

 

단, 유효시간이 지난다면 어떻게 되는 것일까?

사실 서버가 가지고 있는거랑 캐시가 가지고 있는 것이 다를 수 있으니,, 

마찬가지로 다시 한번 서버에 요청을 하고 다시 유효시간을 받아서 해야한다.

즉, 캐시 유효 시간이 초과가 된다면 다시 한번 서버를 통해 데이터를 조회해야하고 캐시를 갱신해야 하므로 네트워크 다운로드를 또다시 해야한다.

 

하지만 만약에 같다면? 이번에 요청한거와 유효 시간이 지나 다시 한번 요청한 결과물이 같다면,, 다시 한 번 다운로드 하는게 과연 효율적일까?

 

데이터를 전송하는 대신에 저장을 해 두었던 캐시를 재사용하면 되지 않을까??

대신 클라이언트의 데이터와 서버의 데이터가 같다는 조건이 성립해야하므로 이를 확인할 수 있는 무언가의 방법이 필요하지 않을까?

 

그래서 검증 헤더를 추가하게 되었다.

아 참고로 지금 한국어로 되어 있는 표기가 잇는데 편의상 이렇게 표시해둔것이고

보통은 영어로 Thu, 04 Jun 2020 07:19:24 GMT 이런식으로 작성된다.

 

 

 

또한 캐시가 가지고 있는 데이터 최종 수정일과 비교하여 바뀐 것이 없다면(조건부 요청),

 

 

 

 

요청을 했는데 변경한게 없다!! 싶으면 304 를 보내주고 body는 없이 전송을 한다. 그렇게 되면 네트워크 부하가 확 줄게 된다.

 

 

이는 캐시값이 바뀌지 않았으니 그대로 써도 된다는 뜻을 가지고 있다.

응답 결과를 재사용, 헤더 데이터를 갱신하여 캐시를 다시 세팅을 해주고 이 캐시에서 데이터를 불러와서 조회하게 된다.

 

 

요약하자면 캐시 유효 시간이 초과하게 되더라도 만약 서버의 데이터가 아무런 변화가 없어 갱신이 되지 않았으면 304 Not Modified라는 메시지와 함께 헤더 메타 정보만 응답한다. 이때 바디 값은 제외된다. 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신하게 되고 캐시에 저장되어 있는 데이터를 재활용하게 된다. 결과적으로는 네트워크 다운로드가 발생하는 것은 변하지 않지만 비교적 용량이 적은 헤더 정보만 다운로드 하므로 부하를 줄일 수 있어 실용적인 해결책이라고 볼 수 있다. 

 

보통 검증 헤더는 Last-Modified와 ETag를 많이 사용하는데, 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터를 의미한다. 

 

이게 맞는지 확인하는 것이 조건부 요청 헤더인데,

이는 검증 헤더로 조건에 따른 분기가 있으며,,

If- Unmodified-Since <->If-Modified-Since: Last-Modified 를 같이 사용하고,

If-Match  <->  If-None-Match: ETag를 같이 사용한다. 

 

조건을 만족하면 200 OK 메시지가 뜨고 조건이 만족하지 않다면 304 Not Modified 메시지가 뜬다.

 

If-Modified-Since: Last-Modified 는 이후에 데이터가 수정되었으면? 이라는 의미로

예시를 들자면,

캐시와 서버의 최종 수정일이 같을 경우 실패한 것으로  304 Not Modified , 바디를 미포함한 헤더 데이터만 전송한다.

즉, 전송용량은 0.1M(헤더 0.1M, 바디 1.0M)

 

반대로 캐시와 서버의 최종 수정일이 다를 경우 200 OK, 바디를 포함한 모든 데이터를 전송한다.

즉, 전송용량은 1.1M(헤더 0.1M, 바디 1.0M)

 

하지만 이도 단점이 있는데,,

 

- 최대할 수 있는 단위가 초단위이므로 1초 미만의 단위로는 캐시 조정이 불가능하다.

- 날짜 기반의 로직을 사용 한다.

- 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 같은 경우에는 어찌할 바가 없다.

- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

  • 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

 

이러한 단점에 있어서

ETag라는 새로운 검증 헤더와 조건부 요청이 도입됐다..

 

이는 다른 게시물에서 정리해볼 예정이다!!!!

 

후 하나 정리하는데 새로운 것들이 있어서 복잡하네,, 그래도 구멍난 내 지식에 조금이라도 도움이 되고 있으니 

포기하지말고 해보자ㅏ