멀티미디어 네트워크

멀티미디어: 오디오

아날로그 시그널을 시간에 따라서 크기값이 변하는 스무스한 시그널이다. 이를 정형화된 디지털값으로 변환을 해야 전송을 할 수 있고 이 값을 sampling 값이라고 한다.

얼마나 복원을 하느냐? 샘플링하는 데이터의 크기와 주기에 관련이 있다.
어떤 의료 시그널을 초당 8000번, 매번 8bit 크기의 value를 사용하여 실제 value로 바꾼다고 하면 초당 64000bit가 필요하다. 그리고 이를 coding rate라고 한다. coding rate가 클수록 original rate에 가까워진다.

96kbps => 1초동안 음향을 96kbit로 표현했다. 즉, 최소 96kbps로 mp3로 전송하려면 좀더 빠르게 coding rate를 해야겠다.

멀티미디어: 비디오

각 이미지를 frame이라고 표현하고 digital로 변환할때 각 pixel에 어떤 색깔 value가 나타난다고 작성해두면 된다. 이웃한 pixel은 비슷한 색깔 value가 작성되므로 pixel 단위로 encoding을 진행한다. 즉, 중복된 정보를 압축시켜 줄이는 것이다. 이 역시 coding rate가 높을수고 화질이 좋아질 것이다. sender입장에서 필요한 데이터가 2mbps 밑으로 sender가 receiver로 전달하려면 2mbps 보다 빠르게 전송하는게 좋다.

멀티미디어의 3가지 적용유형

1) streaming, stored 오디오, 비디오

• 서버에 저장되어 있음
• 연속적으로 상영되는 영상들
• 예) 유투브, 넷플릭스

2) streaming live audio, video

• 서버에 저장되지 않음
• 실제 일어나고 있는 영상을 실시간으로 받는 것.
• 예) 야구

3) conversational voice/video over IP

• 예) 스카이프

다음부터는 streaming stored 오디오에 대해서 살펴보도록 하자

Streaming stored video

예를 들어 영화를 유투브에서 본다고 해보자.
영화는 frame의 연속이므로 매 시간별로 frame을 재생시킨다.
1) frame 순서대로 서버가 보낸다.
2) frame 순서대로 받은 file이 네트워크를 거친다.
3) 클라이언트가 file을 받는다.

현실적으로는 첫번째 frame은 재생이 되나 2번째 frame이 network delay를 유지하지 못한다면 문제가 발생한다. 즉 network delay가 일정하지 않은 'network deter'가 발생하는 것이다. 따라서 바로 재생시키지 않고 현실에서는 다음과 같다.

1) 첫번째 frame을 받고 어느정도의 시간 (=버퍼링)을 기다린다.
2) 이후에 두번째 frame을 전달 받고 재생시킨다.

그렇다면 버퍼링이 길수록 결국 재생이 연속적으로 재생될 수 있는데 또 너무 길어버리면 client 입장에서는 너무 많이 기다려야 한다. 따라서 그 중간의 적정 지점으로 buffer를 정한다.

그럼 버퍼사이즈를 정하는 기준에 대해서 알아보자.

client-side buffering

버퍼를 채우는 것은 서버에서 들어오는 frame들이다.
처음에 buffer를 채우고 시작해야 client는 frame을 계속 playout 시킬 수 있다.
playout 속도가 빠르면 buffer가 비고 결국 client는 재생시킬 frame이 없어서 실질적으로는 영상이 끊기거나 중단되는 현상이 발생한다.

• YouTube <-> client

어플리케이션 사이 통신은 transport layer에 의존한다. (TCP, UDP)를 사용하여 영상을 전송할텐데 예를 들어 2mbps의 영상을 보낸다고 한다면 보내는 속도는 2mbps 이상이 되어야 한다. 이런 경우엔 어떤 transport layer를 사용할까?
UDP를 사용한다면 전송속도는 youtube가 정할 수 있기 때문에 유리할 것이다. 이미 2mbps로 인코딩된 영상을 UDP로 보낸다고 할때 중간에 네트워크 상황이 안좋아져서 2kbps의 속도를 지나는 시기가 있다고 해보자. UDP는 네트워크 상황에 전혀 적응할 수 없으므로 사용자가 받게 될 영상 속도는 2kbps 가 된다.
그렇다면 TCP를 사용하면 어떻게 될까? TCP는 네트워크 상황을 조절할 수 없기 때문에 불리할 것이다.
유투브는 TCP를 사용한다. 네트워크를 조절할 수 있는 TCP에 더불어 "DASH"라는 어플리케이션 기술을 사용한다.

다음에서는 DASH에 대해서 알아보자.

streaming multimedia: DASH

• TCP를 사용해 데이터를 전송한다.

• 동적으로 네트워크 상화을 조절한다.

• YouTube <-(매트릭스 영화: 2GB) -> client

매트릭스 영화같은 큰 영상 파일을 "chunk"라는 작은 영상단위(대략 256KB)로 나눈다. client는 나눠진 chunk들을 순서대로 받는데 이때 각 chunk들은 128kbps, 256kbps .. 단위로 나눠진 버전들이 존재한다.

위 그림을 보면 각 chunk별로 나눠진 테이블을 "manifest table"이라고 부른다. 그리고 각 테이블 값들은 chunk에 해당하는 버전으로 인코딩된 영상의 url이 값으로 들어있다.
테이블에 대해 간단히 소개하면 a 버전보다 b 버전을 client가 빠르게 받아야하고 화질이 좋은 것을 알 수 있다.

처음에는 chunk 1번의 128kbps를 가져온다.
이때 네트워크의 속도를 측정하고 영상을 잘 받아온다면 그 다음에는 chunk 2번의 256kbps
또다시 잘 받아오면 chunk 3번의 512kbps 버전을 가져온다. 이렇게 점차 버전을 높여가다가 영상이 잘 안받아오지면 정지된 버전의 영상을 계속해서 받아온다.

이렇게 되면 네트워크 상황에 따라 최대한의 화질의 영상을 받아올 수 있다.

• 그러면 유투브는 각 버전들이 저장된 table로부터 동시간대에 수많은 client에게 전송해야 하는데 각 버전의 영상들을 어디에 저장할 것인가?

가장 단순한 방법은 youtube 서버에 영상을 저장하고 요청이 들어오면 영상을 전달하는 것이다. 그러나 다음과 같은 문제점이 있다. 1) youtube 서버가 다운되면 데이터를 전송할 수 없다. 2) 한꺼번에 요청이 몰리면 youtube 근처 네트워크가 막힐 것이다. 걀국 end-to-end delay가 발생하면서 128kbps 버전의 영상들만을 내보낼 것이다.
그럼 어떻게 해결해야 할까?
1) multi cast
지금까지의 방식은 unicast 방식이었다. 동일데이터를 보내야하는 경우는 copy 본 하나만 나가고 여러 갈래로 나뉘는 multicast 방식을 사용하는 것이다.

2) content distribution network (CDN)
어플리케이션 기법을 사용하여 몰린 상황을 해결한다. content가 저장된 storage 자체를 전세계 곳곳에 위치시킨다. client가 요청을 보냈다면 manifest 파일만 youtube 서버가 알려주고 client 근처에 있는 CDN서버의 storage에서 값을 가져오는 방식이다. CDN업체는 infra structure 로 컨텐츠 업체들과 계약을 맺고 storage 역할을 한다.

• 그런데 manifest table은 특정 영상의 버전은 동일 url을 포함하고 있는데 서로다른 지역 a, b에 위치한 두 client는 동일 url을 어떻게 각 a, b 지역 CDN 서버에서 가져오는 것일까?

유투브는 manifest table의 url을 보낼때 각 지역의 CDN 서버로 리다이렉트 시키는데 이 CDN서버는 다음과같은 절차로 알 수 있다. (1) client는 DNS쿼리를 UDP에 포함시켜 보낸다. (2) 그 UDP 속 IPpacket의 source를 보면 client의 sourceIP를 알 수 있다. (3) client와 가장 가까운 위치의 CDN 서버의 ip주소를 전송한다.

• client는 사실상 NAT와 같은 서버때문에 실제 ip를 알기 어렵지 않을까? 어떻게 실제 IP를 알 수 있을까?

client가 무선랜 라우터와 연결되고 무선랜이 sk broadband와 연결되면 그 이후에 internet이 있다. 따라서 client는 무조건 sk broadband 를 무조건 지나야 internet을 access 할 수 있다. (sk broadband는 client에게 access network이다.) 그러면 client가 보낸 DNS 쿼리 source는 access network일 것이므로 그 근처의 CDN source IP를 보내면 된다.
그래도 client에게 hops가 가장 가까운 곳에 위치시키기 위해 sk broadband와 같은 access network 근처에 CDN 업체들이 대부분 위치한다.

Netflix

인프라가 없고 netflix server는 1) 계정과 2) manifest 파일만 관리하고 나머지 CDN storage가 전체 영상을 근처 고객에게 전송한다.