학교
[컴퓨터 네트워크] Chapter2. Application Layer (Part 2) - (3)
[3] Client-server vs P2P : example
: 클라이언트/피어 수(N)가 증가함에 따라 두 모델의 최소 분배 시간을 보여주는 공식과 그래프를 제공한다.
1) 주요 포인트
클라이언트 업로드 속도(u)와 서버 업로드 속도(us)가 주어지며, us = 10u
그래프는 N(클라이언트 또는 peer의 수)이 증가함에 따라 P2P 분배가 일반적으로 클라이언트-서버보다 더 빠르게 작동한다는 것을 보여준다.
분배 시간에 대한 공식이 제공된다.
클라이언트-서버: Dc-s = max{NF/us, F/dmin}
P2P: Dp2p = max{F/us, F/dmin, NF/(us + Σui)}
[4] Exercise
1) 문제
F = 15Gbits의 파일을 N개의 Peer에게 배포한다고 가정해보자.
서버의 업로드 속도는 us = 30Mbps이고
각 peer의 다운로드 속도는 di = 2Mbps이고, 업로드 속도는 u이다.
N = 10 / 100 / 1,000이고
u = 300Kbps, 700Kbps, 2Mbps일 때
u의 각 조합 N과 Client-server 배포 및 P2P 배포 모두에 대한 최소 배포 시간을 나타내는 차트를 준비하자.
2-1) 풀이 (Client-Server)
(1) u = 300Kbps / u = 700Kbps / u = 2Mbps
N = 10= max{NF/u_s, F/d}
NF/u_s = 10 * (15 * 1,000,000,000) / (30 * 1,000,000)
F/d = (15 * 1,000,000,000) / (2 * 1,000,000)= max{5000, 7500}= 7,500
N = 100= max{NF/Fu_s, F/d}
NF/u_s = 100 * (15 * 1,000,000,000) / (30 * 1,000,000)
F/d = (15 * 1,000,000,000) / (2 * 1,000,000)= max{50000, 7500}= 50,000
N = 1000= max{NF/u_s, F/d}
NF/u_s = 1000 * (15 * 1,000,000,000) / (30 * 1,000,000)
F/d = (15 * 1,000,000,000) / (2 * 1,000,000)= max{500000, 7500}= 500,000
(2) Client-Server의 경우 u_i와 관련이 없으므로, u의 세 가지 모두 경우와 동일하다.
2-2) 풀이 (P2P)
공통 값
F/us = 15Gbits / 30Mbps = 500초
F/dmin = 15Gbits / 2Mbps = 7,500초
(1) u = 300Kbs
N = 10= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (10 * 15 * 1,000,000,000) / (30 * 1,000,000 + (10 * 300,000)) = 4,545.4545454545-** Σu_i = N * u_i**= max{500, 7500, 4545}= 7,500
N = 100= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (100 * 15 * 1,000,000,000) / (30 * 1,000,000 + (100 * 300,000)) = 25,000-** Σu_i = N * u_i**= max{500, 7500, 25,000}= 25,000
N = 1000= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (1,000 * 15 * 1,000,000,000) / (30 * 1,000,000 + (1,000 * 300,000)) = 45,454.5454545455-** Σu_i = N * u_i**= max{500, 7500, 45,455}= 45,455
(2) u = 700Kbps
N = 10= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (10 * 15 * 1,000,000,000) / (30 * 1,000,000 + (10 * 700,000)) = 4,054.05405405405-** Σu_i = N * u_i**= max{500, 7500, 4,054}= 7,500
N = 100= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (100 * 15 * 1,000,000,000) / (30 * 1,000,000 + (100 * 700,000)) = 15,000-** Σu_i = N * u_i**= max{500, 7500, 15,000}= 15,000
N = 1000= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (1,000 * 15 * 1,000,000,000) / (30 * 1,000,000 + (1,000 * 700,000)) = 20,547.9452054795-** Σu_i = N * u_i**= max{500, 7500, 20,548}= 20,547
(3) u = 2,000Kbps
N = 10= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (10 * 15 * 1,000,000,000) / (30 * 1,000,000 + (10 * 2,000,000)) = 3,000-** Σu_i = N * u_i**= max{500, 7500, 3,000}= 7,500
N = 100= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (100 * 15 * 1,000,000,000) / (30 * 1,000,000 + (100 * 2,000,000)) = 6,522-** Σu_i = N * u_i**= max{500, 7500, 6,522}= 7,500
N = 1000= max{F/u_s, F/d, NF/(u_s +Σu_i)}
F/u_s = (15 * 1,000,000,000) / (30 * 1,000,000) = 500
F/d = (15 * 1,000,000,000) / (2 * 1,000,000) = 7,500
NF/(u_s +Σu_i) = (1,000 * 15 * 1,000,000,000) / (30 * 1,000,000 + (1,000 * 2,000,000)) = 7,389-** Σu_i = N * u_i**= max{500, 7500, 7,389}= 7,500
3) 요약
(1) Client-Server
: u(클라이언트 업로드 속도)에 영향을 받지 않고, 서버가 주로 모든 클라이언트에게 파일을 분배한다.
: N에 따라 분배 시간이 선형적으로 증가한다. (N이 커질수록 서버의 업로드 한계 때문에 시간이 길어진다.)
(2) P2P
: 각 클라이언트가 자신이 받은 파일을 다른 클라이언트에게 공유하므로, u(클라이언트 업로드 속도)가 중요한 역할을 한다.
: N이 커질수록, 그리고 클라이언트의 업로드 속도가 빨라질수록 분배 시간이 줄어든다.
[5] P2P 파일 배포 : BitTorrent
1) BitTorrent란?
파일을 작은 청크(chunks)로 나누어 분배하는 P2P 프로토콜이다.
각 청크는 256KB 크기이다.
전송 / 수신 파일 청크의 개
이를 통해 사용자는 파일 전체를 다운받기 전에, 작은 청크 단위로 파일을 받으며 공유할 수 있다.
2) tracker / torrent
tracker : 토렌트에 참여하는 동료(peer)들을 추적하는 서버 역할을 한다.
peer들의 목록을 관리하여, 청크 교환이 원활하게 이루어지도록 돕는다.
torrent : 파일 청크를 교환하는 peer들의 그룹이다.
이 그룹 내에서 청크들이 상호 교환된다.
3) 예시
앨리스가 도착하면, 트래커에서 피어들의 목록을 받아온다.
그런 다음, 앨리스는 파일 청크를 다른 피어들과 교환하기 시작한다.
이 방식으로 앨리스는 파일을 점차 완성하게 된다.
4-1) 특징 1 : 새로운 피어의 합류
새로운 피어가 합류하면 파일 청크를 점차 받고, 시간이 지남에 따라 파일을 완성한다.
이때 tracker에 등록하고, peer 목록을 얻고, peer의 하위 집합 ('이웃')과 파일 청크를 교환한다.
4-2) 특징 2 : 업로드 중 청크 교환
perr는 파일을 다운로드하는 동안 동시에 다른 peer들에게도 파일을 업로드할 수 잇다.
peer는 필요에 따라 교환할 peer를 변경할 수도 있다.
chrun : peer가 왔다갔다 할 수 있음
peer가 전체 파일을 가지고 있으면, (이기적으로) torrent를 떠나거나, (이타적으로) torrent에 남아 있을 수 있다.
[6] BitTorrent : requesting, sending file chunks
1) Request chunks (청크 요청하기)
주어진 시간에 피어마다 서로 다른 청크의 하위집합을 가지고 있다.: 서로 다른 peer들이 파일의 다른 부분(청크)을 가지고 있다.
주기적으로 Alice는 각 peer에게 보유한 청크 목록을 요청한다.
Alice는 peer에게 누락된 청크를 가장 희귀한 청크로부터 요청한다.: 이때, Alice는 가장 희귀한 청크부터 시작하여, 누락된 청크를 peer들에게 요청한다.
2) Sending chunks : tit-for-tat (청크 보내기 : 맞짱 뜨기)
Alice는 현재 가장 빠른 속도로 청크를 보내고 있는 네 명의 peer에게 청크를 보낸다.
다른 peer들은 Alice로부터 청크를 받지 못한다. (Alice로부터 청크를 받지 않음) -> chocked
10초마다 상위 4개를 재평가한다.
30초마다 : 무작위로 다른 peer를 선택하고, 청크 전송을 시작한다.
이를 'optimistically unchoke'라고 한다.
새로 선택된 peer에게도 상위 4개에 합류할 수 있는 기회를 준다.
3) 정리
: 이 방식은 공정성을 유지하면서 효율적인 파일 공유를 가능하게 한다. 빠른 속도로 공유하는 peer에게 보상을 주고, 새로운 피어에게도 기회를 제공하여 전체 네트워크의 성능을 최적화한다.
[7] BitTorrent : tit-for-tat
1) 과정
Alice는 무작위로 Bob에게 청크를 전송한다.
Bob은 그 보답으로 Alice에게 청크를 전송하기 시작한다.
Bob은 Alice를 상위 4개의 peer로 인식하게 된다.
2) 더 높은 업로드 속도 : 더 나은 거래 파트너를 찾고, 파일을 더 빨리 얻자!
: 업로드 속도가 빠르면, 더 나은 거래 파트너를 찾을 수 있다. 결과적으로 파일을 더 빨리 받을 수 있게 되는 구조이다.
[8] Blockchain
1) 의미
: 암호화로 연결된 블록(데이터 기록)들의 목록을 의미한다.
2) 특징
: 탈중앙화된 P2P 네트워크를 통해 분산 저장되고, 변경 불가능한 데이터 저장소를 형성한다.
3) Blockchain의 프로세스
: 블록체인은 데이터를 기록하고, 이를 암호된 블록으로 묶어 체인으로 연결한다. 이 체인에서 각 블록은 이전 블록과 연결되어 있으며, 분산 네트워크를 통해 데이터의 무결성을 보장한다.
4) Blockchain Trilemma (블록체인 트릴레마)
: 블록체인은 보안, 탈중앙화, 확장성의 3가지 요소 중 두 가지는 최적화할 수 있지만, 세 가지를 모두를 만족시키기는 어렵다는 트릴레마를 갖고 있다.
어떻게 하면 보안 수준을 낮추지 않고, 체인상의 탈중앙 네트워크를 유지하면서, 확장성을 개선할 수 있을까?
5) Gossip Protocol (가십 프로토콜)
전염병이 확산되는 방식에 기반한 컴퓨터 peer to peer 통신 절차: 데이터를 네트워크의 peer들 사이에 빠르게 전파하는 방식이다.: 이 방식은 블록체인 확장성을 높이는 데 도움이 된다.
Q. 확장 가능한가요?
6. Video streaming and content distribution networks
[1] Video Streaming and CDNs : context (비디오 스트리밍 및 CDN: 컨텍스트)
1) stream video traffic
: 인터넷 대역폭의 주요 소비자
넷플릭스, 유튜브, 아마존 프라임 : 가정용 ISP 트래픽의 80%를 차지할 정도로 크다.
2) 도전과제
(1) 규모의 문제 : 규모 10억 명까지의 사용자에게 도달하는 방법은?
단일 메가 미디어 서버가 작동하지 않는 이유를 가져온다.
(2) 이질성
사용자마다 요구되는 기능이나 환경이 다르다.
예 : 유선과 모바일, 대역폭이 풍부한 사용자와 대역폭이 부족한 사용자
3) 해결책
: 분산형 애플리케이션 수준의 인프라를 통해 문제를 해결할 수 있다.
[2] Multimedia : video
1) video
: 일정한 속도로 표시되는 이미지 시퀀스
ex. 24 immages / sec : 1초에 24개의 이미지가 표시
2) digital image : 픽셀 배열
픽셀 배열로 구성되며, 각 픽셀은 비트로 표현된다.
3) coding
: 이미지 내 및 이미지 간에 중복성을 사용하여, 이미지 인코딩에 사용되는 비트 수를 줄이는 방식이다.
spatial (공간적 코딩): 이미지 내 중복을 제거한다.
temporal (시간적 코딩): 한 이미지에서 다음 이미지로 넘어가는 중복성을 제거한다.
4) 예시
(1) spatial coding example
: 같은 색 (모두 보라색)의 N 값을 보내느 대신, 색상 값(보라색)과 보라색의 두 값만 보낸다.
: 동일한 색상의 값을 여러 번 전송하는 대신, 색상 값과 그 색상의 반복 수만 전송한다.
(2) temporal coding example
: 전체 프레임을 i+1로 보내는 대신, 반복되는 값(N)의 프레임의 i와의 차이만 보낸다.
: 이전 프레임과 다른 부분만 전송하여 중복된 정보를 줄인다.
5) CBR / VBR
CBR (constant bit rate) : 일정한 비디오 인코딩 속도 지정
VBR (variable bit rate ) : 공간적, 시간적 코딩의 양이 변함에 따라 비디오 인코딩 레이트가 변경된다.
5) 종류
MPEG 1 (CD-ROM) 1.5 Mbps
MPEG2 (DVD) 3-6 Mbps
MPEG4 (often used in Internet, 64Kbps - 12 Mbps)
[3] Streaming stored video (저장된 비디오 스트리밍)
1) 주요 과제
서버와 클라이언트 간 대역폭(badnwith)은 네트워크 혼잡 수준 (사내, 엑세스 네트워크, 네트워크 코어, 비디오 서버)의 변화에 따라 시간이 지남에 따라 달라진다.
네트워크 혼잡으로 인해 패킷 손실 및 지연이 발생해 비디오 재생에 문제가 생길 수 있다. (비디오 품질 저하 등)
2) case 1
스트리밍 : 이 때 클라이언트는 비디오의 초반 부분을 재생하고, 서버는 비디오의 후반 부분을 계속 전송한다.
비디오 녹화 (검은색 선): 비디오가 초당 30 프레임의 속도로 녹화된다.: 그래프에서 누적 데이터량이 계단식으로 증가하는 것을 볼 수 있다.
비디오 전송 (빨간색 선): 서버에서 클라이언트로 비디오를 전송한다.: 네트워크 지연 시간이 존재하므로, 전송 시작점이 녹화 시작점보다 뒤에 있다.
비디오 재생 (파란색 선): 서버로부터 받은 비디오를 클라이언트에서 재생한다.: 초당 30프레임으로 재생되며, 네트워크 지연 후에 시작된다.
스트리밍의 핵심
그래프의 점선 이후 부분을 보면, 클라이언트가 비디오의 초반을 재생하는 동안 "서버는 계속해서 후반부를 전송하고 있다."
이것이 바로 스트리밍의 원리
전체 비디오를 다운로드할 때까지 기다리지 않고, 받은 부분부터 바로 재생할 수 있다.
효과
이를 통해 사용자는 대용량 비디오 파일을 빠르게 시청할 수 있고, 저장 공간도 절약할 수 있다.
3) continuous playout contraint (연속 재생 제약)
: 클아이언트 재생이 시작되면, 재생은 원본 타이밍과 일치해야 한다.
하지만, 네트워크 지연은 가변적이므로 (jitter) 재색 요건을 맞추기 위해, _클라이언츠 측 버퍼_가 필요하다.
4) 다른 과제
클라이언트 상호 작용 : 비디오 일시 정지, 빨리 감기, 되감기, 건너 뛰기
비디오 패킷이 손실되거나 재전송될 수 있음
5) case 2 (재생 버퍼링)
: 서버에서 일정한 속도로 비디오 데이터를 클라이언트에 전송하고, 클라이언트는 버퍼링을 통해 안정적으로 재생한다.
비디오 전송 (빨간색 선 - "constant bit rate video transmission")
: 서버에서 클라이언트로 일정한 속도로 비디오 데이터를 전송하는 과정을 나타낸다.
: 비디오가 고정된 비트레이트로 전송되며, 네트워크 딜레이에 따라 전송이 시작된다.
: 계단식으로 올라가는 모양은 데이터가 일정한 시간마다 꾸준히 전송된다는 것을 보여줍니다.클라이언트 비디오 수신 (검은색 선 - "client video reception")
: 클라이언트가 서버로부터 비디오 데이터를 받는 과정이다.
: 네트워크의 변동 딜레이 때문에 비디오를 일정하게 수신하지 못할 수 있지만, 전반적으로 빨간색 선을 따라 비디오 데이터를 받는다.
: 빨간색 선에서 시작되는 지점보다 약간 뒤에 위치하고, 네트워크에 따라 지연이 발생할 수 있다.클라이언트 비디오 재생 (파란색 선 - "constant bit rate video playout at client")
: 클라이언트는 수신한 비디오 데이터를 재생한다.
: 버퍼링을 통해 지연 시간 및 지터(jitter)를 보정한 후 일정한 속도로 비디오를 재생하는 과정을 나타낸다.
: 파란색 선은 클라이언트가 비디오를 재생하는 모습을 보여주며, 일정한 비트 레이트로 안정적으로 재생하는 것을 볼 수 있다.지연 보정 및 버퍼링 (client playout delay)
: 클라이언트가 비디오를 재생하기 전에 일정량의 데이터를 버퍼에 쌓아두는 버퍼링 과정이 포함된다 -> 이를 통해 네트워크 지연이나 지터에 의한 재생 중단을 방지한다.
: 클라이언트에서의 지연 보정은 네트워크 상태에 따라 다르며, 이 버퍼링은 일정한 비디오 재생을 가능하게 한다.
(1) 장점
네트워크 불안정성에 대한 대비
끊김 없는 부드러운 재생 경험 제공
가변적인 네트워크 상황에 적응 가능
(2) 단점
초기 재생 시작까지 약간의 대기 시간 발생
실시간성이 조금 떨어질 수 있음
[4] Streaming multimedia : DASH
1) DASH
: Dynamic, Adaptive Streaming over HTTP (동작 적응 스트리밍 방식)
: 네트워크 상황에 맞춰 비디오 화질을 동적으로 변경할 수 있다.
2) server
비디오 파일을 여러 청크로 나눈다.
각 청크는 서로 다른 속도로 인코딩되어 저장된다.
manifest file : 여러 청크에 대한 URL 제공
3) client
주기적으로 서버와 클라이언트 간 대역폭 측정하여 적절한 청크를 요청
manifest 컨설팅하여, 한 번에 하나의 청크 요청
현대 대역폭에서 지속 가능선 최대 코딩 속도를 선택 (ex. 화질 선택)
시점에 따라 다른 코딩 속도를 선택할 수 있다. (시점의 사용 가능한 대역폭에 따라 다름)
4) 클라이언트의 인텔리전스 : 클라이언트가 결정한다.
청크를 요청할 때 (버퍼 고갈 또는 오버플로우가 발생하지 않도록 한다.): 클라이언트는 동영상의 청크(부분)를 언제 요청할지 결정할 수 있다. 적절한 타이밍을 잡아 안정적인 스트리밍을 제공한다.
요청할 인코딩 속도 결정 (사용 가능한 대역폭이 많을 때 클라이언트 품질 향상): 클라이언트는 네트워크 상태에 따라 요청할 비디오의 인코딩 속도를 선택할 수 있다.
청크를 요청할 위치 (클라이언트와 근접하거나 가용 대역폭이 높은 URL 서버에서 요청 가능): 이렇게 하면, 다운로드 속도를 최적화하고 네트워크 혼잡을 피할 수 있다.
5) Streaming video = encoding + DASH + playout buffering
[5] Content Dostribution Networks (CDNs)
: 많은 사용자에게 효율적으로 콘텐츠를 전달하기 위한 시스템이다.
: 전 세계 여러 서버에 동일한 콘텐츠의 사본을 저장하여, 사용자에게 가까운 서버에서 콘텐츠를 전송하는 방식으로 작동한다.
1) 과제
: 수백만 개의 동영상에서 선택한 콘텐츠를 수십만 명의 동시 사용자에게 스트리밍하는 방법은 무엇인가?
2) option1 : 단일 대규모 메가 서버
: 하나의 큰 중앙 서버를 사용해 콘텐츠를 스트리밍하는 방식이다. (확장성 문제가 크다)
(1) 문제점
단일 장애 지점: 서버가 다운되면 모든 사용자가 콘텐츠에 접근할 수 없게 된다.
네트워크 혼잡 지점: 서버에 너무 많은 요청이 몰리며 지연이 발생한다.
멀리 떨어진 클라이언트에 대한 긴 경로: 서버에서 멀리 떨어진 사용자는 데이터가 전송되는 데 시간이 더 걸리기 때문에 느리게 로드된다.
발신 링크를 통해 전송되는 여러 개의 비디오 사본: 많은 사용자가 같은 비디오를 요청할 경우, 서버가 동일한 비디오의 복사본을 여러 번 보내야하므로 비효율적이다.
-> 간단히 말해서, 이 솔루션은 확장이 불가능하다.
3) option2 : 지리적으로 분산된 여러 사이트에 여러 개의 동영상 사본을 저장/제공 (CDN)
: CDN을 이용해 여러 사이트에 콘텐츠를 분산 배치하는 방식이다.
deep, 깊이 들어가기 : CDN 서버를 다수의 접속 네트워크 깊숙이 밀어 넣는다.: CDN 서버를 많은 액세스 네트워크 안에 배치하여, 사용자의 가까운 곳에 서버를 위치시킨다.
사용자와 가까운 위치
Ex) Akamai : 120개 이상의 국가에 240,000 대의 서버를 매치 (2015년)
home, 집으로 가져오기 : 엑세스 네트워크 근처 (내부가 아닌)의 POP에 소규모(10대)의 대규모 클러스터 배치: 액세스 네트워크 내는 아니지만, 가까운 곳에 위치한 큰 규모의 서버 클러스터를 배치한다.
Ex) Limelight
4) CDN의 역할
: CND 노드에 콘텐츠 사본을 저장하고, 사용자에게 가장 가까운 노드에서 콘텐츠를 제공한다.
: 네트워크 경로가 혼잡할 경우다른 노드에서 콘텐츠를 가져와 사용자 경험을 최적화할 수 있다.
(1) 예시
: 넷플릭스는 MadMen의 사본을 저장한다.
(2) 가입자가 CND에서 콘텐츠를 요청할 경우
: 가까운 사본으로 이동하여, 콘텐츠를 검색한다.
네트워크 경로가 혼잡한 경우 다른 사본을 선택할 수 있다.: 그 이유는 CDN는 분산된 개념을 통해 청크를 가져오기 때문이다.
(3) 정리
5) OTT의 과제
: Over the top
: 서비스로서의 인터넷 host-host 통신
: CDN을 어떻게 배치하고, 어떤 노드에서 콘텐츠를 가져올 지 결정하는 것이 매우 중요하다.
혼잡합 인터넷에 대처하기
어느 CDN 노드에서 콘텐츠를 검색할까?
혼잡 시 시청자 행동은?
어떤 콘텐츠를 어떤 CDN 노드에 배치할 것인가?
[6] CDN content access : a closer look
1) Bob (client) request video http:/netcinema.com/6Y7B23V
: video stored in CDN at http://KingCDN.com/NetC6y&B23V
Bob이 netcinema.com 웹 페이지에서 비디오 URL(http://netcinema.com/6Y7B23V)을 가져온다.
Bob의 로컬 DNS를 통해 http:/netcinema.com/6Y7B23V를 확인한다.
netcinema의 DNS가 콘텐츠가 저장된 http://KingCDN.com/NetC6y&B23V의 URL(CNAME)을 반환한다.
Bob의 local DNS server과 KingCDN authoritative DNS와 통신한다.
KINGCDN 서버에서 HTTP를 통해 스트리밍된 비디오를 요청한다.
: 이 방식은 네트워크의 상태에 따라 가장 가까운 CDN 서버에서 콘텐츠를 가져오므로 빠르고 효율적인 스트리밍을 제공할 수 있다.
