[네트워크이론] 2.6 비디오 스트리밍과 컨텐츠 분배 네트워크

(Computer Networking a top-down Approach 책의 내용입니다)

비디오 매체의 특징

• 이미지의 연속
• 압축되지 않은 디지털 인코딩된 이미지는 픽셀의 배열로 구성. 각 픽셀은 luminance와 색상을 나타내는 비트들로 인코딩됨.
• 압축될 수 있다는 특징
  • 비디오 퀄리티를 bit rate에 맞출 수 있음
• 높은 bit rate
  • typically 100 kbps for low-quality video to over 4 Mbps for streaming high-definition movies
  • end-to-end throughput이 비디오 스트리밍 성능 측정에 충요한 요소
    • 끊김없는 영상을 제공하려면 최소한 압축된 영상의 bit rate 이상의 평균 throughput을 제공해야 함
• 여러 버전의 품질로 제공 가능
  • ex) 300 kbps, 1 Mbps, 3 Mbps
    • 유저가 선택

HTTP Streaming and DASH

기본적인 HTTP 영상 스트리밍

• 영상은 HTTP 서버에 일반적인 파일로 저장되어 있음
• 유저가 TCP 커넥션을 통해 서버에 HTTP GET 요청을 보냄
• 서버가 응답
• 클라이언트 사이드에 있는 애플리케이션 버퍼에 바이트가 쌓이게 됨
• 버퍼에 쌓인 바이트의 크기가 threshold를 넘어가면 클라이언트 애플리케이션이 재생 시작.
• 스트리밍 비디오 애플리케이션은 클라이언트 버퍼에서 주기적으로 비디오 프레임을 가져와서 압축을 해제하고 유저 화면에 보여준다.

Dynamic Adaptive Streaming over HTTP (DASH)

• 기존 방식의 문제점 :
  • 클라이언트마다 사용 가능한 bandwidth가 천차만별인데 모든 유저가 동일한 인코딩의 비디오를 받게 됨
• DASH의 방식
  • 여러 bit rate 인코딩 버전의 비디오를 제공
  • 클라이언트가 동적으로 비디오의 몇 초 구간을 요청
    • 사용 가능한 bandwidth가 높으면 클라이언트는 자연스럽게 high-rate 버전의 청크를 요청
    • bandwidth가 낮으면 low-rate 버전의 청크를 요청
• 각 버전의 영상은 다른 URL에서 서빙됨
• HTTP 서버는 manifest file에 각 bit rate 버전의 URL을 저장해두고 이를 제공.
  • 클라이언트가 이를 보고 적절한 버전을 선택하여 요청
• 클라이언트는 청크를 다운로드하면서 수신 대역폭(received bandwidth)을 측정하고 rate detrmination 알고리즘을 통해 다음에 요청할 청크 버전을 결정한다.

Content Distribution Networks

• 과제 : 거대 영상 스트리밍 서비스를 제공하려면?
• 옵션 1 : 하나의 거대한 데이터 센터
  • 이슈 1 : 클라이언트까지 너무 먼 경로를 거쳐야할 수 있음
  • 이슈 2 : 동일한 데이터가 동일한 커뮤니케이션 링크를 여러 번 거쳐야할 수 있음
  • 이슈 3 : A single point of failure
• 옵션 2 : CDN
  • 지리적으로 분산된 곳에 영상의 동일한 복사본을 저장해두고 서빙
  • private CDN, third-party CDN
  • Server placement philosophies(Huang 2008)
    • Enter Deep :
      • 서버 클러스터를 전세계 access ISPs에 설치
      • End user와 가까워져서 유저 입장에서의 딜레이와 처리량을 감소시키려는 목적
      • Akamai 가 취하는 전략
      • 분산되어 있는 특징으로 인해 클러스터를 유지/관리하는 것이 쉽지 않음
    • Bring Home :
      • 클러스터를 적은 수의 핵심 지점에 설치 (일반적으로 IXP에 설치)
      • 클러스터 유지/관리 비용 감소
      • Limelight와 여타 CDN이 취하는 전략
      • 유저가 느끼는 딜레이와 처리량은 증가
  • 보통의 CDN은 파일을 pull 전략으로 클러스터에 저장
    • 필요한 경우에 클러스터가 가져오는 방식

CDN의 동작 방식

사용자 호스트의 웹 브라우저가 URL을 지정하여 영상을 요청하면 CDN은 요청을 가로채서 클라이언트에게 적당한 CDN 클러스터를 선택, 클라이언트의 요청을 해당 서버로 리다이렉트

CDN이 요청을 가로채고 리다이렉트하는 방식

DNS를 활용
ex) 컨텐츠 프로바이더 NetCinema가 third-party CDN인 KingCDN을 통해 서브도메인이 "video"인 URL로 요청받은 비디오를 배포하는 상황

1. 사용자가 NetCinema 웹페이지를 방문
2. 사용자가 http://video.netcinema.com/6Y7B23V 링크를 클릭하면, 사용자의 호스트가 video.netcinema.com에 대한 DNS 쿼리를 보냄
3. 사용자의 로컬 DNS 서버(LDNS)가 NetCinema의 authoritative DNS 서버로 DNS 쿼리를 넘긴다. 넘겨받은 서버는 video.netcinema.com hostname에서 "video"를 발견하여 authoritative DNS 서버는 LDNS에 KingCDN 도메인의 hostname을 넘긴다(ex. a1105.kingcdn.com).
4. LDNS가 KingCDN의 private DNS 인프라로 DNS 쿼리를 날리고, DNS 서버는 KingCDN의 컨텐츠 서버 IP 주소로 응답한다.
5. LDNS는 content-serving CDN 노드의 IP 주소를 유저 호스트로 넘긴다
6. 클라이언트가 IP 주소를 받으면 TCP 커넥션을 통해 비디오에 대한 HTTP GET 요청을 수행한다. DASH를 사용하는 경우라면 서버는 클라이언트에게 manifest 파일을 먼저 보내고, 유저가 적절한 버전의 비디오를 선택할 것이다.

클러스터 선택 정책

• 지리적으로 가장 가까운 클러스터 할당
  • 지리적으로 가장 가까운 클러스터가 네트워크 경로 상으로 가장 가까운 클러스터가 아닐 수 있다는 한계
  • 멀리 있는 DNS 서버를 LDNS로 사용하도록 설정한 일부 사용자에 대해서는 부적절할 수 있음
• 클러스터와 클라이언트 간의 딜레이와 loss 성능을 측정하는 실시간 측정
  • 클러스터가 ping이나 DNS 쿼리를 주기적으로 LDNS에게 전송하여 측정
  • 많은 LDNS가 이러한 요청에 응답하지 않도록 설정되어 있다는 것이 한계