멀티미디어 앱은 결국 App 레이어의 영역으로,
유튜브, 음악 등의 데이터를 사용하는 서비스의 네트워크 부분에 집중한다고 보면 된다.
실생활에서 오디오는 아날로그 신호로,
결국 이를 어떻게 디지털 신호로 변환시킬 것인지에 대한 문제가 발생한다.
이처럼 아날로그 신호 => 디지털 신호로 바꾸는 것을 샘플링이라고 하며,
연속적인 오디오 신호를 단위를 짤라서 디지털 신호로 변환해야 하는데,
저 직사각형을 작고 촘촘하게 나눌수록 더 원본에 가까운 디테일한 소리를 표현할 수 있을 것이다.
Kbps : 1초에 n비트를 써서 표현
96kbps : 1초에 96kb를 써서 소리를 표현
1000kbps : 1초 소리를 1000Kb를 써서 표현
당연히 아래가 퀄리티가 좋을 것 아닌가?
비디오는 결국 이미지의 연속이다. 이 이미지를 "프레임" 이라고하며,
이미지는 결국 픽셀 별로 나누어 색을 줘서 표현한다.
비트레이트 = 1초 영상에 얼마의 데이터를 표현한다
Mbps(메가비트 퍼 세컨드)
영상이 2Mbps라면, 1초에 2메가비트를 사용하여 화면을 표현한다는 것이다.
이상적인 상황이면 2시간 영상짜리 데이터를 쭉 보내고, 쭉 받아서 차례대로 재생하면 문제없을 것이다. 그런데 이건 이상이고 ㅋㅋ
문제는 이 엄청난 스트림의 데이터가 빨리왔다, 늦게 왔다 오락가락한 딜레이가 발생한다는 것이다. 이것을 Jitter 라고 한다.
서버는 영상을 여러 데이터로 나누어 보낼 것이고, 클라이언트는 버퍼에 이를 저장할 것이다.
재생을 시작했는데, 재생 속도보다 평균적으로 받은 데이터가 적다면 당연히 중간에 끊길 것이고, 따라서 재생 속도보다 더 많은 데이터를 받아야 한다는 것이다.
그래서 처음 시작하기 전에, 일부러 3초 정도 시간을 둬서 재생 안하고 데이터를 받을 수 있는 시간을 버는 것이다.
단순히 기술적인 3초가 아니라, 사용자들이 감수할만 한 심리적인 시간까지 고려한 것이다.
그렇다면 이러한 영상 전송은 TCP일까 UDP일까?
UDP는 전송 속도를 누가 정하나? 보내는 사람 마음이다.
TCP는 전송 속도? 네트워크 상황 다라 다르다.(TCP는 Congestion control)
둘다 문제는 있다.
위 그림을 보면 TCP는 네트워크 상황에 따라 fill rate가 왔다갔다 한다.
그래서 이들이 생각해낸 방법은
기본적으로 HTTP에서 작동하고 웹 브라우저가 구현이 되어 있다.
비디오 파일을 여러 청크로 나누어 번호를 매기고,
kbps 별로 여러 버전을 만든다.
이를 manifest file이라고 한다.
그리고 이 각각 chunk 안에는 Url이 있다.
이 URL로 영상 데이터에 접근하는 것이다.
정리하면
여기서 웹 브라우저(유튜브 플레이어) 등이 속도를 지속적으로 측정해,
chunk를 받는 속도를 조절할 수 있다는 것이다.
그래서 영상볼 떄 화질 깨졌다가, 돌아왔다가 하는 것이다.
유튜브 서버가 LA에 있다고 가정하자.
전세계 많은 사람들이 동시에 요청을 할 것이고, LA 주변에서 엄청난 혼잡이 생길 것이다.
그래서 전세계에 복사본을 뿌려놓고, 요청한 사람의 가장 가까운 곳에서 받는, CDN 업체가 생긴다.
사실 chunk 안의 URL은 CDN의 URL이었던 것이다.
Ex.) kingcdn.com/matrix.m4
그렇다면, 가장 가까운 CDN을 어떻게 찾을 수 있을까?
kingcdn.com
에 접속하려면 어떻게 해야 되냐? IP로 바꿔야지.
그럼 먼저
CDN을 배치할 때, KT,SKT 같은 통신사 주변으로 배치를 한다.
만약 내 컴퓨터 바로 옆에 CDN에 있는데, 홉이 100개라고 해보자.
SKT 바로 옆에 있으면? 나는 인터넷을 쓰려면 반드시 통신사 Router를 거쳐야 할 것이다. 그 뒤는 광활한 인터넷이다.
어차피 입구가 SKT면, 그 입구 주변에 배치시키면 hop도 적을 것 아닌가?