맨위로가기

콘텐츠 전송 네트워크

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

콘텐츠 전송 네트워크(CDN)는 여러 위치에 분산된 서버를 통해 웹 콘텐츠의 전송 속도를 높이고, 대역폭 비용을 절감하며, 콘텐츠의 글로벌 가용성을 향상시키는 기술이다. CDN은 종단간 전송 네트워크를 보완하며, 웹 캐시, 서버 부하 분산, 요청 라우팅 등의 기술을 사용한다. CDN은 웹 캐싱, 서버 부하 분산, 요청 라우팅, 콘텐츠 서비스 프로토콜, P2P CDN, 프라이빗 CDN 등 다양한 기술과 형태를 갖추고 있으며, 통신 사업자 CDN, 연합 CDN, 이미지 CDN 등의 새로운 트렌드가 나타나고 있다. 주요 CDN 제공업체로는 아카마이, 아마존 클라우드프론트, 클라우드플레어 등이 있으며, 일본 CDN 시장에서는 아마존 클라우드프론트, 클라우드플레어, 아카마이가 높은 점유율을 차지하고 있다.

더 읽어볼만한 페이지

  • 콘텐츠 전송 네트워크 - 패스틀리
    패스틀리는 2011년 Artur Bergman에 의해 설립된 콘텐츠 전송 네트워크(CDN) 제공업체이며, 리버스 프록시 모델과 콘텐츠 캐싱 기술을 통해 웹사이트 트래픽을 자체 서버로 라우팅하여 사용자에게 콘텐츠를 제공한다.
  • 콘텐츠 전송 네트워크 - Cloudflare
    클라우드플레어는 2009년 설립된 미국의 웹 보안 및 성능 향상 서비스 제공 기업으로, 웹 트래픽 관리, CDN, DDoS 방어, 엣지 컴퓨팅 등 다양한 서비스를 제공하며 무료 및 유료 서비스를 통해 폭넓은 고객층을 확보하고 사업 영역을 확장해왔으나, 콘텐츠 검열 문제 등으로 비판을 받기도 한다.
  • 분산 알고리즘 - 병렬 알고리즘
    병렬 알고리즘은 여러 프로세서가 동시에 문제를 해결하도록 설계되었으며, 병렬화 가능성에 따라 분류되고 통신 오버헤드와 부하 분산이 중요하며, 다양한 하드웨어에서 구현될 수 있다.
  • 분산 알고리즘 - P2PTV
    P2PTV는 각 사용자가 비디오 스트림을 다운로드하고 업로드하여 대역폭에 기여하는 기술을 사용하며, 비트토렌트와 유사하게 작동하고, 서비스 품질 문제와 통제력 부족 등의 문제 해결을 위해 하이브리드 솔루션을 사용하기도 한다.
  • 스트리밍 - 실시간 전송 프로토콜
    실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다.
  • 스트리밍 - 페이스북 워치
    페이스북 워치는 페이스북에서 제공하는 주문형 비디오 서비스로, 오리지널 프로그램과 라이선스 콘텐츠를 제공하며 광고 수익을 창출한다.
콘텐츠 전송 네트워크

2. 기술

CDN 노드는 일반적으로 여러 위치, 종종 여러 인터넷 백본에 배포된다. 이점으로는 대역폭 비용 절감, 페이지 로드 시간 개선, 콘텐츠의 글로벌 가용성 증가 등이 있다. CDN을 구성하는 노드 및 서버의 수는 아키텍처에 따라 다르며, 일부는 수천 개의 노드와 수만 개의 서버가 여러 원격 접속 지점(PoPs)에 도달한다. 다른 CDN은 글로벌 네트워크를 구축하고 소수의 지리적 PoP를 가지고 있다.[4]

콘텐츠 요청은 일반적으로 알고리즘을 통해 최적의 노드로 전송된다. 성능을 최적화할 때는 사용자에게 콘텐츠를 제공하는 데 가장 적합한 위치(가장 가까운 엣지 서버)를 선택한다.

대부분의 CDN 제공업체는 미국, 국제 또는 글로벌, 아시아 태평양 등 원하는 범위에 따라 다양하게 정의된 PoP 집합을 통해 서비스를 제공한다. 이러한 PoP 집합은 최종 사용자에게 CDN 자산의 가장 가까운 에지이므로 "에지", "에지 노드", "에지 서버" 또는 "에지 네트워크"라고 할 수 있다.[5]

콘텐츠 전송 네트워크는 콘텐츠 전송을 최적화하도록 설계된 기술을 사용하여 다양한 지능형 애플리케이션을 배포하여 종단간 전송 네트워크를 보완한다. 결과적으로 긴밀하게 통합된 오버레이는 웹 캐싱, 서버 부하 분산, 요청 라우팅 및 콘텐츠 서비스를 사용한다.[11]

CDN은 수동 자산 복사, 활성 웹 캐시, 글로벌 하드웨어 부하 분산기 등 다양한 콘텐츠 전송 방법을 사용한다. CDN의 전송 서버 거점(노드, Point of Presence (POP)라고 불림)은 일반적으로 광범위하고 여러 위치에 전개되며, 많은 경우 여러 인터넷 백본을 통해 전개된다. 장점으로는 자사 소유 서버의 부하 경감, 접속 회선 대역폭 비용 절감, 페이지 로딩 시간 개선, 또는 콘텐츠의 글로벌 가용성 향상이 포함된다.[66] CDN을 구성하는 노드와 서버의 수는 아키텍처에 따라 다르지만, 경우에 따라 수천 개의 노드, 엣지 서버라고 불리는 서버 대수로도 수만 대에 달하는 경우가 있다.

콘텐츠 요청은 일반적으로 분산된 DNS의 CNAME 해결에서 사용자 최인접 설비 IP를 반환하는 알고리즘을 거쳐 최적의 노드로 요청이 전송된다.

접속원 사용자 최인접 노드·POP을 판정할 때는 다음 흐름으로 DNS 해결 처리가 수행된다.

# URL을 입력했을 때 사용자 DNS에서 해당 DNS 내용을 해결 요청한다.

# 의도적으로 기술된 CNAME 대상 DNS(CDN 사업자의 DNS)에 재접속된다.

# CDN 사업자의 DNS 시스템 내에서 네트워크상 최단 경로 정보나 엣지 서버의 성능 상황 등의 알고리즘을 통해 최적의 거점 IP가 반환된다.

# 여기서 최종적으로 사용자로부터 반환된 IP에 접속 요청 전송

접속원 사용자로부터 최인접 노드·엣지 서버로의 판정 알고리즘으로는 각 사에서 다양한 지표를 사용하고 있지만, 일반적으로 사용자가 접속하고 있는 ISP 설비에 대한 네트워크상 PING 결과나, 물리적인 엣지 서버의 부하 지표 등을 점수화하는 경우가 많다. CDN(콘텐츠 전송 네트워크)은 콘텐츠 전송을 최적화하도록 설계된 기술을 채택하고 활용함으로써, 에지 서버로의 캐싱에 의한 서버 부하 분산, 캐시할 수 없는 콘텐츠의 투명 라우팅 등의 결과로 웹사이트의 가용성 향상이 가능하게 되었다.

2. 1. 콘텐츠 네트워킹 기술

인터넷은 종단간 원칙에 따라 설계되었지만,[10] 콘텐츠 전송 네트워크(CDN)는 이를 보완하여 콘텐츠 전송 효율을 높인다. CDN은 웹 캐싱, 서버 부하 분산, 요청 라우팅, 콘텐츠 서비스 등 다양한 기술을 사용한다.[11]

  • '''웹 캐싱:''' 웹 캐시를 활용하여 콘텐츠를 효율적으로 관리한다.
  • '''서버 부하 분산:''' 여러 서버 간에 트래픽을 분산시켜 안정성을 높인다.
  • '''요청 라우팅:''' 사용자 요청을 최적의 서버로 전달한다.
  • '''콘텐츠 서비스:''' 다양한 프로토콜을 사용하여 콘텐츠 서비스에 접근한다.


CDN은 수동 자산 복사, 활성 웹 캐시, 글로벌 하드웨어 부하 분산기 등 다양한 콘텐츠 전송 방법을 사용한다.

2. 1. 1. 웹 캐시

웹 캐시는 요청이 많은 콘텐츠를 서버에 미리 저장하여 대역폭 요구량을 줄이고, 서버 부하를 줄이며, 캐시에 저장된 콘텐츠에 대한 응답 시간을 개선한다.[12] 웹 캐시는 사용자 요청(풀 캐싱) 또는 콘텐츠 서버에서 배포된 미리 로드된 콘텐츠(푸시 캐싱)를 기반으로 채워진다.[12]

CDN은 주로 업데이트가 적은 정적 콘텐츠와 매번 사용자마다 웹 서버 측에서 HTML 생성이 필요한 동적 콘텐츠로 구분되는데, 정적 콘텐츠는 사이트 내용량의 대부분을 차지하는 경우가 많아 캐싱을 함으로써 웹 서버의 리소스를 동적 콘텐츠 생성에 할당할 수 있다. 또한 네트워크 상에서 성능이 좋은 위치에 CDN 설비가 설치되는 경우가 많아 결과적으로 사이트 전체의 표시 속도 향상으로 이어진다.

2. 1. 2. 서버 부하 분산

서버 부하 분산은 여러 서버 또는 웹 캐시에 트래픽을 분산하여 단일 서버에 부하가 집중되는 것을 방지한다.

웹 캐시는 요청된 콘텐츠에 대한 수요가 가장 많은 서버에 인기 있는 콘텐츠를 저장한다. 이러한 공유 네트워크 장치는 대역폭 요구 사항을 줄이고, 서버 부하를 줄이며, 캐시에 저장된 콘텐츠에 대한 클라이언트 응답 시간을 개선한다. 웹 캐시는 사용자 요청(풀 캐싱) 또는 콘텐츠 서버에서 배포된 미리 로드된 콘텐츠(푸시 캐싱)를 기반으로 채워진다.[12]

서버 부하 분산은 서비스 기반(글로벌 부하 분산) 또는 하드웨어 기반(예: 계층 4–7 스위치, 웹 스위치, 콘텐츠 스위치 또는 멀티레이어 스위치라고도 함)을 포함한 하나 이상의 기술을 사용하여 여러 서버 또는 웹 캐시 간에 트래픽을 공유한다. 여기서 스위치에는 단일 가상 IP 주소가 할당된다. 그런 다음 스위치에 도착하는 트래픽은 스위치에 연결된 실제 웹 서버 중 하나로 전달된다. 이것은 부하 분산, 총 용량 증가, 확장성 향상, 실패한 웹 서버의 부하를 재분배하고 서버 상태 검사를 제공하여 안정성을 높이는 장점이 있다.[11]

콘텐츠 클러스터 또는 서비스 노드는 네트워크 내에서 여러 서버 또는 여러 웹 캐시에 부하를 분산시키기 위해 계층 4-7 스위치를 사용하여 형성될 수 있다.

2. 1. 3. 요청 라우팅

콘텐츠 요청은 일반적으로 알고리즘을 통해 최적의 노드로 전송된다. 성능 최적화를 위해 사용자에게 콘텐츠를 제공하는 데 가장 적합한 위치를 선택할 수 있다. 이는 요청하는 클라이언트로부터 가장 적은 홉(네트워킹) 수, 가장 낮은 네트워크 초, 또는 서버 성능(현재 및 과거) 측면에서 가장 높은 가용성을 선택하여 로컬 네트워크 전반에서 전달을 최적화하는 방식으로 측정할 수 있다. 비용 최적화를 위해 가장 저렴한 위치를 선택할 수도 있다. 최적의 시나리오에서는 이러한 두 가지 목표가 일치하는 경향이 있는데, 네트워크 에지에서 최종 사용자와 가까운 '''엣지 서버'''가 성능이나 비용 면에서 이점을 가질 수 있기 때문이다.[4]

대부분의 CDN 제공업체는 미국, 국제 또는 글로벌, 아시아 태평양 등 원하는 범위에 따라 다양하게 정의된 PoP 집합을 통해 서비스를 제공한다. 이러한 PoP 집합은 최종 사용자에게 CDN 자산의 가장 가까운 에지이므로 "에지", "에지 노드", "에지 서버" 또는 "에지 네트워크"라고 할 수 있다.[5]

요청 라우팅은 클라이언트 요청을 요청을 가장 잘 처리할 수 있는 콘텐츠 소스로 전달한다. 여기에는 클라이언트 요청을 클라이언트와 가장 가까운 서비스 노드 또는 용량이 가장 큰 서비스 노드로 전달하는 것이 포함될 수 있다. 요청 라우팅을 위해 다양한 알고리즘이 사용된다. 여기에는 글로벌 서버 부하 분산, DNS 기반 요청 라우팅, 동적 메타파일 생성, HTML 재작성[13]애니캐스트[14] 등이 있다. 근접성(가장 가까운 서비스 노드 선택)은 반응형 프로빙, 사전 예방적 프로빙 및 연결 모니터링을 포함한 다양한 기술을 사용하여 추정된다.[11]

2. 1. 4. 콘텐츠 서비스 프로토콜

콘텐츠 네트워크에 분산된 다양한 콘텐츠 서비스에 접근하기 위해 여러 프로토콜 스위트가 사용된다. 인터넷 콘텐츠 적응 프로토콜(ICAP)은 애플리케이션 서버 연결을 위한 개방형 표준을 제공하고자 1990년대 후반에 개발되었다.[15][16] 오픈 플러그 가능 에지 서비스(OPES) 프로토콜은 더 최근에 정의된 강력한 솔루션이다.[17] 이 아키텍처는 OPES 프로세서 자체 또는 콜아웃 서버에서 원격으로 실행 가능한 OPES 서비스 애플리케이션을 정의한다. 에지 사이드 인클루드(ESI)는 에지 레벨에서 동적 웹 콘텐츠 어셈블리를 위한 소규모 마크업 언어이다. 웹사이트 콘텐츠는 카탈로그나 포럼처럼 변경되거나 개인화되는 경우가 많아 캐싱 시스템에 문제를 일으키는데, 이를 해결하기 위해 여러 회사에서 ESI를 만들었다.

2. 2. P2P CDN

P2P 콘텐츠 전송 네트워크에서 클라이언트는 자원을 제공하면서 동시에 사용하기도 한다. 이는 클라이언트-서버 모델 시스템과 다르게, 콘텐츠 중심 네트워크에서는 사용자가 많아질수록 성능이 향상되는 특징을 갖는다. 특히 비트토렌트와 같이 사용자가 자원을 공유하도록 유도하는 프로토콜에서 이러한 특징이 두드러진다. P2P 네트워크 사용의 주요 장점 중 하나는 최초 콘텐츠 배포자의 설정 및 운영 비용이 매우 적다는 것이다.[18][19]

2. 3. Private CDN

콘텐츠 소유자가 상용 CDN 서비스의 옵션이나 비용에 만족하지 못하는 경우, 자체 CDN을 만들 수 있다. 이를 프라이빗 CDN이라고 한다. 프라이빗 CDN은 소유자만을 위해 콘텐츠를 제공하는 PoP(Point of Presence, 접속 지점)로 구성된다. 이러한 PoP는 캐싱 서버,[20] 리버스 프록시 또는 애플리케이션 전송 컨트롤러일 수 있다.[21] 이는 두 개의 캐싱 서버처럼 간단할 수도 있고,[20] 페타바이트의 콘텐츠를 제공할 만큼 클 수도 있다.[22]

대규모 콘텐츠 배포 네트워크는 콘텐츠 사본을 캐시 위치 전체에 배포하기 위해 자체 프라이빗 네트워크를 구축하고 설정하기도 한다.[23][24] 이러한 프라이빗 네트워크는 일반적으로 프라이빗 네트워크의 용량이 충분하지 않거나 용량 감소로 이어지는 장애가 발생할 경우를 대비하여 공용 네트워크와 함께 백업 옵션으로 사용된다. 동일한 콘텐츠를 여러 위치에 배포해야 하므로, 다양한 멀티캐스트 기술을 사용하여 대역폭 소비를 줄일 수 있다. 프라이빗 네트워크를 통해 사용 가능한 네트워크 용량을 보다 효율적으로 활용하기 위해 네트워크 부하 조건에 따라 멀티캐스트 트리를 선택하는 방안도 제안되었다.[25][26]

3. 보안 및 개인 정보 보호

CDN 제공업체는 네트워크를 사용하는 콘텐츠 제공자가 지불하는 직접적인 수수료나, 고객의 웹사이트에 스크립트가 로드되는 과정에서 수집된 사용자 분석 및 추적 데이터를 통해 수익을 창출한다. 이러한 서비스는 행동 타겟팅을 목적으로 잠재적인 개인 정보 침해로 지적되고 있으며, 단일 출처의 리소스 제공 및 캐싱을 복원하기 위한 솔루션이 개발되고 있다.[7]

특히, CDN을 사용하는 웹사이트는 EU의 일반 데이터 보호 규정(GDPR)을 위반할 수 있다. 예를 들어, 2021년 독일 법원은 대학교 웹사이트에서 CDN 사용을 금지했는데, 이는 사용자의 IP 주소가 CDN으로 전송되어 GDPR을 위반했기 때문이었다.[8]

JavaScript를 제공하는 CDN은 악성 콘텐츠를 삽입하는 수단으로도 표적이 되어 왔다. 서브 리소스 무결성 메커니즘은 웹사이트 작성자가 참조하는 해시에 의해 콘텐츠가 알려지고 제한된 스크립트를 페이지가 로드하도록 하기 위해 만들어졌다.[9]

4. CDN 동향

CDN 노드는 일반적으로 여러 위치, 종종 여러 인터넷 백본에 배포된다. 이는 대역폭 비용 절감, 페이지 로드 시간 개선, 콘텐츠의 글로벌 가용성 증가 등의 이점을 제공한다. CDN을 구성하는 노드 및 서버의 수는 아키텍처에 따라 다르며, 일부는 수천 개의 노드와 수만 개의 서버가 여러 원격 접속 지점(PoPs)에 도달하기도 하고, 다른 CDN은 글로벌 네트워크를 구축하고 소수의 지리적 PoP를 가지기도 한다.[4]

콘텐츠 요청은 일반적으로 알고리즘에 의해 최적의 노드로 전송된다. 성능 최적화에는 사용자에게 콘텐츠를 제공하는 데 가장 적합한 위치(요청 클라이언트로부터 가장 적은 홉(네트워킹) 수, 가장 낮은 네트워크 초, 서버 성능(현재 및 과거) 측면에서 가장 높은 가용성)를 선택한다. 비용 최적화에는 가장 저렴한 위치를 선택한다. 최적의 경우, 네트워크 에지에서 최종 사용자와 가까운 '''엣지 서버'''가 성능이나 비용 면에서 이점을 가지므로 두 목표가 일치하는 경향을 보인다.

대부분의 CDN 제공업체는 미국, 국제 또는 글로벌, 아시아 태평양 등 원하는 범위에 따라 다양하고 정의된 PoP 집합을 통해 서비스를 제공한다. 이러한 PoP 집합은 최종 사용자에게 CDN 자산의 가장 가까운 에지이므로 "에지", "에지 노드", "에지 서버" 또는 "에지 네트워크"라고 할 수 있다.[5]

인터넷은 종단간 원칙에 따라 설계되었다.[10] 이 원칙은 핵심 네트워크는 단순하게 유지하고, 지능은 네트워크 종단점(호스트 및 클라이언트)으로 이동시킨다는 것이다. 결과적으로 핵심 네트워크는 데이터 패킷 전달에 특화, 단순화, 최적화되었다.

콘텐츠 전송 네트워크는 콘텐츠 전송 최적화 기술을 사용, 다양한 지능형 애플리케이션을 배포하여 종단간 전송 네트워크를 보완한다. 긴밀하게 통합된 오버레이는 웹 캐싱, 서버 부하 분산, 요청 라우팅 및 콘텐츠 서비스를 사용한다.[11]

웹 캐시는 요청된 콘텐츠에 대한 수요가 가장 많은 서버에 인기 있는 콘텐츠를 저장, 대역폭 요구 사항과 서버 부하를 줄이고, 캐시에 저장된 콘텐츠에 대한 클라이언트 응답 시간을 개선한다. 웹 캐시는 사용자 요청(풀 캐싱) 또는 콘텐츠 서버에서 배포된 미리 로드된 콘텐츠(푸시 캐싱)를 기반으로 채워진다.[12]

서버 부하 분산은 서비스 기반(글로벌 부하 분산) 또는 하드웨어 기반(예: 계층 4–7 스위치) 기술을 사용하여 여러 서버 또는 웹 캐시 간에 트래픽을 공유한다. 스위치에는 단일 가상 IP 주소가 할당되고, 스위치에 도착하는 트래픽은 스위치에 연결된 실제 웹 서버 중 하나로 전달된다. 이는 부하 분산, 총 용량 증가, 확장성 향상, 실패한 웹 서버의 부하 재분배, 서버 상태 검사를 통한 안정성 향상 등의 장점이 있다.

콘텐츠 클러스터 또는 서비스 노드는 네트워크 내에서 여러 서버 또는 여러 웹 캐시에 부하를 분산시키기 위해 계층 4–7 스위치를 사용하여 형성될 수 있다.

요청 라우팅은 클라이언트 요청을 가장 잘 처리할 수 있는 콘텐츠 소스로 전달한다. 여기에는 클라이언트 요청을 가장 가까운 서비스 노드 또는 용량이 가장 큰 서비스 노드로 전달하는 것이 포함된다. 요청 라우팅에는 글로벌 서버 부하 분산, DNS 기반 요청 라우팅, 동적 메타파일 생성, HTML 재작성[13]애니캐스트[14] 등 다양한 알고리즘이 사용된다. 근접성(가장 가까운 서비스 노드 선택)은 반응형/사전 예방적 프로빙, 연결 모니터링 등 다양한 기술을 사용하여 추정된다.[11]

CDN은 수동 자산 복사, 활성 웹 캐시, 글로벌 하드웨어 부하 분산기 등 다양한 콘텐츠 전송 방법을 사용한다.

4. 1. 통신 사업자 CDN의 등장

스트리밍 비디오 트래픽이 급증하면서, 인터넷 서비스 제공업체(ISP)들은 가입자들을 유지하기 위해 충분히 좋은 사용자 경험 품질을 제공해야 했다.[27] 이를 위해 대규모 자본 지출을 투자해야 했다.[28]

이러한 상황에 대응하기 위해, 통신 사업자들은 네트워크 백본으로의 콘텐츠 트래픽을 줄이고, 통신 인프라 투자를 줄이고자 자체적인 콘텐츠 전송 네트워크(CDN)를 구축하기 시작했다.

4. 1. 1. 통신 사업자 CDN의 이점

통신 서비스 제공업체는 네트워크 백본에 대한 요구를 줄이고 인프라 투자를 줄이기 위해 자체 콘텐츠 전송 네트워크를 출시하기 시작했다. 통신사 CDN은 비디오 콘텐츠가 전송되는 네트워크를 소유하고 있기 때문에 기존 CDN보다 유리하다.[28] 통신사 CDN은 가입자망을 소유하고 있으며, 자체 네트워크 깊숙한 곳에 캐싱할 수 있으므로 최종 사용자에게 콘텐츠를 더 가깝게 전달할 수 있다. 이러한 딥 캐싱은 비디오 데이터가 일반 인터넷을 통해 이동하는 관리 거리를 최소화하여 더 빠르고 안정적으로 콘텐츠를 전달한다.[28]

통신사 CDN은 또한 기존 CDN이 통신사로부터 대역폭을 임대하고 자체 비용 모델에 운영자의 마진을 포함해야 하기 때문에 비용 측면에서도 유리하다. 또한 자체 콘텐츠 전송 인프라를 운영함으로써 통신 사업자는 자원 활용에 대한 더 나은 제어 능력을 갖게 된다. CDN에서 수행하는 콘텐츠 관리 작업은 일반적으로 CDN이 상호 작용하거나 비즈니스 관계를 맺고 있는 통신 사업자의 네트워크(예: 토폴로지, 사용률 등)에 대한 정보 없이(또는 매우 제한적인 정보로) 적용된다. 이는 통신 사업자가 자원 활용에 미치는 이러한 작업의 영향에 직면하여 제한된 행위 범위를 갖기 때문에 여러 가지 과제를 제기한다.[28]

4. 2. 연합 CDN 및 개방형 캐싱

2011년 6월, StreamingMedia.com은 TSPs 그룹이 전 세계에 광범위한 PoP를 보유한 아카마이와 라임라이트 네트웍스와 같은 대규모 전통적 CDN에 보다 직접적으로 경쟁하기 위해 네트워크를 상호 연결하는 Operator Carrier Exchange(OCX)를 설립했다고 보도했다.[31] 이러한 방식으로 통신 사업자는 연합 CDN 서비스를 구축하고 있으며, 이는 이 연합의 집계된 사용자에게 콘텐츠를 제공하려는 콘텐츠 제공자에게 더 흥미로운 제안이다.

가까운 미래에 다른 통신 CDN 연합이 생성될 가능성이 높다. 이들은 연합에 참여하여 네트워크 존재감과 인터넷 가입자 기반을 기존 연합에 제공하는 새로운 통신 사업자의 가입을 통해 성장할 것이다.

스트리밍 미디어 얼라이언스의 Open Caching 사양은 콘텐츠 제공자가 이러한 API를 통해 각 CDN 제공자를 동일하게 보면서 일관된 방식으로 여러 CDN을 사용하여 콘텐츠를 제공할 수 있도록 하는 일련의 API를 정의한다.

4. 3. DNS 확장 메커니즘을 사용한 CDN 성능 향상

전통적으로 CDN은 클라이언트의 재귀 DNS 리졸버의 IP 주소를 사용하여 클라이언트의 지리적 위치를 파악했다. 이는 많은 상황에서 적절한 접근 방식이지만, 클라이언트가 멀리 떨어진 비지역 재귀 DNS 리졸버를 사용하는 경우 클라이언트의 성능 저하를 초래한다. 예를 들어, CDN은 인도에 있는 클라이언트가 싱가포르에 있는 공용 DNS 리졸버를 사용하는 경우, 해당 클라이언트의 요청을 싱가포르에 있는 엣지 서버로 라우팅하여 클라이언트의 성능을 저하시킬 수 있다.[32]

2011년 8월, 구글(Google)이 주도하는 주요 인터넷 서비스 제공업체의 글로벌 컨소시엄은 DNS 확인 응답의 정확한 지역화를 위한 edns-client-subnet IETF Internet Draft의 공식 구현을 발표했다.[33] 이 이니셔티브에는 Google Public DNS와 같은 제한된 수의 주요 DNS 서비스 제공업체[34] 및 CDN 서비스 제공업체도 참여한다. edns-client-subnet EDNS0 옵션을 사용하면, CDN은 DNS 요청을 해결할 때 요청하는 클라이언트의 서브넷 IP 주소를 활용할 수 있다. 엔드 유저 매핑[32]이라고 불리는 이 접근 방식은 CDN에 의해 채택되었으며, 공용 DNS 또는 기타 비지역 리졸버를 사용하는 클라이언트의 왕복 지연 시간을 대폭 줄이고 성능을 향상시키는 것으로 나타났다.



그러나 EDNS0의 사용은 재귀 리졸버에서 확인 캐싱의 효과를 감소시키고,[32] 총 DNS 확인 트래픽을 증가시키며,[32] 클라이언트의 서브넷 노출에 대한 개인 정보 보호 문제를 제기하는 단점도 있다.

4. 4. 가상 CDN (vCDN)

Virtual CDN영어 (vCDN)은 가상화 기술을 사용하여 콘텐츠 전송 네트워크(CDN)를 구축하는 방식이다.[35][36][37][38] 기존 CDN이 물리적인 서버를 기반으로 캐시를 배포하는 반면, vCDN은 가상 캐시를 사용한다. 이 가상 캐시는 제공업체의 지리적 범위에 분산된 물리적 서버에 가상 머신 또는 컨테이너 형태로 동적으로 배포된다.[35][36][37][38]

vCDN은 가상 캐시 배치를 통해 성능, 안정성, 가용성과 같은 기존 CDN의 제한을 극복한다.[35][36][37][38] 가상 캐시 배치는 콘텐츠 유형과 서버 또는 최종 사용자의 지리적 위치를 기반으로 이루어지기 때문에 서비스 제공 및 네트워크 정체 해소에 효과적이다.[35][36][37][38]

최근 사물 인터넷(IoT) 기기가 증가하면서 데이터 센터와 클라우드에서 처리되는 데이터 양이 방대해지고 있다. 이로 인해 클라우드 측 네트워크 대역폭 요구 사항이 한계에 도달하는 경우가 많다. IoT 기기는 항상 클라우드 측과의 실시간 데이터 통신을 요구하기 때문에, CDN을 구축하여 데이터 및 서비스 프로비저닝을 분산시키고 최종 사용자와의 물리적 근접성을 확보하는 것이 중요하다. 이러한 추세에 따라 기존 CDN 엣지 서버를 가상화하여 사용자에게 개방하고, 사용자가 자유롭게 애플리케이션을 배치하여 엣지 컴퓨팅으로 활용할 수 있는 서비스가 확산되고 있다.

4. 5. 이미지 최적화 및 전송 (이미지 CDN)

이미지 CDN은 요청하는 브라우저의 속성에 따라 HTTP를 통해 동일한 이미지의 여러 버전을 제공하는 웹 아키텍처의 기능이다. 구글(Google)의 애디 오스마니는 2017년에 <picture> 요소를 언급하며, 반응형 웹 디자인 패러다임과 자연스럽게 통합될 수 있는 소프트웨어 솔루션을 이미지 CDN이라고 칭했다.[39] 이미지 CDN의 목적은 다운로드 속도를 유지하면서 고품질 이미지(또는 인간의 눈으로 고품질로 인식되는 이미지)를 제공하여 훌륭한 사용자 경험(UX)에 기여하는 것이다.

이미지 CDN은 일반적으로 다음 세 가지 구성 요소를 지원한다:[41]

  • 이미지의 빠른 제공을 위한 콘텐츠 전송 네트워크(CDN).
  • URL 지시어를 통해 즉석에서, 일괄 모드(이미지 수동 업로드를 통해) 또는 완전 자동(또는 이들의 조합)으로 이미지 조작 및 최적화.
  • 장치 감지(장치 인텔리전스라고도 함), 즉 사용자 에이전트 문자열, HTTP Accept 헤더, 클라이언트 힌트 또는 자바스크립트 분석을 통해 요청하는 브라우저 및/또는 장치의 속성을 결정하는 기능.


다음은 주요 이미지 CDN 솔루션의 현황을 요약한 표이다:[42]

시장의 주요 이미지 CDN
이름CDN이미지 최적화장치 감지
Akamai ImageManager일괄 모드HTTP Accept 헤더 기반
Cloudflare Polish완전 자동HTTP Accept 헤더 기반
CloudinaryAkamai를 통해일괄, URL 지시어Accept 헤더, 클라이언트 힌트
Fastly IOURL 지시어HTTP Accept 헤더 기반
ImageEngine완전 자동WURFL, 클라이언트 힌트, Accept 헤더
ImgixFastly를 통해완전 자동Accept 헤더 / 클라이언트 힌트
PageCDNURL 지시어HTTP Accept 헤더 기반
Tinify CDN여러 개완전 자동HTTP Accept 헤더 기반


5. 주요 콘텐츠 전송 서비스 제공업체

크게 상용 CDN, 통신 사업자 CDN, P2P 기반 상용 CDN, 자체 구축 CDN(In-house CDN)으로 분류할 수 있다.

=== 상용 CDN ===

아카마이(Akamai Technologies), 아마존 클라우드프론트(Amazon CloudFront), 아리야카(Aryaka), 아테메(Ateme CDN), 애저 서비스 플랫폼(Azure CDN), 캐시플라이(CacheFly), CD네트웍스(CDNetworks), 센터서브 인터내셔널(CenterServ), 차이나캐시(ChinaCache), 클라우드플레어(Cloudflare), 코텐도(Cotendo), 에지오(Edgio), 패스틀리(Fastly), Gcore, 구글 클라우드 CDN(Google Cloud CDN), HP 클라우드 서비스(HP Cloud Services), 인캡슐라(Incapsula), 인스타트(Instart), 인터냅(Internap), 리스웹(LeaseWeb), 루멘 테크놀로지스(Lumen Technologies), 메타CDN(MetaCDN), NACEVI, 온앱(OnApp), 고대디(GoDaddy), OVH클라우드(OVHcloud), 랙스페이스 클라우드(Rackspace Cloud Files), 스피데라 네트웍스(Speedera Networks), 스트림질라(StreamZilla), 왕수 사이언스 & 테크놀로지(Wangsu Science & Technology), 요타(Yottaa) 등 다양한 기업들이 서비스를 제공하고 있다.[45][46]

분류기업
미국계
유럽계
국내
중국계
한국계
기타



=== 통신 사업자 CDN ===

통신 사업자는 자체 네트워크를 소유하고 있어 기존 CDN보다 유리하다. 가입자망을 통해 자체 네트워크 깊숙한 곳에 캐싱하여 최종 사용자에게 더 가까이 콘텐츠를 전달할 수 있다. 딥 캐싱은 비디오 데이터의 관리 거리를 최소화하여 더 빠르고 안정적인 전송을 가능하게 한다.[4] 또한, 자체 인프라 운영으로 자원 활용에 대한 제어 능력이 향상된다.[4]

통신 사업자
AT&T
바르티 에어텔
벨 캐나다
BT 그룹
차이나텔레콤
중화 텔레콤
도이치텔레콤
KT
KPN
루멘 테크놀로지스
메가폰
NTT
팩넷
PCCW
싱텔
SK브로드밴드
타타 커뮤니케이션즈
텔레콤 아르헨티나
텔레포니카
텔레노르
텔리아소네라
텔린
텔스트라
텔러스
TIM
튀르크 텔레콤
버라이즌



=== P2P 기반 상용 CDN ===

P2P 기반 CDN은 클라이언트가 자원을 제공하고 사용한다. 클라이언트-서버 모델 시스템과 달리, 사용자가 많을수록 성능이 향상될 수 있다. 특히 비트토렌트와 같은 프로토콜에서 두드러지며, 초기 배포자의 운영 비용을 절감하는 장점이 있다.[18][19]



=== 기타 CDN ===

메타CDN과 와프캐시[47][48]는 콘텐츠 전송 방식의 한 종류이다. 넷플릭스[49]는 자체 전용 CDN을 구축하여 운영하고 있다.

5. 1. 무료


  • cdnjs[43][44]
  • 클라우드플레어(Cloudflare)
  • JSDelivr

5. 2. 전통적인 상용 CDN

아카마이(Akamai Technologies), 아마존 클라우드프론트(Amazon CloudFront), 아리야카(Aryaka), 아테메(Ateme CDN), 애저 서비스 플랫폼(Azure CDN), 캐시플라이(CacheFly), CD네트웍스(CDNetworks), 센터서브 인터내셔널(CenterServ), 차이나캐시(ChinaCache), 클라우드플레어(Cloudflare), 코텐도(Cotendo), 에지오(Edgio), 패스틀리(Fastly), Gcore, 구글 클라우드 CDN(Google Cloud CDN), HP 클라우드 서비스(HP Cloud Services), 인캡슐라(Incapsula), 인스타트(Instart), 인터냅(Internap), 리스웹(LeaseWeb), 루멘 테크놀로지스(Lumen Technologies), 메타CDN(MetaCDN), NACEVI, 온앱(OnApp), 고대디(GoDaddy), OVH클라우드(OVHcloud), 랙스페이스 클라우드(Rackspace Cloud Files), 스피데라 네트웍스(Speedera Networks), 스트림질라(StreamZilla), 왕수 사이언스 & 테크놀로지(Wangsu Science & Technology), 요타(Yottaa) 등 다양한 기업들이 상용 CDN 서비스를 제공하고 있다.[45][46]

이 외에도 애플, 넷플릭스 등 자체 전용 CDN을 구축하는 기업들도 존재한다.

상용 CDN 제공업체들은 다음과 같이 분류할 수 있다.

분류기업
미국계
유럽계
국내
중국계
한국계
기타


5. 3. 통신 사업자 CDN

통신 사업자 CDN은 비디오 콘텐츠가 전송되는 네트워크를 소유하고 있어 기존 CDN보다 유리하다. 통신사 CDN은 가입자망을 소유하고 있으며, 자체 네트워크 깊숙한 곳에 캐싱할 수 있으므로 최종 사용자에게 콘텐츠를 더 가깝게 전달할 수 있다. 이러한 딥 캐싱은 비디오 데이터가 일반 인터넷을 통해 이동하는 관리 거리를 최소화하여 더 빠르고 안정적으로 콘텐츠를 전달한다.[4]

통신사 CDN은 또한 기존 CDN이 통신사로부터 대역폭을 임대하고 자체 비용 모델에 운영자의 마진을 포함해야 하기 때문에 비용 측면에서도 유리하다. 또한 자체 콘텐츠 전송 인프라를 운영함으로써 통신 사업자는 자원 활용에 대한 더 나은 제어 능력을 갖게 된다. CDN에서 수행하는 콘텐츠 관리 작업은 일반적으로 CDN이 상호 작용하거나 비즈니스 관계를 맺고 있는 통신 사업자의 네트워크(예: 토폴로지, 사용률 등)에 대한 정보 없이(또는 매우 제한적인 정보로) 적용된다. 이는 통신 사업자가 자원 활용에 미치는 이러한 작업의 영향에 직면하여 제한된 행위 범위를 갖기 때문에 여러 가지 과제를 제기한다.[4]

반면, 통신사 CDN의 배치는 통신 사업자가 자체 콘텐츠 관리 작업을 구현할 수 있도록 하여 자원 활용에 대한 더 나은 제어를 가능하게 하고, 이를 통해 최종 사용자에게 더 나은 품질의 서비스와 경험을 제공할 수 있도록 한다.[4]

다음은 통신 사업자 CDN 목록이다.

통신 사업자
AT&T
바르티 에어텔
벨 캐나다
BT 그룹
차이나텔레콤
중화 텔레콤
도이치텔레콤
KT
KPN
루멘 테크놀로지스
메가폰
NTT
팩넷
PCCW
싱텔
SK브로드밴드
타타 커뮤니케이션즈
텔레콤 아르헨티나
텔레포니카
텔레노르
텔리아소네라
텔린
텔스트라
텔러스
TIM
튀르크 텔레콤
버라이즌


5. 4. P2P 기반 상용 CDN

P2P 기반 콘텐츠 전송 네트워크(CDN)에서는 클라이언트가 자원을 제공하고 사용하기도 한다. 이는 클라이언트-서버 모델 시스템과 달리, 더 많은 사용자가 콘텐츠에 접근할수록 콘텐츠 중심 네트워크의 성능이 향상될 수 있음을 의미한다. 특히 사용자가 공유하도록 요구하는 비트토렌트와 같은 프로토콜에서 이러한 속성이 두드러진다.[18][19] 이는 P2P 네트워크 사용의 주요 장점 중 하나이며, 초기 콘텐츠 배포자의 설정 및 운영 비용을 매우 낮춘다.[18][19]

5. 5. Multi CDN

메타CDN과 와프캐시[47][48]는 콘텐츠 전송 방식의 한 종류이다.

5. 6. In-house CDN

넷플릭스[49]는 자체 전용 CDN을 구축하여 운영하고 있다.

6. 일본의 CDN

다음은 일본의 CDN 제공 사업자 현황을 정리한 표이다. 각 사업자의 CDN 서비스명, 엣지 캐시 유무, 그리고 주요 인터넷 교환(IX) 지점에서의 자체 퍼블릭 피어링 대역 정보를 확인할 수 있다.

'''CDN 제공 사업자의 일본 현황'''
사업자CDN 서비스명엣지 캐시(ISP 내 등)자사 퍼블릭 피어링 대역(프라이빗 피어링, 간접 연결, 타사 클라우드 캐시, ISP 내 캐시 등은 포함하지 않음)비고
JPNAP 도쿄JPNAP 오사카JPNAP 후쿠오카JPIX 도쿄JPIX 오사카JPIX 후쿠오카BBIX 도쿄BBIX 오사카BBIX 후쿠오카
아카마이 테크놀로지스Akamai CDN[57][58][59][60][61][62][63][64][65]
Amazon.comAmazon CloudFront?[57][58][59][60][61][62][63][64][65]
클라우드플레어Cloudflare CDN?[57][58][59][60][61][62][63][64][65]
Edgio영어Edgio Delivery[57][58][59][60][61][62][63][64][65]
구글Google Cloud CDN?[57][58][59][60][61][62][63][64][65]
패스토리Fastly CDN?[57][58][59][60][61][62][63][64][65]IDC Frontier가 제공하는 IDCF Cloud CDN도 있음
F5 네트웍스Distributed Cloud CDN?[57][58][59][60][61][62][63][64][65]
IBMIBM Cloud CDN?[57][58][59][60][61][62][63][64][65]
마이크로소프트Azure CDN?[57][58][59][60][61][62][63][64][65]
Gcore영어Gcore CDN?[57][58][59][60][61][62][63][64][65]
AdvancedHostersAHCDN?[57][58][59][60][61][62][63][64][65]
i3D.netCDN?[57][58][59][60][61][62][63][64][65]
DatacampCDN77?[57][58][59][60][61][62][63][64][65]
인터넷 이니셔티브GIO 콘텐츠 가속 서비스?[57][58][59][60][61][62][63][64][65]
아켈리아DuraSite-CDN?[57][58][59][60][61][62][63][64][65]
제이스트림J-Stream CDNext?[57][58][59][60][61][62][63][64][65]
JOCDNCDN??????????
레드 박스엣지 캐시??????????버스트 트래픽 옵션은 10Gbps 복수 연결
사쿠라 인터넷웹 가속기?[57][58][59][60][61][62][63][64][65]
알리바바 그룹Cloud CDN?[57][58][59][60][61][62][63][64][65]
텐센트Cloud CDN?[57][58][59][60][61][62][63][64][65]
화웨이Huawei Cloud CDN?[57][58][59][60][61][62][63][64][65]
바이트댄스 / BytePlusBytePlus CDN?[57][58][59][60][61][62][63][64][65]
ZenlayerContent Delivery Network Solutions?[57][58][59][60][61][62][63][64][65]
네이버 / NAVER CloudNAVER Cloud Platform CDN?[57][58][59][60][61][62][63][64][65]
CDNetworks영어?????????


참고: 위 표에서 '?'는 해당 정보가 불확실하거나 확인되지 않았음을 의미한다.

7. 일본 내 CDN 점유율 동향

최근 일본 내 CDN 시장 점유율은 CloudFront(아마존 웹 서비스), Cloudflare, Akamai Technologies 3개 서비스가 대부분을 차지하고 있다.[70][71][72][73][74][75][76][77][78]

일본어 사이트 CDN 점유율
조사 시기1위2위3위출처
2017년 4월CloudflareCloudFrontAkamai[70]
2017년 10월CloudflareCloudFrontAkamai[71]
2018년 4월CloudflareCloudFrontAkamai[72]
2018년 10월CloudFrontCloudflareAkamai[73]
2019년 4월CloudFrontCloudflareAkamai[74]
2019년 10월CloudFrontCloudflareAkamai[75]
2020년 4월CloudFrontCloudflareAkamai[76]
2020년 10월CloudFrontCloudflareAkamai[77]
2021년 4월CloudFrontCloudflareAkamai[78]



JP 도메인 사이트 CDN 점유율
조사 시기1위2위3위출처
2017년 4월CloudFrontAkamaiCloudflare[71]
2017년 10월CloudFrontAkamaiCloudflare[71]
2018년 4월CloudFrontAkamaiCloudflare[72]
2018년 10월CloudFrontAkamaiCloudflare[73]
2019년 4월CloudFrontAkamaiCloudflare[74]
2019년 10월CloudFrontAkamaiCloudflare[75]
2020년 4월CloudFrontCloudflareAkamai[76]
2020년 10월CloudFrontCloudflareAkamai[77]
2021년 4월CloudFrontCloudflareAkamai[78]


참조

[1] 웹사이트 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
[2] 간행물 The Akamai Network: A Platform for High-Performance Internet Applications http://www.akamai.co[...] 2012-11-19
[3] 서적 UNIX and Linux system administration handbook Pearson Education
[4] 웹사이트 How Content Delivery Networks Work http://www.cdnetwork[...] 2015-09-22
[5] 웹사이트 How Content Delivery Networks (CDNs) Work https://www.nczonlin[...] 2011-11-29
[6] 웹사이트 470 million sites exist for 24 hours, 22% are malicious https://www.helpnets[...] 2014-08-27
[7] 웹사이트 Decentraleyes: Block CDN Tracking https://collinmbarre[...] 2016-02-03
[8] 뉴스 VG Wiesbaden verbietet die Nutzung von Content Delivery Networks https://www.taylorwe[...] 2021-12-14
[9] 웹사이트 Subresource Integrity https://developer.mo[...]
[10] Q Q56503280 2006-11-11
[11] 서적 Content Networking: Architecture, Protocols, and Practice Morgan Kaufmann Publisher
[12] 간행물 Speculative Data Dissemination and Service to Reduce Server Load, Network Traffic and Service Time for Distributed Information Systems http://www.cs.bu.edu[...] 1996-03
[13] IETF RFC '3568 Barbir, A., Cain, B., Nair, R., Spatscheck, O.: "Known Content Network (CN) Request-Routing Mechanisms," July 2003'
[14] IETF RFC '1546 Partridge, C., Mendez, T., Milliken, W.: "Host Anycasting Services," November 1993.'
[15] IETF RFC '3507 Elson, J., Cerpa, A.: "Internet Content Adaptation Protocol (ICAP)," April 2003.'
[16] 웹사이트 ICAP Forum https://web.archive.[...]
[17] IETF RFC '3835 Barbir, A., Penno, R., Chen, R., Hofmann, M., and Orman, H.: "An Architecture for Open Pluggable Edge Services (OPES)," August 2004.'
[18] 간행물 On peer-to-peer (P2P) content delivery http://www.land.ufrj[...]
[19] 서적 NETWORKING 2005 -- Networking Technologies, Services, and Protocols; Performance of Computer and Communication Networks; Mobile and Wireless Communications Systems Springer
[20] 웹사이트 How to build your own CDN using BIND, GeoIP, Nginx, Varnish - UNIXy http://blog.unixy.ne[...] 2010-07-18
[21] 웹사이트 How to Create Your Content Delivery Network With aiScaler http://aiscaler.com/[...]
[22] 웹사이트 Netflix Shifts Traffic To Its Own CDN; Akamai, Limelight Shrs Hit https://www.forbes.c[...] 2012-06-05
[23] 웹사이트 Building Express Backbone: Facebook's new long-haul network https://code.faceboo[...] 2017-05-01
[24] 웹사이트 Inter-Datacenter WAN with centralized TE using SDN and OpenFlow https://www.opennetw[...] 2012
[25] 웹사이트 DCCast: Efficient Point to Multipoint Transfers Across Datacenters https://www.research[...] USENIX 2017-07-10
[26] 웹사이트 QuickCast: Fast and Efficient Inter-Datacenter Transfers using Forwarding Tree Cohorts https://www.research[...] 2018
[27] 웹사이트 Online Video Sees Tremendous Growth, Spurs some Major Updates http://siliconangle.[...] 2011-03-03
[28] 웹사이트 Overall Telecom CAPEX to Rise in 2011 Due to Video, 3G, LTE Investments http://www.cellular-[...]
[29] 문서 D. Tuncer, M. Charalambides, R. Landa, G. Pavlou, "More Control Over Network Resources: an ISP Caching Perspective", proceedings of IEEE/IFIP Conference on Network and Service Management (CNSM), Zurich, Switzerland, October 2013.
[30] 문서 M. Claeys, D. Tuncer, J. Famaey, M. Charalambides, S. Latre, F. De Turck, G. Pavlou, "Proactive Multi-tenant Cache Management for Virtualized ISP Networks", proceedings of IEEE/IFIP Conference on Network and Service Management (CNSM), Rio de Janeiro, Brazil, November 2014.
[31] 웹사이트 Telcos and Carriers Forming New Federated CDN Group Called OCX (Operator Carrier Exchange) https://web.archive.[...] 2017-12-13
[32] 웹사이트 End-User Mapping: Next Generation Request Routing for Content Delivery, by F. Chen, R. Sitaraman, and M. Torres, ACM SIGCOMM conference, Aug 2015. https://people.cs.um[...]
[33] 웹사이트 Client Subnet in DNS Requests http://tools.ietf.or[...]
[34] 웹사이트 Where are your servers currently located? https://developers.g[...]
[35] 간행물 Simulating large vCDN networks: A parallel approach 2019-04-01
[36] 간행물 Towards simulation and optimization of cache placement on large virtual content distribution networks 2020-01-01
[37] 간행물 OPAC: An optimal placement algorithm for virtual CDN 2017-06-19
[38] 서적 2017 IEEE 42nd Conference on Local Computer Networks (LCN) IEEE 2017-10
[39] 웹사이트 Essential Image Optimization https://images.guide[...] 2020-05-13
[40] 웹사이트 Let The Content Delivery Network Optimize Your Images https://www.smashing[...] 2020-05-13
[41] 웹사이트 Use image CDNs to optimize images https://web.dev/imag[...] 2020-05-13
[42] 웹사이트 Faster Paint Metrics with Responsive Image Optimization CDNs https://medium.com/@[...] 2020-05-13
[43] 웹사이트 Top 4 CDN services for hosting open source libraries {{!}} opensource.com https://opensource.c[...] opensource.com 2019-04-18
[44] 웹사이트 Usage Statistics and Market Share of JavaScript Content Delivery Networks for Websites https://w3techs.com/[...] W3Techs 2019-04-17
[45] 웹사이트 How CDN and International Servers Networking Facilitate Globalization http://www.huffingto[...] Delarno Delvix 2016-09-09
[46] 웹사이트 Cloud Content Delivery Network (CDN) Market Investigation Report http://www.realviewp[...] 2019-10-07
[47] 웹사이트 CDN: Was Sie über Content Delivery Networks wissen müssen https://www.computer[...] 2019-03-21
[48] 웹사이트 Warpcache review https://www.techrada[...] 2019-03-21
[49] 문서 How Netflix works: the (hugely simplified) complex stuff that happens every time you hit Play https://medium.com/r[...]
[50] 문서 ライムライトからエッジオへ――新会社エッジオ・ジャパンでセキュリティ分野に注力 https://cloud.watch.[...] Impress 2022-09-15
[51] 문서 ShapeおよびVolterraはF5 Distributed Cloud Servicesとなりました https://www.f5.com/j[...] F5ネットワークス 2022-02-15
[52] 문서 IIJがCDNサービス開始--データ転送量課金のみでDDoS攻撃対策も標準 https://japan.zdnet.[...] ZDNET Japan 2013-04-15
[53] 문서 Lumen to wind down CDN business, sell customers to Akamai https://www.datacent[...] Data Centre Dynamics 2023-10-10
[54] 문서 Akamai Technologies Acquires Select Enterprise Customer Contracts from StackPath https://www.prnewswi[...] PRNewswire 2023-08-24
[55] 문서 StackPath quits CDN business, Akamai buys enterprise customer contracts https://www..com/en/[...] Data Center Dynamics 2023-08-29
[56] 문서 StackPath to close down, liquidate assets https://www.datacent[...] Data Centre Dynamics 2024-06-17
[57] 문서 JPNAP Tokyo https://www.peeringd[...] PeeringDB
[58] 문서 JPNAP Osaka https://www.peeringd[...] PeeringDB
[59] 문서 JPNAP Fukuoka https://www.peeringd[...] PeeringDB
[60] 문서 JPIX TOKYO https://www.peeringd[...] PeeringDB
[61] 문서 JPIX OSAKA https://www.peeringd[...] PeeringDB
[62] 문서 JPIX FUKUOKA https://www.peeringd[...] PeeringDB
[63] 문서 BBIX Tokyo https://www.peeringd[...] PeeringDB
[64] 문서 BBIX Osaka https://www.peeringd[...] PeeringDB
[65] 문서 BBIX Fukuoka https://www.peeringd[...] PeeringDB
[66] 웹사이트 ファストリー通信障害で注目 高速化技術「CDN」に死角 https://www.nikkei.c[...] 日本経済新聞 2021-06-13
[67] 뉴스 大規模システム障害、世界数千件に影響 1500億円損失も https://www.nikkei.c[...] 日本経済新聞 2021-06-09
[68] 뉴스 Fastlyの大規模障害に「マルチCDNは非現実的」 正しい対策は? “CDNの中の人”に聞く https://www.itmedia.[...] ITmedia News 2021-06-14
[69] 뉴스 「知られざる企業」で起きたシステム障害は、こうして世界中でネットワークを“停止”させた https://wired.jp/202[...] WIRED 2021-06-12
[70] 웹사이트 日本のCDNシェアについて調査結果@2017年4月 https://tech.jstream[...] Jストリーム 2019-04-10
[71] 웹사이트 日本のCDNシェアについて調査結果@2017年10月 https://tech.jstream[...] Jストリーム 2019-04-10
[72] 웹사이트 日本のCDNシェアについて調査結果@2018年4月 https://tech.jstream[...] Jストリーム 2019-04-10
[73] 웹사이트 日本のCDNシェアについて調査結果@2018年10月 https://tech.jstream[...] Jストリーム 2019-04-10
[74] 웹사이트 日本のCDNシェアについて調査結果@2019年4月 https://tech.jstream[...] Jストリーム 2021-06-09
[75] 웹사이트 日本のCDNシェアについて調査結果@2019年10月 https://tech.jstream[...] Jストリーム 2021-06-09
[76] 웹사이트 日本のCDNシェアについて調査結果@2020年4月 https://tech.jstream[...] Jストリーム 2021-06-09
[77] 웹사이트 日本のCDNシェアについて調査結果@2020年10月 https://tech.jstream[...] Jストリーム 2021-06-09
[78] 웹사이트 日本のCDNシェアについて調査結果@2021年4月 https://tech.jstream[...] Jストリーム 2021-06-09
[79] 웹인용 CDN(콘텐츠전송네트워크) http://www.dt.co.kr/[...] 디지털타임스 2012-02-25



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com