Cache 란?
캐싱은 주어진 리소스의 복사본을 저장하고 있다가 요청 시에 그것을 제공하는 기술 // MDN
Cache의 존재 이유
1. 모든 클라이언트를 서비스할 필요가 없어지므로 서버의 부하를 완화
2. (캐시가 원래 서버에 비해서) 클라이언트에 더 가까이에 있으므로 성능이 향상됩니다. 즉, 리소스를 회신하는데 더 적은 시간이 들게 됩니다. 웹 사이트에서 캐싱은 높은 성능을 달성하는 데에 주요한 요소입니다.
Cache의 사용과 전략
1. 파일을 다운시 재사용할 것인지(Reusable)
2. 로컬 데이터가 서버 데이터와 동일하냐 (Revalidate)
3. 캐쉬 서버와 서버의 데이터가 동일하냐 (Cachable by intermediate cache) == 보완성
Browser 상세 보기 : 유효(Fresh) vs 실효(stale)
캐쉬 생활주기 : 캐쉬 추출
- 캐시는 유한한 저장 공간을 가지므로 아이템들은 주기적으로 스토리지에서 제거됩니다. 이런 과정을 *캐시 축출(cache eviction)*이라고 부릅니다.
캐쉬 갱신 : fresh and stale
만료 시간 리소스: 유효(fresh) || 만료 시간 이후의 리소스 : 실효(stale)
반면 어떤 리소스들은 서버 상에서 변경될 수 있고, 캐시가 갱신되어야 합니다. HTTP가 클라이언트-서버 프로토콜이므로, 리소스가 변경됐을 때 서버는 캐시와 클라이언트에 접근할 수 없습니다; 서버는 리소스에 대한 만료 시간을 알려줄 수밖에 없습니다. 축출 알고리즘은 대개 실효된 리소스보다 유효한 리소스에 특권을 부여합니다. 실효된 리소스는 축출되거나 무시되지 않는다는 것을 알아두시기 바랍니다;
캐시가 실효된 리소스에 대한 요청을 받은 경우, 이 리소스가 실제로 아직 유효한지 아닌지를 확인하기 위해 If-None-Match와 함께 요청을 전달합니다. 만약 그렇다면, 서버는 요청된 리소스 본문을 전송하지 않고 304 (Not Modified) 헤더를 돌려보내 대역폭을 절약합니다.
PC는 서로 통신을 하는데, 아래와 같은 통신은 파일 전체를 가지고 하는 것이 아니라 Header에 간략한 정보만 가지고 통신을 하는 것. 따라서 Headers에 들어있는 변경 정보가 1) 있을 경우 200 반환하고 2) 없을 경우 304를 반환
Cache-Control Header
(2024년 기준 브라우저에서는 데이터 request headers에 Modified 영역을 확인 할 수 없음)
번외 Etag(해쉬값)
ETag 응답 헤더는 강한 검증으로써 사용될 수 있는 사용자 에이전트에게 있어 불투명한(opaque) 값.
Header 안 Max-age 시간이 변경되더라도 Etags값이 동일하면 데이터를 안 보냄(304)
출처
MdN : https://developer.mozilla.org/ko/docs/Web/HTTP/Caching
생활코딩 : https://www.youtube.com/watch?v=e8ch2USjAmA&list=PLuHgQVnccGMAM6VAWEKtaUnvzePCxnUVo&index=5
우아한테크 : https://www.youtube.com/watch?v=NxFJ-mJdVNQ
'나의 FE피봇이야기 > Dev_Knowledge' 카테고리의 다른 글
[ Front-End] 프론트 엔드는 어디로 향해가는가? (feat. Next.js) (0) | 2024.07.07 |
---|---|
[ CODE ] 토스, 가독성 좋은 코드란 (0) | 2024.06.30 |
[npm/redux] redux 잘 못 깔아서 안된다고 징징 (0) | 2024.03.24 |
mac 권한 설정 해제 (0) | 2024.02.19 |
[NPM] package manager version conflict(버전 이슈) (1) | 2024.02.18 |