[FRONT] 캐시(Cache)와 캐싱(Caching)

[FRONT]

1. [FRONT] 프론트엔드 쿠키 이슈 해결하기
2. [FRONT] Nuxt Proxy 설정과 활용
3. [FRONT] 웹 캐시 전략과 구현
4. [FRONT] Next.js와 Nuxt.js 비교 분석
5. [FRONT] Monorepo vs Multi-repo vs Monolith 아키텍처
6. [FRONT] mitmproxy를 활용한 디버깅
7. [FRONT] Storybook 활용 가이드
8. [FRONT] Vercel Turbopack 소개
9. [FRONT] 캐시와 캐싱 전략
10. [FRONT] SWC 컴파일러 이해하기
11. [FRONT] 인터섹션 옵저버로 인터섹션 여부 감지하기
12. [FRONT] BroadcastChannel 사용해서 같은 도메인 브라우저 간 통신하기
13. [FRONT] DOM이벤트 버블링(Bubbling)과 캡처링(Capturing)
14. [FRONT] XSS와 CSRF
15. [FRONT] 웹 성능 최적화
16. [FRONT] 브라우저 렌더링 과정
17. [FRONT] 웹 접근성
18. [FRONT] URL과 Domain 정확히 이해하자 (url구조)
19. [FRONT] HTTP 헤더 이해하기

이슈

저번에 작성한 [AWS] s3 이미지,파일 덮어쓰기시 변경안됨 s3이미지를 날려도 ios에서 이미지 캐시가 남아서 변경할때마다 배포가 필요하여 캐시 공부를 해보기로함!!

참고 문서

• 웹 서비스 캐시 똑똑하게 다루기
• 웹 캐시(web cache) 종류 및 동작 순서

캐시(Cache)란?

캐시는 자주 사용하는 데이터를 더 빠르게 접근할 수 있도록 임시로 저장해 두는 메모리 공간입니다. 데이터를 주 메모리나 원본 데이터 소스로부터 반복해서 가져오는 대신, 캐시에서 빠르게 읽어오므로 성능을 향상시킬 수 있습니다. 캐시는 CPU, 메모리, 디스크, 웹 브라우저 등 다양한 컴퓨팅 환경에서 사용됩니다.

캐싱(Caching)란?

캐싱은 자주 사용하는 데이터를 캐시에 저장하여, 원본 데이터에 다시 접근할 필요 없이 캐시에서 데이터를 읽어오는 과정을 말합니다. 이를 통해 시스템의 응답 시간을 단축하고 성능을 높일 수 있습니다.

브라우저 캐싱의 동작 원리 및 순서

웹 브라우저는 웹 페이지를 로드할 때 자주 사용되는 자원(HTML, CSS, JavaScript, 이미지 등)을 캐시에 저장하여, 이후 같은 페이지나 자원을 다시 요청할 때 서버로부터 다시 다운로드하지 않고 캐시에서 빠르게 로드할 수 있도록 합니다.

브라우저 캐싱 순서는 다음과 같습니다:

1. 브라우저가 페이지 요청: 사용자가 웹 페이지를 요청하면, 브라우저는 해당 페이지의 자원을 불러오기 시작합니다.

2. 캐시 확인: 브라우저는 먼저 캐시에 해당 자원이 저장되어 있는지 확인합니다. 여기서 자원의 URL과 함께 저장된 만료 정보(예: Cache-Control, Expires 헤더)를 참고합니다.

3. 만료되지 않은 경우: 캐시에 저장된 자원이 유효하고 만료되지 않았다면, 브라우저는 캐시에서 자원을 불러와 화면에 표시합니다. 서버로 다시 요청하지 않기 때문에 로드 속도가 매우 빨라집니다.

4. 만료된 경우 또는 자원이 없는 경우: 캐시에 자원이 없거나 만료된 경우, 브라우저는 서버로부터 새로운 자원을 요청합니다. 서버는 최신 자원을 브라우저로 전송하고, 브라우저는 이를 캐시에 다시 저장합니다.

5. 자원의 교체 (Replacement Policy): 캐시 공간이 제한되어 있으므로 오래된 자원은 교체되며, 브라우저 캐시에서도 주로 LRU(Least Recently Used) 방식이 사용됩니다. 즉, 가장 오랫동안 사용되지 않은 자원이 먼저 교체됩니다.

브라우저 캐시에서 사용되는 캐시 정책

• Cache-Control: 서버가 이 헤더를 통해 캐시 정책을 지정할 수 있습니다. 예를 들어, max-age는 자원이 캐시에 얼마 동안 유효한지(초 단위)를 설정하며, no-cache는 자원이 캐시되지 않도록 설정할 수 있습니다.
• Expires: 특정 날짜와 시간을 설정하여, 자원이 그 시점 이후에 만료되도록 할 수 있습니다.
• ETag: 자원의 버전 정보를 제공하여, 브라우저가 서버에 자원이 변경되었는지 확인할 수 있게 합니다. 자원이 변경되지 않았다면 캐시된 버전을 사용하게 됩니다.

크롬(Chrome) 사파리(Safari) 캐시 및 캐싱 차이

크롬(Chrome)과 사파리(Safari) 브라우저에서 사용하는 캐시 및 캐싱 순서는 대부분 비슷하지만, 일부 세부적인 구현 방식에서 차이가 있을 수 있습니다. 두 브라우저 모두 웹 표준을 따르며, 캐시를 통해 웹 페이지 성능을 최적화하는 방식은 크게 다르지 않지만, 캐시 관리나 정책 적용 방식에서 다소 차이를 보일 수 있습니다.

1. 공통점

• 웹 표준 준수: 크롬과 사파리 모두 HTTP 표준에서 정의한 Cache-Control, Expires, ETag와 같은 헤더를 기반으로 캐싱 정책을 관리합니다. 따라서 서버에서 정의한 캐싱 정책은 두 브라우저에서 일관되게 적용됩니다.
• 캐시 교체 정책: 대부분의 브라우저는 LRU(Least Recently Used) 방식을 채택하여 오랫동안 사용되지 않은 자원을 우선적으로 교체합니다. 크롬과 사파리도 동일한 방식으로 캐시 데이터를 관리합니다.

2. 차이점

1. 캐시 저장소 및 관리 방식

   • 크롬(Chrome): 크롬은 Google의 V8 엔진과 강력한 자바스크립트 처리 성능 덕분에 대규모 데이터를 다루는 데 최적화되어 있습니다. 크롬은 보다 적극적인 캐시 관리를 통해 사용자 경험을 개선하는 전략을 사용합니다. 예를 들어, 프리페칭(Prefetching) 및 프리렌더링(Prerendering) 같은 기술을 통해 자주 방문하는 사이트의 데이터를 미리 캐시에 로드하여 성능을 향상시킵니다.
   • 사파리(Safari): 사파리는 Apple의 WebKit 엔진을 기반으로 하며, 크롬보다 다소 보수적인 캐시 관리 전략을 채택하는 경우가 많습니다. 특히 iOS에서는 디바이스의 성능과 배터리 수명을 고려하여 캐시 메커니즘을 보다 신중하게 관리합니다. iOS 기기에서 사파리는 더 작은 캐시 용량을 사용할 수 있으며, 메모리와 저장 공간이 제한된 환경에서 자원을 보다 효율적으로 관리하려 합니다.

2. 캐시 만료 및 검증 정책

   • 크롬(Chrome): 크롬은 자원의 캐시 만료 및 검증 시 보다 공격적인 검증 전략을 사용할 수 있습니다. 자원의 최신 상태를 유지하기 위해 자주 ETag를 검증하거나 If-Modified-Since 요청을 보낼 수 있습니다.
   • 사파리(Safari): 사파리는 이러한 검증 요청을 덜 빈번하게 보낼 수 있으며, 사용자가 최근 방문한 사이트에서 더 오래된 데이터를 사용할 가능성이 높습니다. 이는 데이터 절약과 성능 최적화를 위한 선택일 수 있습니다.

3. 프라이버시 및 보안 관리

   • 사파리(Safari): 사파리는 프라이버시 보호에 더 집중하는 경향이 있으며, 이를 위해 Intelligent Tracking Prevention(ITP)라는 기능을 사용해 추적 방지와 관련된 캐시 정책을 적용합니다. 이 기능은 광고 추적 등에서 사용하는 캐시 데이터를 엄격하게 제한할 수 있습니다.
   • 크롬(Chrome): 크롬은 보안에 중점을 두면서도 프라이버시 보호에 있어서는 사파리보다 덜 엄격할 수 있습니다. 크롬은 캐시를 더 자주 재사용하려는 경향이 있지만, 광고나 추적과 관련된 데이터를 차단하는 방식은 사파리와 약간 다를 수 있습니다.

결론:프론트에서 해결

브라우저 캐시를날리기위해 이런식으로 쿼리 스트링 붙여서 캐시날리기로했음

1
2
<img src="*********?new Date()" />
<script src=*******.js?20160406150321>

이런식으로 사용할라함

• Previous
  [Algorithm] Graphs - Detect Cycle in Graphs Algorithm
• Next
  [Algorithm] Graphs - Prim's Algorithm