(컴퓨터와 네트워크 / 이석복) 멀티미디어 네트워크 (Streaming Stored 방식, DASH)

본 게시물은 이석복 교수님의 네트워크 강의를 수강하며 작성한 강의노트와 추가 공부한 내용을 바탕으로 작성하였습니다.

• 참고 강의 및 사이트

KOCW

KOCW

 

---

 

유튜브 같은 멀티미디어가 네트워크 상에서 어떻게 동작하는 걸까? 멀티미디어 네트워크 파트에서는 이러한 서비스의 동작 방식에 대해 다룬다.

 

Multimedia : Audio

오디오와 같은 아날로그 신호는 어떻게 네트워크로 전달할까? 이를 디지털 데이터로 전환하는 것이 필요하다. 이러한 작업(아날로그 신호를 디지털 신호로 변환)를 Sampling이라고 한다.

연속적인 값(Continuous Value)을 전환하다보니 항상 오차가 발생한다. 표현하는 비트 수가 클수록 이러한 오차는 줄어든다. 즉, 샘플링의 주기가 얼마나 촘촘한가에 따라 본래 값과 얼마나 유사하냐가 결정된다.

bps는 1초에 나타내는 비트양을 의미한다.

CD는 1.411 Mbps로 96, 128, 160 kbps보다 더 고음질이다.

 

Multimedia : Video

영상은 이미지의 연속이다. 초당 나타내는 이미지 횟수가 많을 수록 고화질이 된다.

이미지는 곧 프레임이며, 각 픽셀의 어떤 색깔 값을 나타내는가에 대한 정보가 배열에 담겨 있다.

이미지에서 대개 근처 픽셀끼리는 같은 색을 가지고 있다. 따라서 중복되는 픽셀은 압축시켜서 프레임에 저장해놓는다.

초당 나타내는 프레임 수를 Coding rate라고 한다.

 

 

 

Multimedia networking : 3 Application Types

위에서 다룬 멀티미디어를 다루는 네트워크에는 아래와 같이 3가지 타입이 있다.

 

Streaming Stored

서버에 저장되어 있는 오디오를 틀어주는 방식이다.

Netflix나 Youtube가 이에 해당된다.

Conversational

실시간 대화를 위한 통신 방식으로 사용자 간에 음성, 영상, 텍스트 등 다양한 형태의 데이터를 교환한다.

Skype를 예로 들 수 있다.

Streaming Live

서버에 저장된 게 아니라 실제 촬영 중인 영상을 실시간으로 송출하는 방식이다.

Youtube Live나 아프리카 TV를 예로 들 수 있다.

 

 

Streaming Stored

이미지 출처 : 이석복 교수님 강의자료

위 3가지 방식 중 본 강의에서는 Streaming Stored 방식에 대해서만 자세히 다뤘다.

Streaming Stored의 이상정인 방식을 떠올려보자.

 

매 시간별로 frame이 전송되고 Client는 이를 받아서 재생시키면 된다. 하지만 현실적으로 클라이언트가 첫번째 프레임을 받자마자 미디어를 재생시키면 이는 재생되지만, 두번째 프레임에 대해서는 보장할 수 없다. 네트워크 문제로 다음 프레임을 재생해야 하는데 들어오지 않았을 때 delay가 발생하는 문제가 있다.

 

따라서 어느 정도 기다렸다가 재생을 하면 위의 문제가 발생하더라도 Client가 보기에는 delay 없이 재생이 가능하다. 이때 ‘어느 정도 기다리는 것’을 버퍼링이라 한다. 이런 버퍼링이 너무 길면 사용자가 해당 서비스에서 이탈할 가능성이 높아지므로 적당선에서 합의를 볼 필요가 있다.

 

 

 

TCP ? UDP ?

Streaming Stored 방식에서는 TCP와 UDP 중 어떤 방식을 사용해야할까 ?

UDP는 전송 속도를 보내는 측에서 결정할 수 있고 TCP는 전송 속도가 네트워크에 의해 결정된다. 이런 이유로 UDP가 좋아보일 순 있지만, 네트워크 상황이 안 좋아졌을 때 Client는 아예 데이터를 받을 수 없어 UDP도 적절하지 못하다.

 

 

 

DASH : Dynamic Adaptive Streaming over HTTP

그 대안이 바로 DASH라는 프로토콜이다.

 

2GB 짜리 영화를 있을 때 이를 통째로 저장하는 것이 아니라 작은 단위(chunks)로 쪼갠다. 이 청크들을 한 번에 원하는 속도로 인코딩하지 않고, 128kbps, 256kbps, … , 1mbps … 과 같이 여러 버전의 코딩데이터를 만들어 놓는다. 그리고 각 버전이 저장된 url을 저장해 높은 테이블이 있다. 이러한 테이블을 Manifest file 이라고 한다.

 

실제로 유튜브에서 영상을 조회하면, 영상 파일이 스트림되는 것이 아니라 이 Manifest file을 넘겨준다. 클라이언트는 chunk 1번부터 가장 낮은 버전의 url을 가져와 재생시킨다. 또한 이 때의 속도를 측정해 양호할 경우 더 높은 버전의 url을, 문제가 발생하면 낮은 버전의 url을 재생시키는 것이다.

 

 

전 세계 사람들이 이용하는 Youtube이기에 동시 사용자가 많을 수 있다. 한 곳에 이 url이 모여있으면 그 곳으로 요청이 몰려 문제가 발생한다. 따라서 CDN을 활용한다.

 

CDN이란, Infra structure 업체들과 계약을 맺어 서버를 곳곳에 분산시키는 방식이다.

따라서 사용자의 요청이 들어오면 Youtube는 manifest file만 넘기고 사용자는 근처 서버에서 데이터를 받아오게 된다.

 

여기까지 살펴보면 다음과 같은 의문이 든다. 같은 Manifest file을 가지고 어떻게 다른 서버에 데이터를 요청할 수 있을까? 다음과 같이 동작하여 사용자들을 다른 서버에 분산시킨다.

Manifest url을 찾아가려면 해당 IP를 알아야 한다. 이를 위해서는 DNS 쿼리를 보내 IP를 알아낸다. CDN 업체가 UDP에 담겨 온 DNS 쿼리의 IP를 보고 가장 근처의 IP를 보내주는 것이다.