멀티미디어네트워크

어떻게 youtube같은 멀티미디어 서비스가 동작할까?

 

Multimedia File Type

오디오

 

• analog signal을 digital로 바꿔야 한다.
• 이 과정에서 에러(오차)가 발생한다
• digital bit의 수가 많을수록 에러는 줄어든다.
• 주기를 촘촘하게 할 수록 에러는 줄어든다. (sampling rate or coding rate. ex) 초당 64000bit) 

비디오

• 각 이미지를 frame이라 표현한다.
• 각 pixel에 어떤 색깔 value가 나타는지가 이미지를 결정한다. 인접한 pixel은 유사하므로 압축할 수 있다. 
• coding rate가 높을수록 화질이 좋다. (2Mbps 의 coding rate : 이미지 표현에 초당 2mega bit 사용)

application type

multimedia file을 사용하는 애플리케이션은 무엇이 있을까?

•  streaming, stored audio, video
  • 서버에 이미 저장되어 있는 파일을 보여준다. youtube
• streaming live audio, video
  • 실시간. 축구 중계
• conversational 
  • skype, discord

streaming stored video

이상적인 상황은 이렇다.

1. 프레임별로 저장된 비디오
2. 클라이언트에게 전송 
3. 비디오 수신 

하지만 2와 3 사이의 network delay가 일정하지 않다. 클라이언트는 프레임 1을 받고 프레임 2를 받기 까지의 delay가 발생할 수 있다. 영상이 smooth하지 않게 된다. 이것을 network jitter가 발생했다고 한다.

실제 클라이언트가 frame을 받는 것은 검은색 그래프와 같다. 따라서 frame을 받는 것과 play 하는 것 사이의 client playout delay = buffering을 둔다. 다만 버퍼링이 너무 긴것도 사용자 입장에서 좋지 않다. 

버퍼에 frame이 남아있기만 하면 된다. playout rate보다 fill rate가 높다면 결국 버퍼가 비게 되고 버퍼링이 발생할 것이다.

 

•  youtube와 client는 application이므로 transport layer에 의존한다. (tcp or udp)
• video file의 coding rate가 2Mbps라면 전송속도가 2Mbps 이상이어야 client가 영상을 smmoth하게 재생할 수 있다. 
  
  • UDP : nw 상황에 관계없이 전송자가 속도를 결정할 수 있다. 따라서 2Mbps 이상으로 보낼 수 있다.
  • TCP : nw 상황에 따라 전송 속도가 좌우된다. 
  • UDP를  쓰자니 nw 상황이 2Mbps 미만이면 내가 보내는 것과 상관없이 제대로 도착하지 않을 것이고, TCP를 쓰자니 내가 보내는 속도를 맘대로 조절할 수 없다. 

Dash

youtube 같은 application은 dash(dynamic adaptive streaming ove http)라는 application 기술을 사용한다. 

• 큰 영상파일을 먼저 작은 단위의 chunk로 나눈다.

• 각 chunk별로 여러 coding rate 버전을 만들어 놓는다. 이것을 manifest file이라 하며 해당 chunk가 저장된 url이 적혀 있다.
• youtube는 client가 영상 재생을 클릭하면 manifest file을 넘겨준다.
• 1번 chunk는 낮은 coding rate로 시작했다가 nw 상황이 양호하면 점점 높인다. 그러다 다시 속도가 안나오면 낮춘다. 
• 영상 시청할 때 화질이 낮아졌다가 높아졌다 하는 이유가 dash 때문이다.

그렇다면 manifest file의 각 chunks에 대한 요청은 client들에게 어떻게 제공할까?

• 서버 하나에 두고 모든 사용자들에게 제공할 수 있다.
  • 서버가 다운되면 모든 사용자가 장애를 겪는다
  • 요청이 몰리면서 delay가 발생해 모두 매우 낮은 coding rate의 영상을 제공받게 될 것이다
• 2가지 해결방법이 있다.
  • Multicast

• Multicast는 라우터에서 구현하기 힘들어 대부분 라우터에서 지원하지 않는다.

CDN

• CDN (Content Distribution Network) 라는 application layer의 기법을 사용한다. 
  • content가 저장된 storage 자체를 전세계 곳곳에 위치시킨다
  • youtube는 client에게 manifest file만 제공하고 이에 대한 각각의 요청은 인접한 CDN에서 받는다. 
  • CDN업체는 전세계 곳곳의 infrastructure 업체들이다.

아르헨티나에 사는 메시도, 포르투갈에 사는 호날두도 같은 url movie.youtube.com/starwars.chunk1로 영화 스타워즈에 대한 chunk를 요청할 것이다. 어떻게 같은 url에 대한 요청을 메시한테는 아르헨티나의 CDN에서, 호날두한테는 포르투갈의 CDN에서 응답하게 할 수 있을까?

• youtube는 요청을 movie.kingcdn.com/starwars.chunk1로 리다이렉트 시킨다.
• movie.kingcdn.com의 ip 주소를 메시와 호날두는 dns server를 통해 얻는다.
• 이 정보는 kingcdn의 dns server가 제공한다. (또는 전에 제공했다.)
• kingcdn의 dns sever는 누가 주소를 요청하는지에 따라 다르게 답한다. 요청의 ip src를 보고 인접한 cdn의 주소를 알려준다. 메시에게는 포르투갈의 kingcdn의 ip를, 호날두에게는 포르투갈의 kingcdn의 ip를 제공한다. 
• cdn에게 요청하는 ip는 access nw를 나가면서 nat에 의해 변환된다. 즉 cdn server가 access network (skt의 gateway router 등)에 가까이 위치하는 것이 사용자로부터 hop 수가 가깝다. 

netflix는 계정 관리 서버만 두고 cdn 업체들을 통해 manifest file을 제공하는 방식으로 운영한다.