NSCache와 URLCache의 차이

Memory Caching

어플리케이션의 메모리 영역의 일부분을 Caching에 사용하는 것
(단점) 어플리케이션이 종료되어 메모리에서 해제되면 이 영역에 있던 리소스들은 OS에 반환되면서 Memory Caching 되어 있던 리소스들은 사라짐

Disk Caching

데이터를 파일 형태로 디스크에 저장하는 것
(단점) Disk Caching이 반복적으로 발생하면 어플리케이션이 차지하는 용량이 커진다.
(장점) 어플리케이션을 껐다 켜도 데이터가 사라지지 않는다.
(예시) 카카오톡에서 이미지나 동영상을 디바이스에 저장하지 않더라도 눈으로 보기 위해서는 파일을 다운로드 받아야 하는데, 이때 다운로드 받은 파일들이 Disk Caching되어 앱을 종료했다가 실행해도 볼 수 있다.

1. NSCache와 URLCache의 차이

- NSCache
    - in-memory 캐시 제공
    - 일반적으로 이미지 또는 데이터의 크기에 비례하는 크기를 할당
    - NSCache는 퇴거 프로세스가 순서대로 진행될 것이라고 보장 X
    - 캐시된 개체는 다음 실행에서 존재 X
    - 장점 -> 성 비용이 많이 드는 일시적인 데이터가 있는 개체에 대한 성능 및 자동 제거 기능
- URLCache
    - URL 로드 요청에 대한 Response 캐싱을 구현합니다.
    - in-memory와 on-disk 캐시를 제공한다.
    - in-memory와 on-disk 부분의 크기를 조작할 수 있습니다.
    - 캐시 데이터가 지속적으로 저장되는 경로를 제어할 수도 있습니다.
- 차이점
    - 모든 네트워크 데이터 관리의 경우 데이터 캐싱을 위해 NSCache가 아닌 URLCache를 사용해야 함
    - 왜냐하면, URLCache는 메모리 내 캐시와 디스크 캐시 모두에 있으며 데이터에 메모리 청크를 할당하지 않기 때문
        - 청크 -> 하나의 번들 파일을 효과적으로 다루기 위해 여러가지의 파일로 다시 나누는 것
    - 메모리 내 크기와 디스크 크기를 정의할 수 있어 더 유연
    - URLCache는 시스템의 디스크 공간이 부족해질 때까지 캐시된 데이터를 유지합니다.

2. 메모리 캐싱과 디스크 캐싱의 차이

- 메모리 캐싱
    - 임시적인 데이터
    - 자주 업데이트되는 데이터
    - 프로그램에서 빠르게 주고받을 데이터
- 디스크 캐싱
    - 큰 용량의 데이터
    - 오래 유지 해야하는 데이터

3. URLCache의 기본 캐시 정책

- URLCache.StoragePolicy

이름	기능
case allowed	URLCache제한 없이 보관 이 가능합니다.
case allowedInMemoryOnly	저장 URLCache이 허용됩니다. 그러나 스토리지는 메모리로만 제한되어야 합니다.
case notAllowed	URLCache메모리나 디스크에 저장하는 것은 어떤 방식으로도 허용되지 않습니다.

4. URLRequest에서도 캐싱에 대한 설정을 해줄 수 있음. URLRequest의 기본 캐시 정책은?

캐시 정책	로컬 캐시	원본 소스
NSURLRequest.CachePolicy.reloadIgnoringLocalCacheData	무시됨	무조건 접근
NSURLRequest.CachePolicy.returnCacheDataDontLoad	무조건 접근	무시됨
NSURLRequest.CachePolicy.returnCacheDataElseLoad	우선 시도	필요하다면 접근
NSURLRequest.CachePolicy.useProtocolCachePolicy	프로토콜에 따라 다름	프로토콜에 따라 다름

5. 캐시를 구현할 때 고려해야하는 캐시 운용 정책은?

1) 보안성 (캐시 접근 및 저장 관련)
2) 데이터 수명
3) 캐시 교체 정책 (Cache Replacement Policy)
    -. 데이터 사용시간에 따른 교체 (사용시간 작은것 부터..)
    -. LRU, FIFO, LFU 구조에 따라 교체
    -. Random, NUR, Optimal 등등...
4) 저장하는 시점에 따른 정책
    -. Write Through: 쓰기 요청 시 즉시 저장
    -. Write Back: 쓰기 요청 시 캐시에서만 이뤄지고 바로 저장되지 않고 추후 캐시에서 해당 사항이 끝날때 최종으로 한번에 변경사항 저장

일정한 URL을 써라
같은 자원을 다른 URL로 서비스 하고 있다면 그 자원은 여러번 요청되고 저장될 것이다.

재사용하면 안되는 리소스는 캐시하지않게 하자
민감한 데이터의 경우 no-store 설정을 해줘서 저장하지 않도록.

어떤 자원들이 중간 저장을 가능하게 할지 결정하라
모든 사용자들에게 동일한 자원은 CDN(Content Delivery Network)이나 다른 중간 매개체들에게도 캐시할 수 있게 하는 좋은 후보다.

각 자원의 최적의 캐시 기간을 정해라
다양한 자원은 각기 다른 신선도를 요구한다. 살펴보고 각각의 max-age를 적절히 선택하라.

URLCache
NSCache
끄적이는 개발노트:티스토리