Video Streaming and CDNs (Content Distribution Networks)

!! 정리 

이 둘이 모두 발생

DASH : 클라이언트의 현재 상황에 맞추어 streaming하는 방법

CDN : 지역 별로 비디오를  빠르게 찾을 수 있도록 하기

 

---

 

video가 인터넷 대역폭에서 가장 많이 차지

youtube는 1B, netflix는 75M

1B의 유저를 지원을 어떻게 해…

• scale 문제
• 제각각인 유저들
  • wired이냐 모바일이냐
  • 대역폭이 넉넉치 못한 사람들이 비디오 스트리밍을 원한다면
  • 대역폭이 왔다갔다 하는 사람들은

 

Video

비디오는 단위 시간당 일정 개수의 이미지를 보내는 것

이 디지털 이미지는 픽셀들의 배열. 픽셀을 비트로 표현

즉, 단위 시간 당 일정 개수의 비트가 전달되어야 함

 

이미지 간 또는 내부의 중복을 사용하여 bit 수 줄이기

spatial coding 

• within image
• 같은 정보의 픽셀들이 연속적으로 몇 개 있는지 압축하여 보냄

temporal coding

• from one image to next
• 바로 다음 이미지가 이전 이미지와 비슷하다면 이전 이미지만 보냄

 

encoding 속도 

CBR (constant bit rate)

• 모든 이미지의 video encoding 속도가 일관됨
• 위의 두 방식을 적용X. 그래도 보내기 대문

VBR (variable bit rate)

• spatial coding , temporal coding 방식을 적용하여 video encoding 속도가 변함

 

spatial, temporal redundancy를 제거함으로써

encode된 bit 양을 줄이면 결과적으로

variable bit encoding rate를 생성하게 된다.

 

 

Streaming multimedia : DASH

멀티미디어 스트리밍이 필요한 application service들이 많아짐에 따라

client 환경 및 요구의 다양성에 대응하기 위해 사용되는 프로토콜

 

Dynamic, Adaptive, Streaming over HTTP

server 측:

• 비디오 파일을 서로 다른 bit rate의 버전으로 encoding함
• .manifest file : 서로다른 버전에 대한 URL을 제공해야 함

client 측:

• 가용 대역폭을 확인하기 위해 서버-클라이언트의 대역폭을 주기적으로 측정
• 서버가 제공하는 manifest를 참조하여 한 번에 청크 하나씩 요청
  • 지원 가능한 최대 속도로 encoding한 것부터
  • client의 가용 대역폭이 시간에 따라 달라짐을 대비해 다른 coding rate를 준비
    • 이 때 낮은 대역폭에 이뤄졌을 경우 비디오 품질이 낮아짐
    • 갑자기 변해버린 드라마 영상 화질 480pㅠㅠ

 

client에 모든 결정권을 부여

• 언제 청크를 요청할 것인가?  -  buffer starvation or overflow 방지
• encoding rate는 무엇으로?  -  더 나은 대역폭이 가능할 때만 높임
• 어디서 청크를 요청할 것인가?  -  비디오를 가진 여러 서버들 중 자신과 가깝거나 가용 대역폭이 높은 쪽을 선택

 

DASH server의 역할

• prepare video files encoded into several versions of different bit rates
• prepare manifest file

 

---

CDN: Content Distribution Networks

문제: 수백 수천만의 동시접속자에게 스트리밍을 지원하는 법

하나의 큰 mega-server로는 불가능

• single point 의 실패
• 네트워크가 한 곳에서 혼잡해짐
• 멀리 있는 client는 긴 경로를 가짐
• 계속된 실패로 동일한 복사본을 여러번 보내야 할 수도

지역적으로 흩어져있는 서버에 비디오를 저장해두는 것이 바로 CDN

• enter deep
  • CDN 서버를 access network 속으로 push하여 심어둠
    • ex) Akamai는 1700개의 위치에 분포
    • 사용자와 가깝게 하는 것이 목표 (end user와 CDN 서버 간의 지연을 줄이고 처리량throughput을 늘림)
    • 서버가 많이 필요하고 관리하기 힘들 수 있음
    •  Global Access ISP에 server cluster를 배치
• bring home 
  • 서버 cluster는 access network 내부가 아닌 그 근처의 POPs에 설치 (IXP에 구축)
  • 일반적으로 초기 설계 방식에 비해 유지관리 비용 절감
  • 서버 cluster 하나의 규모를 크게하여 서버를 설치한 장소의 수는 감소
    • 1700개 ->10개

 

더 많은 수의 CDN server를 필요로 하는 구조

: enter deep

 

 

CDN 동작 방식

바로 CDN을 찾아가는 것이 아니라 회사의 authoritative DNS server에 해당 CDN의 IP주소를 물어야 함

 

 

CDN을 Over the top이라고 부르는 이유

over the top network

• 물리적인 네트워크 상에 host-host 통신 지원

OTT Challenges

• CDN 노드마다 어떤 컨텐츠를 보유할지
• 요청이 발생하면 어떤 CDN으로부터 회수할지
• congestion이 발생할 때는 사용자가 어떻게 행동하는지

 

 

CDN content access 자세히 보기

 

content provider 자신이 제공하는 프로그램을 CDN에 맡김. 

content user로부터 온 요청을 content provider가 받아서 CDN으로 redirect해줌

 

아래 그림에서

netcinema.com은 provider,

KingCDN이 CDN.

netcinema의 프로그램은 KingCDN에 저장되어 있기에

여기에 DNS를 이용하여 redirect를 함

 

1. 밥이 자신이 원하는 비디오를 url에 담아 netcinema에 요청  (비디오 띄우는 웹 페이지 html 가져옴)
2. 밥이 밥의 local DNS에 같은 url를 보냄 
3. 밥의 local DNS가 netcinema의 authoritative DNS에 그 url을 보내 CDN url을 얻어냄
4. 새로얻은 CDN url을 그 CDN(king) authoriataive DNS로 요청하여 해당 비디오의 IP주소를 받아옴
5. 밥의 local DNS로부터 받은 IP주소로, HTTP를 통해 kingCDN 서버로 비디오 스트리밍을 요청

 

user의 local name server가 KingCDN의 존재를 알 수 없으므로

 user의 local name server는

 user가 선택한 content의 URL을 resolve하기 위해 

netcinema의 authoritative name server에게 query를 보내게 되고, 

이를 받은 netcinema의 authoritative name server가 

user의 local name server에게

 KingCDN authoritative에게 물어보라고 알려줌으로서

실제 content를 저장하고 있는 서버의 주소를 발견할 수 있게 된다.

 

 

How about Netflix?

netflix는 DNS을 사용하지 않고

모든 over the top 관련 문제를 아마존 클라우드에 위임

amazon cloud에서 user의 request를 받도록 하고

amazon cloud가 직접 manifest file을 user애개 보내도록 한다.

 

새로운 비디오를 추가하고 싶다면 그 비디오를 아마존 클라우드로 보냄

그럼 아마존 클라우드가 여러 버전의 비디오를 각 CDN 서버에 저장

 

그래서 사용자는 아마존 클라우드로 요청하여 그에 대한 manifest file을 받음

manifest fil에서 적절한 URL을 골라서 

DASH를 사용하여 멀티미디어 스트리밍을 받는다.