캐시

3. 기본 개념

캐시는 데이터 접근의 지역성 원리를 이용하여 효율성을 높인다. 지역성은 데이터 접근이 시간적, 혹은 공간적으로 가깝게 일어나는 것을 의미한다.^[1]

캐시는 데이터 버퍼를 제공하여 대기 시간과 처리량(대역폭)을 개선한다. 더 큰 리소스는 액세스에 상당한 대기 시간을 유발하는데, 예를 들어 최신 4GHz 프로세서가 DRAM에 도달하는 데 수백 클럭 사이클이 걸릴 수 있다. 이는 캐시에 큰 덩어리를 읽어들여 완화할 수 있다. 예측 또는 명시적인 캐시 프리페칭을 사용하여 향후 읽기를 예측하고 미리 요청할 수도 있다. 최적으로 수행되면 대기 시간을 완전히 우회할 수 있다.^[1]

캐시를 사용하면 여러 세분화된 전송을 더 크고 효율적인 요청으로 조립하여 기본 리소스에서 더 높은 처리량을 얻을 수도 있다. DRAM 회로의 경우, 더 넓은 데이터 버스를 사용하여 이를 실현할 수 있다.^[1]

하드웨어는 데이터를 임시로 저장하기 위해 메모리의 블록 형태로 캐시를 구현한다. 중앙 처리 장치(CPU), 솔리드 스테이트 드라이브(SSD), 하드 디스크 드라이브(HDD)는 하드웨어 기반 캐시를 자주 포함하며, 웹 브라우저와 웹 서버는 일반적으로 소프트웨어 캐싱에 의존한다.

캐시는 항목 풀로 구성된다. 각 항목에는 ''데이터''와 ''태그''가 있다. ''데이터''는 ''백업 저장소''에 있는 데이터의 복사본이고, ''태그''는 백업 저장소의 데이터 식별자이다.

캐시 클라이언트(CPU, 웹 브라우저, 운영 체제)가 데이터에 접근해야 할 때, 먼저 캐시를 확인한다. 원하는 데이터의 태그와 일치하는 태그가 있는 항목을 찾으면, 해당 항목의 데이터를 대신 사용한다. 이를 '''캐시 적중'''이라고 한다. 예를 들어, 웹 브라우저 프로그램은 디스크의 로컬 캐시를 확인하여 특정 URL의 웹 페이지 내용의 로컬 사본이 있는지 확인할 수 있다. 이때 URL은 태그이고, 웹 페이지의 내용은 데이터이다. 캐시 적중으로 이어지는 액세스의 비율을 캐시의 '''적중률'''이라고 한다.

원하는 태그가 있는 항목이 없는 상황을 '''캐시 미스'''라고 한다. 이 경우 백업 저장소에서 데이터를 가져오는 데 더 많은 비용이 든다. 요청된 데이터는 일반적으로 다음 액세스를 위해 캐시에 복사된다.

캐시 미스가 발생하면, 새로 검색된 데이터를 위한 공간을 만들기 위해 기존 캐시 항목이 제거되기도 한다. 교체할 항목을 선택하는 휴리스틱을 교체 정책이라고 한다. 가장 널리 사용되는 교체 정책 중 하나인 LRU(Least Recently Used)는 가장 오래된 항목을 교체한다. 더 정교한 캐싱 알고리즘은 항목의 사용 빈도도 고려한다.

3. 1. 기억 계층 (Memory Hierarchy)

• 기억 계층의 예시:
• 상위 레벨: CPU 레지스터 (소용량, 고속)^[1]
• 중간 레벨: L1 캐시, L2 캐시 (중용량, 중속)
• 하위 레벨: 하드 디스크, 자기 테이프 등의 보조 기억 장치 (대용량, 저속)^[1]

• 캐시의 종류:
• 인클루전(inclusion) 캐시: 상위 레벨 캐시(예: L1)에 존재하는 데이터가 하위 레벨 캐시(예: L2)에도 존재하는 방식.^[1]
• 빅팀(victim) 캐시: 상위 레벨 캐시에 존재하는 데이터가 하위 레벨 캐시에 반드시 존재하지 않는 방식.^[1]

3. 2. 지역성 (Locality)

• 시간적 지역성(Temporal Locality^영어)은 특정 데이터가 한번 접근되었을 경우, 가까운 미래에 다시 접근할 가능성이 높은 것을 말한다.
• 공간적 지역성(Spatial Locality^영어)은 특정 데이터와 가까운 주소가 순서대로 접근되는 경향을 의미한다.

3. 2. 1. 시간적 지역성 (Temporal Locality)

3. 2. 2. 공간적 지역성 (Spatial Locality)

4. 캐시의 동작 방식

하드웨어는 데이터를 임시로 저장하기 위해 메모리의 블록 형태로 캐시를 구현하며, 이는 다시 사용될 가능성이 있는 데이터이다. 중앙 처리 장치(CPU), 솔리드 스테이트 드라이브(SSD), 하드 디스크 드라이브(HDD)는 하드웨어 기반 캐시를 자주 포함하며, 웹 브라우저와 웹 서버는 일반적으로 소프트웨어 캐싱에 의존한다.

캐시는 항목 풀로 구성된다. 각 항목에는 ''데이터''가 있으며, 이는 일부 ''백업 저장소''의 동일한 데이터 복사본이다. 각 항목에는 또한 ''태그''가 있는데, 이 태그는 항목이 복사본인 백업 저장소의 데이터 식별자를 지정한다.

캐시 클라이언트(CPU, 웹 브라우저, 운영 체제)가 백업 저장소에 존재한다고 가정되는 데이터에 접근해야 할 때, 먼저 캐시를 확인한다. 원하는 데이터의 태그와 일치하는 태그가 있는 항목을 찾을 수 있으면, 해당 항목의 데이터가 대신 사용된다. 이 상황을 '''캐시 적중'''이라고 한다. 예를 들어, 웹 브라우저 프로그램은 디스크의 로컬 캐시를 확인하여 특정 URL의 웹 페이지 내용의 로컬 사본이 있는지 확인할 수 있다. 이 예에서 URL은 태그이고, 웹 페이지의 내용은 데이터이다. 캐시 적중으로 이어지는 액세스의 비율을 캐시의 '''적중률'''이라고 한다.

원하는 태그가 있는 항목이 캐시에 없는 상황을 '''캐시 미스'''라고 한다. 이 경우 백업 저장소에서 데이터를 가져오는 데 더 많은 비용이 든다. 요청된 데이터가 검색되면 일반적으로 다음 액세스를 위해 캐시에 복사된다.

캐시 미스가 발생하는 동안 새로 검색된 데이터를 위한 공간을 만들기 위해 다른 기존 캐시 항목이 일반적으로 제거된다. 교체할 항목을 선택하는 데 사용되는 휴리스틱은 교체 정책이라고 한다. 가장 널리 사용되는 교체 정책 중 하나인 LRU(Least Recently Used)는 가장 오래된 항목, 즉 다른 항목보다 최근에 액세스되지 않은 항목을 교체한다. 보다 정교한 캐싱 알고리즘은 항목의 사용 빈도도 고려한다.

4. 1. 캐시 적중 (Cache Hit)

예를 들어, 웹 브라우저 프로그램은 특정 URL의 웹 페이지 내용이 로컬 캐시에 있는지 확인한다. 이때 URL은 태그, 웹 페이지 내용은 데이터에 해당한다. 캐시 적중 비율은 캐시의 '''적중률'''이라고 한다.

4. 2. 캐시 실패 (Cache Miss)

요청한 데이터가 캐시에 없어, 더 느린 저장 장치(주기억장치, 디스크 등)에서 데이터를 가져와야 하는 경우를 '''캐시 실패'''(cache miss)라고 한다. 이 경우 백업 저장소에서 데이터를 가져오는 데 더 많은 비용이 든다. 요청된 데이터가 검색되면 일반적으로 다음 접근을 위해 캐시에 복사된다.

캐시 실패가 발생하면, 새로 검색된 데이터를 위한 공간을 만들기 위해 기존 캐시 항목 중 일부를 제거해야 하는 경우가 있다. 이때 어떤 항목을 제거할지 결정하는 방법을 교체 정책이라고 한다. 가장 널리 사용되는 교체 정책 중 하나는 LRU(Least Recently Used)로, 가장 오랫동안 사용되지 않은 항목을 교체한다. 더 정교한 캐싱 알고리즘은 항목의 사용 빈도도 고려한다.

4. 3. 쓰기 정책 (Writing Policies)

캐시에 데이터를 쓸 때, 원본 데이터(backing store)에도 언제, 어떻게 쓸 것인지를 결정하는 정책이 필요하다. 이를 쓰기 정책이라고 한다. 쓰기 정책에는 다음과 같은 두 가지 기본 방식이 있다.^[3]

• '''쓰기 통과 (Write-Through)''': 캐시와 백업 저장소 모두에 동기적으로 쓰기를 수행한다.
• '''쓰기 백 (Write-Back)''': 처음에는 캐시에만 쓰기를 수행한다. 백업 저장소에 대한 쓰기는 수정된 내용이 다른 캐시 블록으로 교체되기 전까지 연기된다. 이를 ''레이지 쓰기''라고도 한다.

쓰기 백 캐시는 구현하기가 더 복잡하다. 캐시에서 어떤 내용이 변경되었는지 추적하고, 나중에 백업 저장소에 쓰기 위해 이를 '더티(dirty)'로 표시해야 하기 때문이다. 쓰기 백 캐시에서 읽기 미스가 발생하면, 데이터를 가져오기 위해 두 번의 메모리 접근이 필요할 수 있다. (한 번은 더티 데이터를 쓰기 위해, 다른 한 번은 필요한 데이터를 읽기 위해)

쓰기 작업 요청자는 데이터가 반환되지 않으므로, 쓰기 미스 시 데이터를 캐시에 로드할지 여부에 대한 결정도 필요하다.

• '''쓰기 할당 (Write-Allocate)''' (또는 ''쓰기 시 가져오기''): 미스된 쓰기 위치의 데이터를 캐시에 로드한 다음, 쓰기 적중 연산을 수행한다.
• '''쓰기 비할당 (No-Write-Allocate)''' (''쓰기 우회''): 미스된 쓰기 위치의 데이터는 캐시에 로드되지 않고, 백업 저장소에 직접 쓰여진다.

쓰기 통과 및 쓰기 백 정책은 이 두 가지 쓰기 미스 정책을 모두 사용할 수 있지만, 일반적으로 함께 사용된다.^[4][5]

4. 3. 1. 쓰기 통과 (Write-Through)

시스템이 캐시에 데이터를 쓸 때, 언젠가는 그 데이터를 백업 저장소에도 써야 한다. 이 쓰기의 시점을 ''쓰기 정책''이라고 한다. ''쓰기 통과(Write-Through)''는 캐시와 백업 저장소 모두에 동기적으로 쓰기를 수행하는 방식이다.^[3]

쓰기 통과 캐시는 쓰기 비할당 정책을 사용할 수 있다. 쓰기 비할당(또는 쓰기 우회)은 미스된 쓰기 위치의 데이터는 캐시에 로드되지 않고 백업 저장소에 직접 쓰는 방식이다. 쓰기 통과 캐시에서 쓰기 비할당을 사용하는 경우, 후속 쓰기는 여전히 백업 저장소에 직접 써야 하므로 이점이 없다.^[4][5]

4. 3. 2. 쓰기 지연 (Write-Back, Write-Behind)

쓰기 백(Write-back)은 쓰기 지연(write-behind)이라고도 불리며, 데이터를 캐시에 쓸 때 바로 백업 저장소에 쓰지 않고, 캐시에만 기록하는 방식이다. 데이터가 수정되면 '더티(dirty)' 플래그를 설정하여 표시하고, 나중에 해당 데이터가 캐시에서 제거될 때(다른 데이터로 교체될 때) 백업 저장소에 한꺼번에 기록한다. 이를 "레이지 쓰기"라고도 부른다.^[3]

이 방식은 쓰기 작업을 빠르게 처리할 수 있다는 장점이 있다. 하지만, 캐시에만 데이터가 저장되어 있는 동안 전원 공급이 중단되거나 시스템 오류가 발생하면 데이터가 손실될 위험이 있다.

쓰기 백 캐시에서 읽기 실패가 발생하면, 데이터를 가져오기 위해 두 번의 메모리 접근이 필요할 수 있다. 한 번은 쓰기 백을 위한 것이고, 다른 한 번은 필요한 데이터를 실제로 읽어오기 위한 것이다.

쓰기 백 캐시는 일반적으로 쓰기 할당(write-allocate) 방식을 사용한다. 쓰기 할당은 쓰기 실패 시 해당 데이터를 캐시에 로드하고, 이후 동일한 위치에 대한 쓰기(또는 읽기)가 캐시에서 처리될 수 있도록 한다.^[4][5]

4. 4. 쓰기 할당 (Write Allocate)

쓰기 실패 시, 데이터를 캐시에 로드한 후 쓰기 작업을 수행한다. 쓰기 작업에서 요청자에게 데이터가 반환되지 않으므로, 쓰기 실패 시 데이터를 캐시에 로드할지 여부에 대한 결정을 내려야 한다.^[3]

• '''쓰기 할당''' (또는 '''쓰기 시 가져오기'''): 실패한 쓰기 위치의 데이터가 캐시에 로드된 다음, 쓰기 적중 연산이 수행된다. 이 방식에서 쓰기 실패는 읽기 실패와 유사하다.
• '''쓰기 비할당''' (또는 '''쓰기 비할당''' 또는 '''쓰기 우회'''): 실패한 쓰기 위치의 데이터는 캐시에 로드되지 않고 백업 저장소에 직접 쓰여진다. 이 방식에서 데이터는 읽기 실패 시에만 캐시에 로드된다.

쓰기 백 캐시는 쓰기 할당을 사용하여, 이제 캐시된 동일한 위치에 대한 후속 쓰기(또는 읽기)를 기대한다.^[4][5]

4. 5. 쓰기 비할당 (No-Write Allocate)

시스템이 캐시에 데이터를 쓸 때, 언젠가는 그 데이터를 백업 저장소에도 써야 한다. 이 쓰기의 시점을 ''쓰기 정책''이라고 한다. 쓰기 미스 시 데이터를 캐시에 로드할지 여부에 대한 결정을 내려야 하는데, 그중 하나가 '''쓰기 비할당''' 방식이다.

• '''쓰기 비할당''' (''쓰기 비할당'' 또는 ''쓰기 우회''): 미스된 쓰기 위치의 데이터는 캐시에 로드되지 않고 백업 저장소에 직접 쓰여진다. 이 접근 방식에서 데이터는 읽기 미스 시에만 캐시에 로드된다.^[4][5]

쓰기 통과 캐시는 쓰기 비할당을 사용한다. 쓰기 통과 방식에서는 후속 쓰기가 여전히 백업 저장소에 직접 쓰여져야 하므로 이점이 없기 때문이다.^[4][5]

4. 6. 교체 정책 (Replacement Policies)

캐시가 가득 찼을 때, 어떤 데이터를 제거하고 새로운 데이터를 저장할지 결정하는 정책을 교체 정책이라고 한다. 가장 널리 사용되는 교체 정책 중 하나는 LRU(Least Recently Used)이다. LRU는 가장 오랫동안 사용되지 않은 항목, 즉 다른 항목보다 최근에 접근되지 않은 항목을 교체한다. 보다 정교한 캐싱 알고리즘은 항목의 사용 빈도도 고려한다.

4. 7. 프리페치 (Prefetch)

프리페치는 필요할 것으로 예상되는 데이터를 미리 캐시에 가져오는 기술이다. 예측 또는 명시적인 캐시 프리페칭을 사용하여 향후 읽기가 어디에서 올지 추측하고 미리 요청을 할 수 있다. 최적으로 수행되면 대기 시간을 완전히 우회할 수 있다.^[17]

요구 페이징 정책을 가진 캐시가 백업 저장소에서 최소한의 데이터만 읽어오는 것과 달리, 프리페치 입력 큐 또는 예측 페이징 정책을 가진 캐시는 요청된 데이터뿐만 아니라, 다음 데이터 청크가 곧 필요할 것이라고 추측하여 해당 데이터를 미리 캐시에 프리페치한다. 이러한 방식은 백업 저장소가 첫 번째 청크를 읽는 데 긴 지연 시간을 가지지만, 다음 청크들을 순차적으로 읽는 데 훨씬 짧은 시간이 걸리는 경우에 특히 유용하다. 예를 들어 디스크 스토리지 및 DRAM에서 효과적이다.^[17]

일부 운영 체제는 실행 파일을 전체 RAM에 미리 로드하는 로더를 사용하기도 한다. 또한, 일부 캐시는 전체 파일을 미리 로드할 뿐만 아니라, 프리페처와 관련된 페이지 캐시 또는 링크 프리페칭과 관련된 웹 캐시와 같이 곧 요청될 수 있는 다른 관련 파일도 로드한다.^[17]

5. 여러 가지 캐시의 종류

메모리 설계에서는 용량과 속도 사이에 근본적인 상충 관계가 존재한다. 용량이 커질수록 크기가 커지고 신호가 이동해야 하는 물리적 거리가 늘어나 전파 지연이 발생하기 때문이다. 또한, SRAM과 같은 고성능 기술과 DRAM, 플래시, 하드 디스크와 같이 저렴하고 대량 생산이 용이한 제품 사이에도 이러한 상충 관계가 나타난다.

캐시는 데이터 버퍼를 제공하여 대기 시간과 처리량 (대역폭)을 개선한다. 큰 리소스는 접근에 상당한 대기 시간을 유발하는데, 예를 들어 최신 4GHz 프로세서가 DRAM에 도달하는 데 수백 클럭 사이클이 걸릴 수 있다. 캐시는 이러한 대기 시간을 완화하기 위해 큰 덩어리의 데이터를 읽어 들이고, 예측 또는 명시적인 캐시 프리페칭을 통해 대기 시간을 줄일 수 있다. 또한, 캐시는 여러 세분화된 전송을 더 크고 효율적인 요청으로 조립하여 기본 리소스에서 더 높은 처리량을 얻을 수 있도록 돕는다.

5. 1. 하드웨어 캐시

5. 1. 1. CPU 캐시

5. 1. 2. GPU 캐시

5. 1. 3. DSP 캐시

5. 2. 소프트웨어 캐시

5. 2. 1. 디스크 캐시 (페이지 캐시)

• '''미리 읽기''': 운영 체제가 디스크에 데이터를 읽도록 요청할 때, 헤드를 해당 트랙에 올려놓고 데이터를 읽기까지 시간이 걸린다. 하지만 운영체제는 대개 첫 번째 섹터 이후의 섹터들을 요구하는 경우가 많아서, 연속된 섹터를 읽을 때 시간을 절약하기 위해 디스크는 뒷부분의 데이터를 미리 읽어 캐시에 저장한다.

• '''속도 조절''': 디스크의 입출력 인터페이스는 디스크 플래터가 데이터를 읽는 속도보다 훨씬 느린 경우가 많다. 따라서 디스크가 데이터를 빠르게 읽고 쓸 수 있도록 데이터를 인터페이스에 넘기기 전에 캐시에 잠시 저장한다.

• '''쓰기 가속''': 운영 체제가 디스크에 쓰기를 요청하면, 디스크 내부 컴퓨터는 캐시에 데이터를 저장하고 디스크가 쓰기를 끝내기도 전에 운영 체제에게 쓰기가 끝났음을 보고할 수 있다. 이렇게 하면 운영 체제는 디스크 쓰기가 완료될 때까지 기다리지 않고 다음 작업을 빠르게 수행할 수 있다. 그러나 이 방법은 전원이 차단되면 데이터가 사라지거나 파일 시스템이 망가질 수 있어 논란의 여지가 있다. 최신 RAID 컨트롤러는 배터리 백업 시스템을 구현하기도 하지만, 데이터 정확성을 중요하게 여기는 시스템에서는 쓰기 가속 기법을 사용하지 않는 경우도 있다.

• '''명령 큐''': 최신 시리얼 ATA 디스크와 대부분의 SCSI 디스크는 다른 명령을 수행하는 중에도 여러 개의 명령을 추가로 받을 수 있다. 이 명령들은 나중에 처리하기 위해 디스크 캐시에 저장된다. 명령 큐는 쓰기가 완전히 끝났을 때 운영 체제에게 알려줌으로써 파일 시스템의 정확성을 유지한다.

5. 2. 2. 웹 캐시

5. 2. 3. 분산 캐시

5. 2. 4. 기타 캐시

6. In-network Cache

정보 중심 네트워킹(ICN)은 종단 간 원칙에 기반한 호스트 중심 패러다임에서 벗어나 식별된 정보가 중심이 되는 네트워크 아키텍처로 인터넷 인프라를 발전시키는 접근 방식이다. ICN 노드는 고유한 캐싱 기능을 가지므로, ICN은 캐시의 느슨하게 연결된 네트워크로 볼 수 있으며, 캐싱 정책에 대한 고유한 요구 사항을 갖는다. 그러나 콘텐츠 캐싱은 무단 접근으로부터 콘텐츠를 보호해야 하는 과제를 제시하며, 이는 특별한 주의와 해결책을 요구한다.^[10]

ICN에서 캐시는 프록시 서버와 달리 네트워크 레벨 솔루션이다. 따라서 빠르게 변화하는 캐시 상태와 더 높은 요청 도착률을 가지며, 더 작은 캐시 크기는 콘텐츠 제거 정책에 대한 다른 요구 사항을 부과한다. 특히, ICN의 제거 정책은 빠르고 가벼워야 한다. 다양한 ICN 아키텍처 및 애플리케이션을 위한 다양한 캐시 복제 및 제거 방식이 제안되었다.

7. 버퍼 vs. 캐시

캐싱은 반복적으로 전송되는 데이터에 대한 성능 향상을 근본적인 목표로 한다. 캐싱 시스템은 데이터 항목의 초기 전송(일반적으로 쓰기) 시에도 성능 향상을 가져올 수 있지만, 이는 캐싱 시스템 내에서 발생하는 버퍼링 때문이다.

읽기 캐시의 경우, 데이터 항목을 캐시의 더 빠른 중간 저장소에서 가져올 수 있게 되어, 원래 저장 위치에서 가져오는 것보다 성능이 향상된다. 이를 위해서는 데이터 항목을 해당 위치에서 한 번 이상 가져와야 한다. 쓰기 캐시의 경우, 데이터 항목을 캐시의 중간 저장소에 즉시 저장하여, 나중에 해당 저장소로 전송하거나 백그라운드 프로세스로 처리함으로써 첫 번째 쓰기 시 성능 향상을 가져올 수 있다.

엄격한 버퍼링과 달리, 캐싱 프로세스는 캐시의 중간 저장소와 데이터가 저장된 위치 사이의 일관성을 유지하기 위해 (잠재적으로 분산된) 캐시 일관성 프로토콜을 준수해야 한다. 반면에 버퍼링은 다음과 같은 역할을 한다.

• 통신 프로세스 간의 새로운 데이터 전송 횟수를 줄여, 여러 작은 전송에 대한 오버헤드를 더 적은 더 큰 전송으로 분산시킨다.
• 서로 직접 전송할 수 없는 통신 프로세스를 위한 중개자 역할을 한다.
• 전송에 관련된 통신 프로세스 중 적어도 하나에서 필요로 하는 최소 데이터 크기 또는 표현을 보장한다.

참조

_[1] 웹사이트 Cache https://web.archive.[...] 2016-08-02
_[2] 논문 Cache hit ratio maximization in device-to-device communications overlaying cellular networks http://dx.doi.org/10[...] 2020-02
_[3] 웹사이트 Understanding Caching https://www.linuxjou[...] 2004-01-01
_[4] 서적 Computer Architecture: A Quantitative Approach https://books.google[...] Elsevier
_[5] 서적 Computer Architecture A Quantitative Approach Morgan Kaufmann Publishers 1990
_[6] 논문 Survey of CPU Cache-Based Side-Channel Attacks: Systematic Analysis, Security Models, and Countermeasures 2021-06-10
_[7] 웹사이트 Intel Broadwell Core i7 5775C '128MB L4 Cache' Gaming Behemoth and Skylake Core i7 6700K Flagship Processors Finally Available In Retail https://wccftech.com[...] 2015-09-25
_[8] 웹사이트 qualcom Hexagon DSP SDK overview https://developer.qu[...]
_[9] 웹사이트 Lecture 7: Memory Management http://cseweb.ucsd.e[...] UC San Diego 2013-12-04
_[10] 논문 Secure Distribution of Protected Content in Information-Centric Networking
_[11] conference Time Aware Least Recent Used (TLRU) cache management policy in ICN
_[12] 논문 A Cache Management Scheme for Efficient Content Eviction and Replication in Cache Networks
_[13] 간행물 5 Lines Of Code In The Cloud 2011-05-30
_[14] 웹사이트 Web application caching https://web.archive.[...] 2013-07-24
_[15] conference Corelli: A Dynamic Replication Service for Supporting Latency-Dependent Content in Community Networks http://comp.eprints.[...]
_[16] 웹사이트 Globally Distributed Content Delivery, by J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman and B. Weihl, IEEE Internet Computing, Volume 6, Issue 5, November 2002. https://people.cs.um[...] 2019-10-25
_[17] 웹사이트 Definition: cloud storage gateway https://www.techtarg[...] 2014-07
_[18] 논문 Distributed caching with centralized control 2001-02-01
_[19] 논문 Distributed Caching on the Path To Scalability https://msdn.microso[...] 2009-07