99클럽 33일차 TIL: 클라이언트 사이드 캐시

#1. 오늘의 학습 키워드

클라이언트 사이드 캐시 에 대해

• cache 의 종류와 redis 의 선정 및 CDN 의 개념의 대해 알아보았다.
  • cache 종류 비교 및 선정
    • https://second-brain.tistory.com/9
  • redis 적용
    • https://second-brain.tistory.com/10
  • CDN
    • https://second-brain.tistory.com/50
• 이번 포스트에서는 다른 측면에서의 캐시인 클라이언트 사이드 캐시에 대해서 알아보자

---

#2. 공부한 내용

1. 클라이언트 사이드 캐싱

- 브라우저 측에서 데이터 저장 (캐싱)

• 웹 페이지를 접근할 때, 서버 데이터의 서브셋을 클라이언트 측 로컬 디스크나 메모리에 저장을 한다.
  • 추후 페이지가 로드될 때, 접근한 정보가 클라이언트 측에 있다면, 굳이 서버 측 데이터 베이스에 요청을 하지 않고 로컬 정보를 가져다 쓴다.
  • 서버에 새로운 요청을 하지 않기에, 네트워크 상 통신 비용을 줄여서 속도를 높인다.
• 이때 데이터 서브셋 내 데이터들은 자주 접근하지만, 드물게 변경 되는 데이터 위주로 구성해야 성능을 많이 높일 수 있다.

1) 클라이언트 사이드 캐싱 관련 HTTP 헤더

• 클라이언트 측에서 캐싱을 수행할 수 있도록, 서버에서는 response HTTP 헤더에 여러 정보를 담아서 전송한다.
• Cache-Control
  • 캐시 유효기간, 캐시 사용 유무 등 결정할 수 있는 캐시 제어 헤더
• Expires
  • 캐시 만료 시간 설정
  • 캐시 만료 시간 지날 경우 브라우저는 가지고 있던 캐싱된 데이터를 새로운 요청으로 덮어씌운다.
• Last-Modified
  • 서버에서 마지막으로 수정된 시간 정보를 담는다.
• If-Modified-Since
  • 클라이언트 측 요청 헤더
    • 클라이언트는 Last-Modified 로 받은 정보를 해당 헤더에 넣어서 전송
  • 서버는 해당 헤더내의 시간 정보와, 실제로 요청된 리소스의 최신화된 마지막 수정 시간을 비교하여 변경 여부를 판단
• ETag
  • 리소스의 버전 정보
• If-None-Math
  • 클라이언트 측 요청 헤더
    • 클라이언트는 ETag 로 받은 정보를 해당 헤더에 넣어서 전송
  • 서버는 해당 헤더내의 정보와, 실제로 요청된 리소스의 최신화된 ETag값을 비교하여 변경 여부를 판단

2) 장점

• 빠른 웹페이지 로딩 속도
  • latency 가 줄어든다.
• 서버 측 부하 감소
  • 서버측 데이터 베이스는 쿼리를 덜 받게 된다.
  • 서버 측 네트워크 트래픽도 줄어든다.
• 오프라인 지원
  • 사용자가 서버와 접속할 수 없어도, 이전에 캐시된 콘텐츠를 사용할 수 있다.

3) 단점

• 캐시 관리 어려움
  • 데이터 베이스와 캐시의 일관성을 늘 고려해야한다.
  • 따라서 캐시 제어 및 무효화 매커니즘을 구현해야한다.
• 보안 문제
  • 캐싱할 컨텐츠의 따라서 보안 문제를 초래할 수도 있다.

---

• 참조:
  • https://kim-gpt.tistory.com/entry/클라이언트-단-캐시-Client-side-Caching
  • https://medium.com/garimoo/클라이언트-사이드-캐싱-71a3ca7727ff

---

#3. 오늘의 회고

• 정리:
  • 클라이언트 사이드 캐시는 클라이언트 측에서 데이터를 캐싱하여 빠르게 접근하는 기술이다.
  • 이를 통해 웹 페이지 성능 향상과 서버 부하를 줄일 수 있다.
  • 그러나 빨라진 속도 만큼 tradeoff 로 고려할 것도 많아진다.
    • 캐시를 적절하게 관리하고 유지하는 것은 쉬운 작업이 아니다.
    • 해당 캐시가 오래된 데이터 일 경우 캐싱 무효화를 해야한다.