NetWork[Cahe]
Cache
캐시는 이전에 요청한 데이터를 저장해두었다가, 동일한 요청이 다시 발생할 때 저장된 데이터를 반환시켜주는 기술입니다.
즉, 식당에서 늘 시켜먹던 메뉴를 직원이 손님을 알아보고 손님에게 물어보지 않고 미리 주문해주는 것과 유사합니다.
이로인해 캐시를 사용하게 되면 이전에 저장해 두었던 데이터를 꺼내기만 해서 사용하기 떄문에, 트래픽을 줄일수 있고, 성능이 향상된다는 장점을 가지고 있습니다.
이를 통해 중복된 작업을 최소화하고 사용자에게 빠르고 효율적인 서비스를 제공할 수 있습니다.
Cache를 적용하지 않는 경우
동작 과정
- 첫번쨰로 요청이 옵니다
- 서버에서는 요청 메세지를 받고, 이에 맞는 데이터 새로 만들어 반환합니다.
- 두번쨰로 같은 요청이 들어옵니다.
- 저장된 데이터가 없기 때문에 데이터를 새로만들어서 반환합니다.
이처럼 Cache를 적용하지 않는경우, 같은 요청이 반복적으로 들어와도 저장해놓은 데이터가 존재하지 않기 떄문에, 반복적으로 새로운 데이터를 만들어 반환합니다.
이로 인해 트래픽과 서버부하가 높아질 수 있습니다.
Cache를 적용하는 경우
동작 과정
- cache-control: max-age= 헤더를 추가해야 합니다.
- 첫번째로 요청이 들어옵니다
- 서버에서는 요청 메세지를 받고, 이에 맞는 데이터를 새로 만들어 반환합니다.
- 두번째로 같은 요청이 들어옵니다.
- 서버는 캐시 유효시간을 검증하고, 유효하다면 브라우저 캐시에서 조회합니다.
- 조회한 캐시 데이터를 반환합니다.
캐시를 사용할 경우, 캐시 가능 시간동아 네트워크를 사용하지 않아도 되는 장점이 있고,또한 트래픽을 최적화할 수 있으며, 네트워크 사용량 또한 줄일 수 있습니다.
이로 인해 브라우더 로딩속도가 매우 빠르다는 장점을 가져올 수 있습니다.
하지만 캐시 유효 시간이 초과하면, 다시 서버를 통해 데이터를 조회하고, 캐시를 갱신하게 됩니다.
캐시 시간 초과
서버에서 기존 데이터를 변경하는 경우
- 서버에서 기존 데이터를 변경하는 경우, 일반적으로는 해당 데이터에 대한 캐시의 유효시간이 만료된 후, 클라이언트가 해당 데이터를 요청할 때 서버는 변경된 데이터를 새로 만들어서 반환합니다.
서버에서 기존 데이터를 변경하지 않는 경우 - Last-Modified
- 서버에서 기존 데이터를 변경하지 않는 경우는 저장해 두었던 캐시를 재사용 할 수 있습니다.
- 재사용 하기 위해서는 검증헤더인 Last-Modified를 추가 해야합니다.
- Last-Modified : 마지막으로 데이터가 변경된 시간입니다.
- 단점
- 1초 미만 단위로 캐시 조정이 불가능합니다.
- 날짜 기반의 로직을 사용합니다.
서버에서 기존 데이터를 변경하지 않는 경우 - ETag
- ETag 방식은, 캐시용 데이터에 임의로 고유한 버전 이름을 달아두고 ETag가 같으면 유지, 다르면 다시 받는 방식입니다.
- 데이터가 변경되면 이 이름을 변경합니다.(Hash 재 생성)
- 동작 과정은 Last-Modified와 유사하지만, 다른점은 데이터 최종 수정일 대신 ETage의 버전이름으로 비교해서 동작합니다.
동작 과정
검증 과정 - Last-Modified
- 첫 번째로 클라이언트가 서버로 요청 메세지를 전송합니다.
- 서버는 검증 헤더(Last-Modified)를 응답 헤더에 추가하고, 브라우저 캐시에 저장을 합니다.
- 클라이언트가 브라우저 캐시를 조회할때 캐시 시간 초과가 발생합니다.
- 클라이언트는 서버로 다시 요청 메세지를 전송하는데 if-modified-since: 2020년 11월 10일 10:00:00 라는 헤더를 추가해서 전송합니다.
- 서버에서는 if-modified-since: 2020년 11월 10일 10:00:00 라는 헤더를 읽고, 브라우저 캐시의 데이터 최종 수정일과, 서버 데이터의 최종 수정일을 비교합니다. 이때 데이터 수정일이 같으면, 데이터가 변경되지 않았음을 파악합니다.
- 데이터가 추가적으로 변경되지 않았음으로 서버에서는 HTTP body를 비워두고 헤더만 작성하여 클라이언트에게 304(Not Modified) 상태코드를 반환합니다.
- 클라이언트는 304 상태코드를 받으면 캐시된 데이터는 그대로 사용하고, 서버로부터 새로운 데이터를 전달받지 않습니다.
- 클라이언트는 브라우저 캐시에서 데이터를 조회하여 사용합니다.
검증 과정 - ETag
첫 번째로 클라이언트가 서버로 요청 메세지를 전송합니다.
서버는 검증 헤더(Etag)를 응답 헤더에 추가하고, 브라우저 캐시에 저장합니다.
클라이언트가 브라우저 캐시를 조회할때 캐시 시간 초과가 발생합니다.
클라이언트는 서버로 다시 요청 메세지를 전송하는데 If-None-Match: “고유한-ETag-값” 헤더를 추가해서 전송합니다.
서버에서는 If-None-Match 헤더를 읽고, 브라우저 캐시의 데이터 ETag 값과 서버 데이터의 ETag 값을 비교합니다. 이때 ETag 값이 같으면 데이터가 변경되지 않았음을 파악합니다.
데이터가 추가적으로 변경되지 않았음으로 서버에서는 HTTP body를 비워두고 헤더만 작성하여 클라이언트에게 304(Not Modified) 상태코드를 반환합니다.
클라이언트는 304 상태코드를 받으면 캐시된 데이터는 그대로 사용하고, 서버로부터 새로운 데이터를 전달받지 않습니다.
클라이언트는 브라우저 캐시에서 데이터를 조회하여 사용합니다.
결론
데이터가 자주 변하는 경우에는 캐시를 사용하는 것이 효과적이지 않습니다.
왜냐하면 데이터가 자주 갱신되므로 캐시된 데이터가 빈번하게 무효화되고, 클라이언트는 자주 변경되는 데이터를 새롭게 요청해야 합니다.
이러한 상황에서는 캐시된 데이터를 사용함으로써 실질적인 성능 향상이 어렵기 때문입니다.
반면에 데이터가 자주 변하지 않고 상대적으로 변동이 적은 경우에는 캐시를 적용하여 클라이언트와 서버 간의 효율적인 데이터 전송을 이끌어낼 수 있습니다.
불필요한 데이터 요청을 방지하고 네트워크 트래픽을 감소시키는 데 도움이 됩니다.
클라이언트는 캐시된 데이터를 사용하여 서버에 대한 요청을 최소화하며, 이는 빠른 응답과 더 나은 성능을 제공합니다.