Multimedia

어떻게 multimedia service가 동작하는지에 대해 알아본다.

결국 application layer의 이야기이다. 우리가 이제까지 얘기했던 application layer는 HTTP에 관한 것이었다. '

audio

아날로그 signal로 공기에 wave를 타고 가는 신호이다.

이를 정형화된 디지털 signal로 바꾸는 과정이 필요하다. 이러한 과정을 샘플링 과정이라 한다.

따라서 주기적으로 그때그때의 값이 무엇인지 판단해 변환한다. 하지만 아날로그 value이므로 디지털 데이터 처럼 딱 맞아떨어지지 않는다. 그렇기 때문에 디지털 value로 바꿀 때 항상 오차가 발생한다.

아날로그 신호를 디지털 신호로 바꿀 때 비트의 수가 크면 클수록 에러의 수가 줄어든다. 또한 측정하는 주기를 줄이면 오차가 더욱 줄어든다. 얼마나 복원을 하느냐는 sampling하는 주기와 데이터의 크기에 의존한다.

예를 들어 audio signal을 초당 8000번 sampling하고 sampling할 때 마다 8bit 크기의 value를 사용한다면 64000bit가 필요할 것이다.

아래는 coding rate를 나타낸 것이다. 즉, 초당 아래에 나온 비트만큼을 가지고 인코딩한다.

• CD: 1.411 Mbps
• MP3: 96, 128, 160 kbps
  MP3를 볼 때 96kbps보다 160bps를 사용하는 것이 음질이 더 좋다.

MP3보다 CD가 더 좋은 음질을 가진다고 할 수 있다.

video

video는 이미지의 연속으로 초당 그림 몇개를 연속으로 보여주는 것이다. 각 이미지를 frame이라고 한다. 이를 어떻게 디지털 파일로 어떻게 저장시키는가? 각 픽셀에 어떤 색 value가 나타나는가를 적어놓으면 된다. 이웃한 픽셀에는 색이 비슷하므로 이를 압축해서 표현한다. 첫 픽셀에는 무슨 색이고, 연속한 몇개의 픽셀이 동일한 색이다라고 표현하면 훨씬 크기가 줄어들 것이다. 이것이 바로 pixel 단위로 인코딩을 하는 것이다.

coding rate가 높으면 높을 수록 화질이 좋을 것이다. 예를 들어 2Mbps인 비디오라면 초당 필요한 frame들이 2Mbit로 압축되어 표현되어있는 것이다. 따라서 최소 이 속도보단 빠르게 보내야 receiver가 이를 받아 영상을 송충하는데 무리가 없다.

3 application types

streaming, stored audio, video

Multimedia인데 이미 서버에 저장되어 있고, 저장해놓은 것을 클라이언트에게 스트리밍하는 것이다. 예로 유튜브같은 것이다.

streaming live

이는 streaming, stored와 대비되는 것으로 서버에 저장되어 있는 것을 전송하는 것이 아닌 지금 실제로 일어나고 있는 것을 실시간으로 받는 것이다. 예로 야구 중계같은 것이 있다.

conversational

예를 들어 skype가 있다.

streaming stored video

유튜브에서 영화를 본다고 가정해보자. 그렇다면 유튜브 서버에서 가장 먼저하는 일은 frame 파일을 만들어놓고, 요청이 온 크라이언트에게 순서대로 전송한다. 클라이언트는 이를 받아 송출하면된다. 이것이 이상적인 상황인데, 현실에서는 일정하게 전송되지 않는다.

따라서 클라이언트가 데이터를 전송받자마자 재생하면, 뒤의 frame이 도착하지 않았을 때 문제가 생긴다. 따라서 network delay가 일정하지 않다는 network jitter가 생긴다. jitter가 발생하기 때문에 바로 재생시키면 안된다.

클라이언트가 frame을 받는 시간이 다 다른것을 볼 수 있다. 따라서 이를 받자마자 재생하는 것이 아닌, 조금 기다렸다가 재생하면 jitter가 있더라도 괜찮은 것이다. 이를 버퍼링이라고 한다.

그런데 client playout delay가 길어지면, 즉 많이 받아놓고 재생하는 시간이 너무 길면 사용자는 지칠 것이다.

버퍼를 채우는 것은 서버의 데이터이고, 버퍼를 비우는 것은 video player이다. 항상 버퍼에 무언가가 있어야하므로 위의 만큼 채워놓고 시작하는 것이다. 뭔가가 남아있기만 하면된다. 만약에 player의 속도가 서버가 전송하는 시간보다 빨라 버퍼가 비어버리면 동영상을 보다가 버퍼링이 생기는 것이다. 그렇다면 사용자가 불편을 느껴 떠나게 되는 것이다.

결국 버퍼를 채워놓고 비지 않게 하는 것이 핵심이다.

유튜브와 클라이언트 사이의 통신이므로 applicatio사이의 통신이므로 transport layer의 TCP와 UDP 중 하나를 사용한다. 무엇을 사용하는 것이 좋을까? 2Mbps짜리 영상을 제공한다면 전송하는 속도가 이보다 더 빨라야한다.

UDP를 사용하면, 전송하는 시간을 전송하는 쪽에서 정한다. 하지만 TCP를 사용하면 전송하는 시간을 network가 정한다. 따라서 이러한 이유로 UDP를 사용한다고 생각할 수 있다.

UDP를 사용한다는 것은 네트워크 상황을 고려하지 않고 그냥 2Mbps를 쏟아내는 것이다. 예를 들어 중간에 네트워크 상황이 안좋아서 중간에 2kbps의 속도가 된다면 동영상이 재생되지 못하고 엄청 느려질 것이다. 하지만 TCP를 사용하면 2Mbps로 보내질 못한다. 즉, trade off가 있다. 그렇다면 어떻게 할까?

결론적으로는 DASH라는 것을 사용해 TCP를 사용한다.

DASH

DASH: Dynamic, Adaptive Streaming over HTTP

동적으로 네트워크 환경에 적응해 보내준다는 것으로 보인다.

youtube에서 2GB짜리를 이를 통째로 2Mbps로 보내면 문제가 생긴다. 따라서 이를 아주 작은 크기의 chunk로 잘게 쪼개 여러 버전(128kbps, 256kbps, 512kbps ...)을 만든다. 그리고 각각의 버전별 청크의 URL이 적혀있다. 아래의 표와 같을 것이다.

chunks/coding rate	128kbps	256kbps	512kbps	1Mbps	2Mbps	5Mbps
1	URL	URL	URL	URL	URL	URL
2	URL	URL	URL	URL	URL	URL
3	URL	URL	URL	URL	URL	URL
4	URL	URL	URL	URL	URL	URL
5	URL	URL	URL	URL	URL	URL
..	URL	URL	URL	URL	URL	URL

이 테이블을 manifast table이라 한다. 따라서 유튜브에 들어가 영화를 클릭하면 이 table을 넘겨준다. 그렇다면 클라이언트는 이를 받아 재생하는데, 처음에는 낮은 속도의 chunk를 재생하고 네트워크 상황이 괜찮으면 점점 속도를 올린다. 그러다가 문제가 생기면 속도를 낮춘 chunk를 재생하는 것이다.

따라서 이를 통해 영상의 화질이 안좋아지더라도 끊기지 않는 것이고, 계속 화질이 안좋은 것이 아닌 네트워크 상황에 따라 좋은 화질을 송출할 수 있는 것이다.

유튜브에 같은 시간에 요청을 하는 사용자는 어마어마하게 많을 것이다. 그렇다면 유튜브는 이 파일을 어디에 저장할까?

가장 단순한 방법은 서버를 하나 두고 저장했다가 주면된다. 문제점은 이 서버가 죽으면 모든 서비스가 죽고, 하나의 서버에 모든 요청이 몰리게 되어 delay가 심해지고 그렇다면 네트워크 상황이 좋아지지 않아 낮은 화질의 동영상을 제공할 수 밖에 없을 것이다.

그렇다면 어떻게 해야될까?

두가지가 있다.

첫번째 방법은 multicast라는 방법이다. 지금까지는 cliter와 server사이의 둘사이만의 통신으로 unicast 통신이었다. 같은 데이터를 여러 사용자에게 보내면 많은 양의 같은 데이터가 몰려 혼잡이 생긴다. 따라서 데이터의 copy를 보내 어느 한곳에서 copy되어 각각의 클라이언트에게 보내는 것이다. 하지만 이는 구현이 어려워 대부분 지원이 되지 않는다.

두번째 방법은 CDN이다.

Contents Distribution Network이다.

Contents가 저장된 스토리지 자체를 전세계 곳곳에 두는 것이다. 그리고 사용자가 유튜브에 접속하면 manifast table을 넘겨주고 이 URL에 요청을 보내면 사용자의 근처에 있는 스토리지에 가서 가져오는 방식이다.

즉, 이 CDN 업체들은 infraStructure 업체이다.

table의 URL은 전세계의 사용자들이 같다. 그렇다면 같은 URL인데 어떻게 각각의 사용자의 근처에 있는 스토리지에 접근할 수 있는 것일까?

예를 들어 유튜브가 kingCDN이라는 업체와 계약을 했다고 가정하자. 사용자는 URL로 요청하면 유튜브는 response로 redirect uri를 준다. 그러면 사용자는 이 host의 IP를 알아야하는데, 이는 DNS가 알려준다. 처음엔 local DNS에 요청하는데 이게 없다면 King CDN의 DNS가 이 IP를 알고있으므로 알려준다. 따라서 IP 매핑을 King CDN의 DNS가 해주는 것이다. 이 King CDN이 요청한 사람의 IP 를 보고 가까운 위치의 스토리지를 알려주는 것이다.

CDN은 어디에 위치하는게 좋을까? 나와 물리적 거리가 아닌 네트워크 상에 hop 수가 적은 곳에 있는 것이 좋다. 따라서 사용자 위치에 가까이 있기 위해 access network 근처에 둔다.

netflix도 amzon cloud에 모든 것을 넘기고 계정만 관리해 table만 넘겨준다.