HTTP에서 제공하는 Cache-Control

1. Client, Server 그리고 Cache의 배치구조
1-1. Client <-> Cache Server <-> Server
arrow_forward: 중간에 Cache Server를 배치한 구조
요청한 데이터가 캐싱이 되어 있는 경우라면, Server까지 갈 필요가 없기 때문에 좀 더 빠르게 데이터를 받을 수 있다.
하지만, Cache Server까지 도달하는 네트워크 통신은 불가피하다.

1-2. Client(+cache manager) <-> Server
:arrow_forward: Client 내에 제공된 Cache 매니저가 있는 경우
iOS에서는 이러한 Cache Manager를 제공하고 있습니다. Client 내부에서 Cache를 관리하기에,
캐싱이 되어있는 경우라면 완벽하게 네트워크 통신을 피할 수도 있다.
(하지만, 캐싱이 되어 있더 라도 항상 요청을 하지 않는 것은 아니다.)

2. Cache 동작 원리
2-1) Client의 요청이 Cache Server 혹은 로컬 Cache 관리자에 전달됩니다. 
2-2) 캐시 된 문서가 있는지를 조회합니다. 
2-3) 존재한다면 문서의 유효성 체크를 하게 되고, 없다면 Server로 요청을 전달합니다. 
2-4) 해당 문서가 아직 유효하다면, 새로 생성한 Headers와 기존의 Body를 조합합니다. 
2-5) 유효하지 않다면, Server에 요청을 전달합니다. 
2-6) Client에 응답을 전달합니다.


참고 :
https://www.blog-dreamus.com/post/cache-control-%EC%9D%B4-%ED%95%84%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0

'Cache-Control'이 필요한 이유

 

 

추가) JS에서 웹 캐시 직접 이용하기 참고 : https://developer-talk.tistory.com/242