[네트워크] 비디오 스트리밍 원리와 DASH, P2P, CDN 소개

Peer-to-Peer (P2P) 네트워크

P2P 네트워크에서는 중앙 서버 없이 각 피어가 직접 서로 통신한다. 피어는 다른 피어에게 서비스를 제공하고, 그 대가로 서비스를 받는다("give and take"). 피어 간 서비스는 주로 파일 공유나 스트리밍 형태로 이루어지며, 대표적 서비스는 BitTorrent, KanKan 등이 있다.

P2P의 특징과 장점

확장성(Scalability)
- 새로운 피어의 참여로 인해 서비스 용량과 수요가 동시에 증가한다.
- 피어는 간헐적으로(intermittently) 네트워크에 접속하며, 위치 및 IP가 변할 수 있다.

P2P 아키텍처

항상 켜져 있는 서버가 없음 (no always-on server)
임의의 종단 시스템(end system)끼리 직접 통신함
각 peer는 다른 peer에게 서비스를 요청하고, 동시에 서비스를 제공함
self scalability (자체 확장성): 새로운 peer가 참여하면 새로운 서비스 용량과 수요가 함께 생김
peer는 간헐적으로 연결되고, IP 주소가 자주 바뀜 → 관리가 복잡함
예시:
P2P 파일 공유: BitTorrent
스트리밍: KanKan
VoIP: Skype

파일 분배: Client-Server vs P2P

문제: 하나의 서버가 파일(크기 F)을 N개의 peer에게 분배하는 데 얼마나 시간이 걸릴까?

서버 업로드 용량: us
각 클라이언트의 다운로드 용량: di
각 클라이언트의 업로드 용량: ui (P2P의 경우)

Client-Server 방식의 파일 분배 시간

서버는 N개의 클라이언트에게 각각 파일을 전송해야 함:
한 개 전송 시간: F/us
N개 전송 시간: NF/us
클라이언트 다운로드 속도 고려:
최소 다운로드 속도: dmin
최소 다운로드 시간: F/dmin

→ 최종 분배 시간:

N이 커질수록 선형 증가

P2P 방식의 파일 분배 시간

각 서버가 클라이언트 또는 서버 역할을 하기도 한다. self-scaleable하다

서버는 최소 한 번만 업로드하면 됨: F/us
클라이언트는 다운로드해야 함: F/dmin
전체 시스템은 총 NF 비트를 업로드해야 함:
사용 가능한 총 업로드 대역폭: us + Σui

→ 최종 분배 시간:

N이 커지면 파일 수요는 증가하지만, 동시에 제공 능력도 증가함 → 확장성 우수

BitTorrent 기반 P2P 파일 분배

BitTorrent의 주요 요소

트래커(tracker): 네트워크 참여 피어 목록 및 보유한 파일(chunk) 정보를 관리한다.
피어(peer): 파일을 다운로드 받거나 업로드하는 사용자로, 상황에 따라 클라이언트와 서버 역할을 번갈아 수행한다.
Chunk(청크): 파일을 구성하는 작은 데이터 조각(256kb).

절차:

Alice가 torrent에 참여
tracker로부터 peer 목록을 얻음
다른 peer들과 청크 교환 시작

BitTorrent 작동 방식

peer가 torrent에 참여하면:
처음에는 청크가 없음
tracker에 등록하여 "이웃(peer)" 목록 획득
다운로드 중에도 다른 peer에게 청크 업로드 가능
peer는 이웃을 교체할 수 있음
churn 현상: peer는 언제든 나갔다 다시 들어올 수 있음
전체 파일을 받은 peer는:
altruistic(이타적)하게 남을 수도 있고,
selfish(이기적)하게 떠날 수도 있음

청크 요청: Rarest First 전략

피어는 자신이 갖지 않은 청크 중 "가장 희귀한(rarest)" 청크를 우선적으로 요청한다. 희귀한 청크를 먼저 확보해야 피어가 이탈해도 전체 파일 확보가 용이하기 때문이다.

모든 peer는 서로 다른 청크 집합을 가지고 있음
Alice는 주기적으로 이웃에게 어떤 청크가 있는지 묻고
자신에게 없는 청크 중에서 가장 희귀한 것을 먼저 요청함 (rarest-first)

청크 전송: tit-for-tat 전략 (give and take)

피어는 청크를 업로드하는 속도가 빠른 다른 피어에게 우선적으로 데이터를 제공하며("tit-for-tat"), 나머지 피어는 차단(choke)한다.

Alice는 현재 자신에게 가장 빠르게 청크를 보내고 있는 4명에게만 청크를 보냄
나머지는 choked 상태 (청크 못 받음)
10초마다 top 4 재평가
30초마다 랜덤 peer 하나를 추가적으로 연결(optimistically unchoke) 함
새로운 peer가 top 4 안에 들 수 있는 기회를 부여

Tit-for-Tat 작동 예시

Alice가 Bob을 optimistically unchoke
Bob이 Alice에게 빠르게 보내기 시작 → reciprocate
Bob이 Alice의 top-4에 진입

→ 더 나은 업로드 파트너 확보 = 더 빠른 다운로드 속도 확보

Video Streaming과 CDN (OTT)

Netflix, YouTube 등 OTT(Over-The-Top) 서비스는 막대한 트래픽을 생성하며, 통신 사업자(KT, SKT 등)의 인프라를 사용하지만 별도의 비용을 지불하지 않는 문제가 있다. 이를 효율적으로 관리하기 위해 CDN과 같은 분산된 애플리케이션 레벨의 인프라가 활용된다.

스트리밍 비디오 트래픽의 context

Netflix, YouTube, Amazon Prime 등의 비디오 트래픽은 전체 인터넷 트래픽의 약 80% 차지 (2020년 기준)
주요 과제:
확장성 (scale): 수억 명의 사용자에게 콘텐츠 제공
이질성 (heterogeneity): 사용자마다 네트워크 환경, 디바이스 다름
해결책: 분산형 애플리케이션 인프라
OTT : Over The Top -> Apllication layer
- 기존에는 TV나 케이블 같은 통신 인프라 사업자들이 방송 콘텐츠를 제공했는데, OTT는 이런 전통적인 유통망을 ’넘어(over the top)’서 인터넷만 있으면 누구나 직접 콘텐츠를 볼 수 있는 서비스

비디오의 구조와 압축 방식

비디오는 일정한 속도로 프레임을 재생 (24~30fps)
각 프레임은 픽셀의 배열 (디지털 이미지)
압축(Coding):
- 공간 압축 (spatial coding): 같은 색상 반복 → 색상 + 반복 횟수로 표현
- 시간 압축 (temporal coding): 변화가 없는 부분은 생략하고 차이만 저장

CBR vs VBR

CBR (Constant Bit Rate): 고정된 인코딩 속도
VBR (Variable Bit Rate): 콘텐츠 복잡도에 따라 인코딩 속도 가변
예시:
MPEG1 (CD-ROM): 1.5 Mbps
MPEG2 (DVD): 3~6 Mbps
MPEG4 (인터넷): 64 Kbps ~ 12 Mbps

저장된 비디오 스트리밍

개요 (Scenario)

비디오 서버에 저장된 동영상을 클라이언트가 인터넷을 통해 스트리밍하는 방식
서버가 비디오 데이터를 인터넷을 통해 클라이언트에게 전송하고, 클라이언트가 이를 실시간으로 재생함

주요 도전 과제 (Main Challenges)

서버와 클라이언트 간의 대역폭(Bandwidth)이 시간에 따라 변동함
- 가정 내 네트워크, 액세스 네트워크, 코어 네트워크, 서버 자체의 혼잡도에 따라 달라짐
패킷 손실(Packet Loss) 및 혼잡(Congestion)에 의한 지연으로 인해 재생이 늦어지거나 비디오 품질이 저하될 수 있음

스트리밍 동영상의 동작 방식

Video recorded (서버)
- 비디오는 초당 일정 프레임(예: 30 frames/sec)으로 녹화되어 서버에 저장됨
Video sent (서버 → 클라이언트)
- 서버는 저장된 비디오를 클라이언트로 전송함
- 네트워크를 통해 데이터가 패킷 단위로 전송됨
- 이 과정에서 네트워크 지연(Network delay)이 발생함
Video received & played (클라이언트)
- 클라이언트는 비디오 데이터를 수신하고 재생을 시작함 (초당 30 frames)
- 클라이언트가 초반부 데이터를 재생하고 있는 동안에도 서버는 후반부 데이터를 계속 전송함 (Streaming)
- 즉, 스트리밍이란 클라이언트가 앞부분을 재생하는 동시에 서버가 뒷부분 데이터를 전송하는 방식임

스트리밍 비디오의 주요 문제점과 대응 방법

지속적인 재생의 어려움 (Continuous Playout Constraint)

클라이언트는 비디오를 지속적으로 끊김 없이 재생해야 함
- 재생 타이밍(Playout Timing)은 녹화된 원본 타이밍과 정확히 일치해야 자연스러운 재생 가능
하지만 네트워크 지연(Network Delay)은 일정하지 않고 가변적(Jitter) 임
- 즉, 네트워크 상태에 따라 데이터가 빨리 도착하기도 하고 느리게 도착하기도 함
- 이를 해결하기 위해 클라이언트는 버퍼(Buffer)를 사용해 데이터가 지연되더라도 지속적으로 비디오를 재생할 수 있도록 대비함

추가적인 문제점 (Other Challenges)

클라이언트의 상호작용성(Interactivity) 제공이 필요함
- 예: 비디오 일시정지(Pause), 빨리감기(Fast-forward), 되감기(Rewind), 특정 부분으로 이동(Jump) 등
비디오 패킷이 손실(Packet Loss)될 경우 재전송(Retransmission) 이 필요함

클라이언트 측 재생 버퍼링 (Playout Buffering)

클라이언트가 비디오 데이터를 수신하면 바로 재생하지 않고, 일정량의 데이터를 미리 저장한 뒤 재생을 시작하는 방식 (Buffering)
버퍼링을 통해 네트워크 지연과 지터(Jitter, Delay jitter)를 보상(compensate) 할 수 있음

버퍼링의 동작 과정 예시

서버는 비디오를 일정 비트율(constant bit rate) 로 지속해서 전송함 (예: 매초 일정량의 데이터 청크 전송)
네트워크 지연(Network Delay)이 가변적(variable)으로 발생하면서 클라이언트에게 도착하는 데이터 속도가 일정하지 않음
클라이언트는 일정 시간 데이터를 버퍼에 미리 저장한 후 재생 시작
클라이언트에서 버퍼 내 데이터를 일정한 속도로 재생하며, 지속적으로 데이터를 미리 받아 버퍼를 유지함
- 이를 통해 데이터 도착 속도가 느려지더라도 중단 없이 끊김 없는 재생 가능

예시 설명

시점 t0에서 클라이언트는 총 6개의 청크(chunks)를 수신했고, 이 중 2개의 청크는 이미 재생이 완료됨
따라서 현재 버퍼에는 4개의 청크가 저장된 상태이며, 이는 이후 발생할 네트워크 지연을 견딜 수 있는 여유 공간으로 활용됨

DASH (Dynamic Adaptive Streaming over HTTP)

DASH는 HTTP를 기반으로 클라이언트 환경에 따라 비디오 전송 품질을 동적으로 조정하는 기술이다.

각 청크의 위치(URL)는 "manifest" 파일에 저장되며, 클라이언트는 이 파일을 참조하여 가장 적합한 서버(예: 가까운 데이터센터)에서 데이터를 다운로드 받는다.

서버:

비디오 파일을 여러 청크로 분할
각 청크는 다양한 품질(인코딩 비율)로 저장
여러 CDN 서버에 복제
manifest 파일: 모든 청크의 URL 정보 포함

클라이언트:

주기적으로 대역폭 측정
manifest 파일을 바탕으로 한 청크씩 요청
현재 대역폭에 맞는 최고 품질 선택
네트워크 상황에 따라 서버/인코딩 비율 변경 가능

DASH의 클라이언트 측 “지능”

언제(when) 청크를 요청할지 결정 (버퍼 고갈/과잉 방지)
어떤(what encoding rate) 품질로 요청할지 결정 (대역폭 기반)
어느 서버(where)에서 가져올지 결정 (가까운 CDN 선택)

→ 스트리밍 = 인코딩 + DASH + 클라이언트 버퍼링

주요 필드 설명:

Source/Destination Port: 송수신 애플리케이션 식별
Sequence Number: 전송되는 첫 바이트의 번호
Acknowledgment Number: 다음으로 기대하는 바이트 번호
Data Offset: 헤더 길이
Control Flags: SYN, ACK, FIN 등 제어 비트
Window Size: 수신자가 허용 가능한 버퍼 크기
Checksum: 오류 검출
Urgent Pointer: 긴급 데이터 위치
Options: 타이머, 윈도우 조정 등 옵션

CDN(Content Distribution Network)과 예시

CDN이 필요한 이유

문제: 수백만 개의 비디오 콘텐츠를 수십만 명의 사용자에게 실시간 제공하려면?

Option 1: 단일 메가 서버

단일 장애 지점 (single point of failure)
네트워크 혼잡 지점 (congestion)
사용자와의 물리적 거리 문제

→ 확장성 부족

Option 2: CDN (분산 콘텐츠 전송 네트워크)

여러 지역에 여러 복사본 저장
두 가지 방식:
Enter Deep: ISP 근처의 작은 서버들에 콘텐츠 분산 (Akamai 방식)
- CDN 서버를 ISP 내부 네트워크까지 깊숙이 배치
Bring Home: 주요 지점에 큰 데이터센터 (Limelight 방식)
- CDN 서버를 ISP 외부나 자체 데이터센터에 중앙 집중 배치

Netflix의 OpenConnect 예시

Netflix는 Amazon 클라우드에서 콘텐츠를 CDN 노드로 업로드
사용자가 콘텐츠를 요청하면 manifest 파일 제공
클라이언트는 상황에 맞는 품질, 서버를 선택해 콘텐츠 스트리밍

CDN 콘텐츠 접근 흐름 정리

전제 상황

사용자가 접속하려는 콘텐츠: http://netcinema.com/6Y7B23V
실제 콘텐츠는 CDN에 저장되어 있고 주소는 http://KingCDN.com/NetC6y&B23V

단계별 처리 과정

1단계. 웹 페이지에서 URL 획득

사용자(Bob)는 netcinema.com 웹사이트에서 영화 ID가 포함된 URL (netcinema.com/6Y7B23V)을 클릭한다.

→ 이 URL은 실제 콘텐츠가 저장된 kingcdn.com으로 리디렉션될 예정.

2단계. 로컬 DNS (LDNS)로 도메인 이름 해석 요청

Bob의 컴퓨터는 이 URL을 해석하기 위해 로컬 DNS 서버 (LDNS)에 netcinema.com에 대한 DNS lookup을 요청한다.

→ LDNS는 캐시에 없으면 권한 있는 DNS 서버로 요청을 릴레이한다 (iterative 방식 사용).

3단계. Netcinema의 권한 DNS로 요청 전달

LDNS는 netcinema.com의 authoritative DNS 서버로 질의하고,

이 DNS는 해당 리소스에 대한 CNAME 레코드를 반환한다.

→ 반환된 CNAME 예: kingcdn.netcinema.com

즉, netcinema는 자신이 직접 콘텐츠를 제공하지 않고, CDN의 하위 도메인으로 위임(CNAME) 하여 콘텐츠 요청을 전달한다.

4단계. CNAME에 대해 추가적인 DNS 해석 수행

LDNS는 kingcdn.netcinema.com에 대한 IP 주소를 얻기 위해 KingCDN의 권한 DNS 서버에 iterative 질의를 수행한다.

5단계. 최종 IP 주소 반환 → 클라이언트로 전달

KingCDN의 authoritative DNS는 적절한 CDN 서버(예: 지리적으로 가까운 서버)의 IP 주소를 반환하고,

LDNS는 이 IP 주소를 Bob의 컴퓨터로 전달한다.

6단계. 콘텐츠 요청 및 HTTP 스트리밍

Bob의 클라이언트는 반환된 KingCDN 서버의 IP로 HTTP 요청을 전송하여 비디오 콘텐츠를 요청한다.

→ 콘텐츠는 HTTP를 통해 스트리밍 방식으로 전송된다.

7단계. 네트워크 상황에 따라 품질을 동적으로 조정 (DASH 사용)

스트리밍 방식은 DASH (Dynamic Adaptive Streaming over HTTP)를 사용하여,

네트워크 상태에 따라 비디오 품질(해상도 등)을 동적으로 조정한다.

→ 이를 통해 끊김 없이 사용자에게 최적의 품질로 콘텐츠를 제공할 수 있다.

핵심 포인트 정리

DNS CNAME 리디렉션을 통해 오리지널 서버(netcinema.com)에서 CDN 서버(KingCDN.com)로 유연하게 콘텐츠 위치를 변경할 수 있다.
사용자는 CDN을 직접 인지하지 못한 채 빠르게 콘텐츠를 전송받을 수 있다.
DNS 기반 접근 방식은 전통적인 웹 캐싱보다 더 효율적으로 사용자와 가까운 서버로 연결시켜준다.

Netflix – (CDN + DASH 기반)

Netflix는 자체 CDN 인프라를 보유하고 있으며, 외부 CDN 제공자(KingCDN 등)와 계약하지 않고 직접 관리합니다.
콘텐츠는 Amazon Cloud에 먼저 업로드됩니다.
이후 여러 해상도/품질로 인코딩된 영상 파일들을 Netflix 자체 CDN 서버로 미리 복사(push) 합니다.

Push 방식

사용자의 요청 없이도 콘텐츠를 미리 CDN에 저장해두는 방식입니다.
Netflix는 네트워크 부하가 적을 때 Amazon Cloud에서 자체 CDN 서버로 복사본을 전송하여 캐싱을 완료합니다.
이는 지연을 줄이고 스트리밍 속도를 높이기 위한 사전 준비 작업입니다.

1단계. 사용자가 넷플릭스 계정에 로그인

사용자인 Bob은 자신의 Netflix 계정 정보(등록, 결제 등) 를 관리합니다.
이 요청은 Netflix registration/accounting 서버로 전달됩니다.

2단계. 사용자가 넷플릭스 콘텐츠 탐색

Bob은 웹 또는 앱에서 Netflix 콘텐츠를 탐색합니다.
이때 사용자는 특정 영상을 클릭하거나 탐색하며, 메타데이터 및 미리보기 등의 정보가 로딩됩니다.
이 요청은 Amazon Cloud 상의 Netflix 콘텐츠 서버로 전달됩니다.

3단계. Manifest 파일 요청 및 수신

Bob이 특정 영상을 선택하면, 클라이언트는 해당 영상의 Manifest 파일을 요청합니다.
Manifest 파일에는 이 영상의 여러 해상도/비트레이트 버전 정보가 들어있으며, 각 버전이 어느 CDN 서버에 저장돼 있는지도 포함됩니다.
이 파일은 다시 클라이언트에게 전달됩니다.

4단계. DASH 서버 선택 및 스트리밍 시작

Bob의 클라이언트는 Manifest 정보를 분석하여 가장 적합한 CDN 서버(DASH 서버) 를 선택합니다.
- 선택 기준: 거리, 지연(latency), 네트워크 상황
이후, 선택된 CDN 서버와 HTTP 연결을 맺고 스트리밍을 시작합니다.
스트리밍은 DASH 방식으로 동작하며, 네트워크 상태에 따라 동적으로 화질이 조절됩니다.

용어 설명

용어	설명
Push CDN	사용자 요청 없이 콘텐츠를 CDN에 미리 저장해두는 방식
Pull CDN	사용자 요청 시 콘텐츠를 CDN에 불러오는 방식
Manifest File	특정 콘텐츠에 대한 세그먼트 파일 위치 및 버전을 정의한 메타데이터 파일
DASH	네트워크 상태에 따라 품질을 조절하는 HTTP 기반 스트리밍 프로토콜
자체 CDN	Netflix가 직접 운영하는 콘텐츠 배포망 (외부 CDN 미사용)

'CS 지식 > 네트워크' 카테고리의 다른 글

[네트워크] UDP 특징과 구조 체크섬, 인터넷 체크섬 (0)	2025.04.25
[네크워크] 멀티플렉싱과 디멀티플렉싱 - TCP, UDP, 연결지향 (0)	2025.04.24
[네트워크] DNS(Domain Name System)와 메세지 포맷, 보안 (1)	2025.04.04
[네트워크] 이메일 시스템과 프로토콜(SMTP, IMAP, POP, HTTP) (1)	2025.04.04
[네트워크] 웹 캐시와 HTTP framing (1)	2025.04.04