멀티미디어 네트워크

이 글은 한양대 이석복 교수님의 강의를 복습하며 작성한 글입니다.

 

멀티미디어 : 오디오 

• 샘플링 
  • 아날로그 신호를 디지털 신호로 변환하는 작업 
  • 오디오는 연속적인 아날로그 신호이며, 네트워크에서 사용하기 위해서는 디지털 신호로 변환이 필요함.
• 샘플링의 파라메터
  • 샘플링 비트 : 샘플링 비트는 주어진 크기를 얼마나 잘게 쪼갤지를 의미함. 
  • 샘플리 주기 : 샘플링 주기는 주어진 시간을 얼마나 잘게 쪼갤지를 의미함. 
• 샘플링 비트 + 주기가 크면 클수록 디지털 신호는 아날로그 신호에 가까워진다. 
• Sender는 샘플링해서 값을 전송하고, Receiver는 받은 값을 다시 아날로그 신호로 바꾼 후 사용한다. 

 

멀티미디어 : 비디오

• 비디오는 이미지의 연속이다.
  • 이미지는 프레임이라고 표현한다. 프레임은 픽셀로 나눠지고, 각 픽셀이 어떤 색깔이 나타나는지를 저장한다. 
  • 오디오와 동일하게 코딩 레이트가 크면 클수록 화질이 좋다. 
• 예시 
  • 동영상의 코딩 레이트가 2Mbps다. 이 말은 1초동안 영상은 재생하는데 최소 2Mbps의 데이터가 필요하다는 것이다.
  • 네트워크 관점에서는 Sender → Receiver로 2Mbps 이상의 데이터가 전송되어야 한다는 것이다. 

 

네트워크에서 동영상을 전송하는 방법(Streaming Stored Video)

• Streaming, Stored Audio/Video
  • 위 방법은 이미 서버에 저장된 멀티미디어 파일을 사용자들에게 전송해주는 것이다. 
• 유투브에서 동영상 재생 
  1. 영상은 프레임으로 나눠져서 클라이언트에게 순서대로 발송된다. 
  2. 서버에서 보낸 프레임 파일은 Network Delay 이후에 사용자에게 전송되게 된다. 그리고 사용자는 이 프레임 파일을 재생한다. 
• 문제점
  • 현실에서는 Network Delay가 일정하지 않다. 왜냐하면 네트워크 상황은 매번 변하기 때문이다.
  • 따라서 각 프레임이 클라이언트에게 전송되는 시간이 달라지는 Jitter가 발생한다. 
• 버퍼링
  • Jitter 문제로 인해 클라이언트는 프레임을 받으면 바로 영상을 재생하지 않는다.
  • 받은 프레임을 버퍼에 차곡차곡 쌓아두고, 일정 시간 이후에 재생을 하는 방식으로 Jitter를 해결한다. 
  • 버퍼에 채워지는 속도보다 사용자가 소비하는 속도가 빠를 경우, 동영상은 정상 재생이 되지 않는다. 

YouTube는 어떤 Transport 프로토콜을 사용할까?

• UDP는 전송 속도를 사용자가 제공한다. 네트워크의 상황을 고려하지 않고 원하는 만큼 막 데이터를 전송한다. 이럴 때 문제점은 실제로 네트워크가 혼잡할 경우 나는 2000개를 보내도, 실제로 전달 받는 것은 2개 정도 일 수도 있다는 것이다. 
• 위 이유 때문에 YouTube는 TCP 프로토콜을 사용한다. 실제로는 TCP를 이용한 DASH라는 것으로 처리된다.

 

 

DASH : Dynamic, Adaptive, Streaming Over HTTP

• DASH(Dynamic Adapative, Streaming Http)
  • DASH는 HTTP 프로토콜을 이용하여 동적으로 괜찮은 수준의 파일을 전송하는 기술이다. 
  • DASH는 동영상을 작은 Chunk 단위로 쪼개고, 그 쪼갠 파일을 각각의 코딩 레이트에 맞춰 다시 한번 인코딩을 한다. 그리고 각 Chunk + 화질에 대한 URL을 기록한 파일을 만들어둔다. 
  • 위의 파일을 ManiFest File이라고 한다. 유투브는 동영상 실행 요청이 오면, 사용자에게 이 Manifest 파일을 전송한다. 
  • 사용자는 Chunk 1번의 최소 화질부터 실행을 한다. 정상 전송 시, 다음 Chunk는 높은 화질의 Chunk를 요청한다. 정상 전송이 안될 경우, 낮은 화질의 Chunk를 실행한다. 이처럼 네트워크 환경을 고려해서 동적으로 요청한다. 

ManiFest File 예시

Chunk	128kbps	256kbps	512kbps	1Mbps	2Mbps	4Mbps
#1	URL	URL	URL	URL	...	...
#2	...	...	...	...	...	...
#3	...	...	...	...	...	...
#4	...	...	...	...	...	...

 

 

• 만약 유투브 서버가 하나로 생성되어 있다고 하면, 전세계 모든 지역에서 요청이 온다. 이렇게 될 경우, 해당 지역의 네트워크는 굉장히 혼잡스러워진다. 따라서 해당 네트워크의 다른 구성원에도 피해가 있으며, YouTube를 이용하는 모든 사람들의 화질은 최소 화질로 설정되게 될 것이다. 
• CDN (Content Distribution Network)
  • CDN 서비스는 전세계에 데이터 센터를 만들어 두고, 동일한 형태의 파일을 가지고 있는다. 
  • 유투브는 사용자에게 요청이 오면 Manifest 파일만 전달해준다. 사용자는 Manifest 파일을 읽어서 Chunk 데이터를 요청한다. 
  • 사용자가 Chunk 데이터를 요청하면, 사용자 근처의 CDN 데이터 센터에서 값을 전송해준다. 

 

CDN 서버 요청은 어떻게 처리되는 걸까?

• Youtube가 전달해주는 Manifest 파일은 동일하다. 바꿔 이야기하면 전세계의 어떤 사람도 Chunk 파일을 요청할 때, 동일한 URL로 요청을 한다. 그런데 어떻게 세계 각국의 사람들은 가까운 CDN에서 데이터를 받아오는 걸까? 
• 유투브가 ACDN과 계약을 했다고 가정하자. 
  1. 사용자가 Chunk URL로 요청한다. HTTP 요청은 Youtube로 가게 된다.
  2. Youtube는 사용자에게 ACDN.com으로 Redirect 응답을 내려준다. 
  3. 사용자는 Redirect URL을 알기 위해 ACDN.com의 IP를 알아야한다. 이 때, IP를 알기 위해 DNS 쿼리가 발생된다.
  4. IP는 ACDN의 Autorative DNS 서버가 알려준다. 이 때, Redirect할 CDN 센터를 동적으로 알려준다. DNS 쿼리에는 사용자의 출발지 정보가 있고, 이 출발지 정보는 지역 정보와 연결되어 있기 때문에 가까운 CDN IP를 알려준다. 
• 위 동작 때문에 사용자는 같은 URL로 Youtube에 데이터를 요청해도, 각각에게서 가까운 CDN 센터에서 데이터를 받아올 수 있게 된다. 

 

CDN 서버는 어디에 있어야 할까?

• CDN 서버는 논리적으로 가장 가까운 위치에 있어야 한다.
• 논리적으로 가장 가까운 위치는 최대한 적은 Hop으로 이동할 수 있는 것을 의미한다. 이것은 KT, SKT 브로드밴드의 라우터 근처를 의미한다.
• 대부분의 사용자는 국내 통신사를 사용하고 있으며, 해당 통신사를 통해 인터넷으로 나가게 된다. 따라서 CDN 센터가 해당 통신사의 서브넷 내부에 있다면 아주 적은 HOP으로 접근해서 데이터를 받아올 수 있게 된다.