Multimedia Networking: 두 판 사이의 차이

youngwiki
50번째 줄: 50번째 줄:


==VoIP==
==VoIP==
인터넷을 통한 실시간 음성 대화는 종종 인터넷 전화(Internet telephony)라고 불리는데, 사용자 관점에서는 전통적인 회선 교환 전화 서비스와 유사하기 때문이다. 또한 실시간 음성 대화는 일반적으로 VoIP(Voice-over-IP)라고 불린다. 화상 대화(conversational video)는 VoIP와 많은 면에서 유사하지만, 음성뿐 아니라 참가자의 영상도 포함된다는 점에서 차이가 있다.
===Limitations of the Best-Effort IP Service===
[[IPv4 Addressing|IP(Internet Protocol)]]는 Best-Effort 서비스를 제공한다. 즉, IP는 각 데이터그램을 출발지에서 목적지로 가능한 한 빨리 전송하려고 노력하지만, 지연 시간이나 패킷 손실 등에 대한 보장은 하지 않는다. 이는 큰 문제가 될 수 있는데, VoIP 애플리케이션은 지연(delay), 지터(jitter), 손실(loss)에 매우 민감하기 때문이다. 이때 VoIP 애플리케이션이 reliable data transfer를 위해서 TCP를 사용하지 않는 이유는 TCP의 재전송 메커니즘이 end system 사이의 지연을 증가시키기 때문이다. 또한 TCP의 혼잡 제어는 패킷 손실이 발생했을 때 전송 속도를 낮추므로 수신 속도보다 송신 속도가 느려질 수 있고, 이에 따라 버퍼 고갈(buffer starvation)이 발생하여 수신자 측에서 음성 이해 가능성(intelligibility)이 심각하게 저하될 수 있다. 이에 따라 대부분의 VoIP 애플리케이션은 기본적으로 UDP를 사용한다.
해당 문단에서는 best-effort 네트워크 환경에서도 application layer에서 VoIP 성능을 향상시킬 수 있는 방법들을 다룬다. 이에 대한 논의를 구체적으로 하기 위해서, 다음의 VoIP 예시를 사용한다:
* 송신자는 초당 8,000 바이트를 생성한다.
* 송신자는 20ms마다 바이트들을 모아 하나의 청크로 만든다.
* 이 chunk는 특수 헤더와 함께 UDP 세그먼트에 캡슐화되어 전송된다.
** 계산하면, <code>20ms × 8,000 bytes/sec = 160 bytes</code>. 즉, 20ms마다 160바이트 UDP 세그먼트가 전송된다.
이 상황에서 수신자는 언제 청크를 재생할지, 누락된 청크에 대해서 어떻게 대응할지에 대해서 결정해야 한다. VoIP 애플리케이션에서 생성된 UDP 세그먼트는 IP 데이터그램으로 캡슐화되어 전송된다. 이 데이터그램은 전송 중에 라우터의 버퍼(큐)를 거치는데, 이 중 하나라도 버퍼가 가득 차 있다면, 해당 IP 데이터그램은 폐기(dropped)되고 수신자에게 도달하지 못한다. 하지만 패킷 손실은 생각보다 치명적이지 않을 수도 있는데, 실제로 VoIP 애플리케이션에서 1~20% 정도의 손실률은 허용 가능하며, 이는 음성의 인코딩 방식과, 패킷 손실을 은폐하는 기술에 따라 달라진다. 예를 들어 FEC(Forward Error Correction) 기법은 중복되는 정보를 담은 비트를 추가적으로 전송하여, 일부 손실된 데이터를 복구할 수 있다. 하지만 손실률이 10~20% 이상이거나 링크가 매우 혼잡하면 QoS를 더 이상 유지할 수 없다.
VoIP 애플리케이션에게는 종단 간 지연(end-to-end delay)도 매우 중요한 요소이며, 종단 간 지연은 다음의 총 합이다:
* transmission delay
* processing delay
* queueing delay
* propagation delay
* end-system processing delays
이때 VoIP 애플리케이션 기준으로, 150ms 미만의 지연은 사용자에게 감지되지 않으며, 150~400ms의 지연 시간은 받아들일 수 있는 수준의 지연시간이다. 또한 400ms 이상의 지연 시간은 현실적으로 대화가 더 이상 불가능한 수준이다. 이에 따라 수신 측은 보통 400ms 초과된 패킷은 무시하며, 이는 결과적으로 패킷 손실과 유사하다.
지연 시간에 대해 특히 고려해야 하는 것은 jitter이며, 이는 패킷 간 도착 간격의 불규칙성을 의미한다. 예를 들어 송신자는 20ms 간격으로 패킷 전송을 하지만, 수신 시점의 간격은 20ms보다 크거나 작을 수 있다는 것이다. 예를 들어 첫 패킷이 라우터의 거의 빈 큐에 도착하고, 두 번째 패킷은 도착 후 다른 패킷들과 겹친다면, 두 패킷은 20ms 간격으로 전송됐지만, 실제 수신 간격은 20ms보다 더 길어진다. 이 경우 오디오가 끊기거나 느려진 느낌을 줄 수 있다.<br>
반대로 첫 번째 패킷은 라우터의 큐 뒤쪽에 도착해서 오래 기다리고, 두 번째 패킷은 거의 곧바로 뒤따라 도착해서 바로 처리된다면 실제 수신 간격은 20ms보다 짧아진다. 이 경우 음성이 너무 빨리 나와 들리기도 전에 다음 소리가 덮을 수 있다. 따라서 jitter를 완화하는 것이 QoS를 위해서 필요하다.
=== Removing Jitter at the Receiver for Audio ===


==각주==
==각주==
[[분류:컴퓨터 네트워크]]
[[분류:컴퓨터 네트워크]]

2025년 6월 15일 (일) 15:10 판

상위 문서: 컴퓨터 네트워크

개요

현재 전 세계의 대부분의 사람들은 인터넷을 이용하여 여러 멀티 미디어 건텐츠에 접근할 뿐만 아니라, 동영상과 오디오등을 인터넷에 업로드하기도 한다. 이렇듯, 멀티미디어 컨텐츠는 인터넷의 중요한 구성 요소가 되어가고 있다. 해당 문서에서는 이러한 멀티미디어 서비스를 제공하는 멀티미디어 애플리케이션의 분류 체계와, 기존 애플리케이션과의 차이점에 대해 다룬다. 또한 이를 구현하기 위한 여러 기술 들과 기법에 대해 다룬다.

Multimedia Networking Applications

멀티미디어 네트워크 애플리케이션이란 오디오나 비디오를 사용하는 모든 네트워크 애플리케이션을 의미한다.

Properties of Video

비디오란 이미지들의 연속이며, 여러 이미지들이 동일한 속도로 표시되는 것이다. 예를 들어 24 images/sec(24fps)란 초당 24장의 정지 이미지로 전송되는 비디오 품질을 의미한다. 또한 디지털 이미지란 픽셀 배열이며, 각각의 픽셀은 비트로 표시된다. 예를 들어 RGB 픽셀은 24비트로 표현 가능하다.

비디오의 가장 큰 특징은 높은 비트 전송률(bit rate)를 요규한다는 것이다. 화상 회의는 적어도 100kbps의 전송률을 요구하며, 고화질 영상 스트리밍 서비스는 3Mbps 이상의 전송률을 요구한다. 비디오의 또다른 특징은 압축이 가능하다는 것이며, 이를 통해 영상 품질과 비트 전송률 사이의 절충(trade-off)를 택할 수 있다. 이렇게 멀티미디어의 데이터를 압축하고 디지털 형식으로 변환하는 과정을 인코딩(encoding)이라고 한다.

압축을 할 때 중요한 것은 중복(redundancy)를 활용하는 것으로 이는 공간적 중복(spatial redundancy)와 시간적 중복(temporal redundancy)로 구분된다. 공간적 중복은 이미지 내부에서 반복되는 색상, 패턴들을 의미하며, 시간적 중복은 연속된 프레임에서 중복되는 프레임을 의미한다. 보라색 픽셀이 하나의 프레임 내에서 중복된다고 할 때, 각 픽셀의 색 정보를 N번 전송하는 대신 공간적 중복을 활용하여 보라색 + 반복 횟수: N만을 전송하면 된다. 또한 시간적 중복을 활용한다면 연속된 프레임(frame i와 frame i+1) 사이의 차이만 전송하여, 전체 프레임을 다 보내지 않고, 변화된 부분만 보내는 방식이다.

동영상의 비트레이트는 CBR(Constant Bit Rate)와 VBR(Variable Bit Rate)로 나뉜다. CBR은 고정 전송률로 비디오를 전송하는 방식이다. 즉, 매 초마다 동일한 양의 데이터를 사용해서 비디오를 압축하는 방식이다. 인코딩 속도가 일정하여 비교적 예측가능하며, 이에 따라 일정한 네트워크 대역폭을 요구한다는 장점이 있다. 하지만 모든 프레임에 동일한 비트 수를 사용하므로, 동적인 화면과 같이 압축이 어려운 프레임에 대해서는 영상의 품질이 떨어질 수 있다는 단점이 있다.
VBR이란 가변 전송률로 비디오를 전송하는 방식이다. 즉, 프레임 간의 변화나 복잡도에 따라 인코딩 속도가 달라지는 방식이다. 이에 따라 장면의 복잡도에 따라 적절한 전송률을 사용하여 비디오 서비스의 품질을 일정하게 유지할 수 있다는 장점이 있다. 하지만 요구되는 네트워크 대역폭의 요구량이 일정하지 않다는 단점이 있다.

Properties of Audio

Figure 1. Multimedia: audio
Figure 1. Multimedia: audio

실제의 소리는 연속적인 파동 형태의 아날로그 신호이다. 따라서 디지털 전송을 위해서는 이를 아래와 같은 과정을 통해 디지털 신호로 변환하여야 한다:

  1. 아날로그 오디오 신호는 일정한 속도로 샘플링(sampling)된다.
    • 샘플링이란, 일정 시간 마다 소리의 세기를 측정하는 것이다.
    • 예를 들어, 전화는 초당 8000번의 샘플링을, CD에 저장된 음악은 초당 44100번의 샘플링을 요구한다.
  2. 샘플링하여 측정된 소리의 세기는 어떤 유한한 값 중 하나로 반올림(quantized)되며, 이 과정을 양자화(quantization)이라고 한다.
    • 예를 들어 8비트 사용시, 가능한 양자화 값은 256개이다.
    • 이 과정에서 원래의 값과 차이가 생기는데, 이를 양자화 오차(quantization error)라고 한다.
  3. 모든 샘플의 비트 표현은 이에 해당하는 디지털 신호가 된다.

이러한 과정은 figure 1을 통해서 더욱 잘 이해할 수 있다. 또한 이를 통해서 오디어의 전송률을 계산할 수 있는데, 예를 들어 초당 8000번의 샘플링이 진행되고, 256개의 양자화 값이 존재할 때, 해당 오디오의 전송률은 log2256bits/sample x 8000samples/sec = 64000bps(64kbps)가 된다. 오디오 스피커를 통해 이를 다시 재생하기 위해서는 수신자가 해당 디지털 신호를 다시 아날로그 신호로 변환해야 한다. 하지만 이것은 원래 신호의 근사치일 뿐이며, 원래의 아날로그 신호에 더 가까워지기 위해서는 샘플링 속도 혹은 양자화 값의 수를 늘려야 한다. 즉, 비디오와 마찬가지로 QoS와 비트 전송률 간의 절충(trade off) 관계가 있다.

Types of Multimedia Network Application

인터넷은 여러 가지 유형의 멀티미디어 애플리케이션을 지원하며, 이는 크게 세 가지 범주로 나뉜다:

  • 저장된 오디오/비디오 스트리밍(Streaming Stored Audio and Video)
  • IP 기반의 음성/영상 통화(Conversational Voice- and Video-over-IP)
  • 실시간 오디오/비디오 스트리밍(Streaming Live Audio and Video)

먼저, 저장된 오디오/비디오 스트리밍에 대해 논의하자. 이때 해당 문서에서는 저장된 비디오 스트리밍 애플리케이션에 대해서 집중하여 서술한다. 저장된 오디오 스트리밍(예: Spotify의 음악 스트리밍 서비스)은 저장된 비디오 스트리밍과 매우 유사하지만, 일반적으로 비트 전송률이 훨씬 낮을 뿐이다. 이 범주의 애플리케이션에서, 전송하는 매체는 미리 녹화되어 서버에 저장되어 있는 비디오이다. 이때 저장된 비디오 스트리밍 애플리케이션에는 다음과 같은 세 가지 특징이 있다:

  1. 스트리밍(Streaming): 저장된 비디오 스트리밍 애플리케이션에서는 클라이언트가 서버로부터 비디오를 받고 몇 초 내에 재생을 시작한다. 즉, 클라이언트는 비디오의 한 지점을 재생하는 동시에, 서버로부터 이후의 부분을 받는다. 이 기법을 스트리밍이라고 하며, 이는 전체의 비디오 파일을 먼저 다운로드하고 재생하는 방식보다 더욱 빠른 재생을 가능하게 한다.
  2. 상호작용성(Interactivity): 미디어는 사전에 녹화된 것이며, 이에 따라 사용자는 비디오를 일시 정지하거나, 앞으로 또는 뒤로 이동하거나, 빨리 감기 등을 할 수 있어야 한다. 또한 해당 동작을 클라리언트가 요구했을 때, 그 반응 시간은 매우 짧아야 한다.
  3. 연속 재생(Continuous playout): 생이 시작되면, 비디오는 원래 녹화된 타이밍에 맞춰 계속 재생되어야 한다. 따라서 데이터는 클라이언트가 재생하기 전에 적시에 서버로부터 도착해야 하며, 그렇지 않으면 QoS는 프레임 정지/건너뜀 등의 현상으로 악화된다.

이러한 스트리밍 서비스에서 가장 중요한 성능 지표는 처리량(throughput)이다. 이는 연속적인 재생을 보장하기 위해서는 네트워크가 해당 비디오의 비트 전송률보다 높은 처리량을 제공해야 하기 때문이다.

그리고, IP 기반 음성/영상 통화에 대해서 논의하자. IP 기반의 음성 통화는 사용자의 관점에서 전통적인 circuit-switching 전화 서비스와 유사하여 종종 인터넷 전화라고도 불린다. 또한 VoIP(Voice-over-IP)로도 알려져 있다. 영상 통화는 음성에 더하여 참여자의 영상도 포함된다는 점에서만 구분된다. 이때 VoIP에서 중요한 특성 두가지는 아래와 같다:

  • timing consideration: 약간의 지연만 생겨도 사용자는 불편을 느끼므로 음성/영상 애플리케이션은 지연에 매우 민감하다. 이는 delay tolerance가 매우 낮다는 말로 표현되기도 한다.
  • loss-tolerant: 데이터 손실에 비교적 관대하여, 데이터의 완전성과 무결성이 상대적으로 중요하지 않다는 의미이다.

마지막으로 실시간 오디오/비디오 스트리밍에 대해 논의하자. 실시간 오디오/비디오 스트리밍 서비스는 전통적인 라디오/TV 방송과 유사하지만, 전송이 인터넷을 통해서 이루어진다는 점에서 차이가 있다. 이들 애플리케이션은 사용자의 위치에 상관없이 생방송을 시청할 수 있게 한다. 해당 애플리케이션은 보통 동일한 프로그램을 동시에 여러 사용자에게 전송한다. 오늘날 인터넷에서는 보통 CDN을 이용해 이를 수행한다. 저장된 오디오/비디오 스티리밍과 마찬가지로, 네트워크는 실시간 멀티미디어 흐름마다 비디오 소비 속도보다 높은 평균 처리량을 제공해야 한다.

Streaming Stored Video

자세한 내용은 Streaming Stored Video 문서를 참조해주십시오.

VoIP

인터넷을 통한 실시간 음성 대화는 종종 인터넷 전화(Internet telephony)라고 불리는데, 사용자 관점에서는 전통적인 회선 교환 전화 서비스와 유사하기 때문이다. 또한 실시간 음성 대화는 일반적으로 VoIP(Voice-over-IP)라고 불린다. 화상 대화(conversational video)는 VoIP와 많은 면에서 유사하지만, 음성뿐 아니라 참가자의 영상도 포함된다는 점에서 차이가 있다.

Limitations of the Best-Effort IP Service

IP(Internet Protocol)는 Best-Effort 서비스를 제공한다. 즉, IP는 각 데이터그램을 출발지에서 목적지로 가능한 한 빨리 전송하려고 노력하지만, 지연 시간이나 패킷 손실 등에 대한 보장은 하지 않는다. 이는 큰 문제가 될 수 있는데, VoIP 애플리케이션은 지연(delay), 지터(jitter), 손실(loss)에 매우 민감하기 때문이다. 이때 VoIP 애플리케이션이 reliable data transfer를 위해서 TCP를 사용하지 않는 이유는 TCP의 재전송 메커니즘이 end system 사이의 지연을 증가시키기 때문이다. 또한 TCP의 혼잡 제어는 패킷 손실이 발생했을 때 전송 속도를 낮추므로 수신 속도보다 송신 속도가 느려질 수 있고, 이에 따라 버퍼 고갈(buffer starvation)이 발생하여 수신자 측에서 음성 이해 가능성(intelligibility)이 심각하게 저하될 수 있다. 이에 따라 대부분의 VoIP 애플리케이션은 기본적으로 UDP를 사용한다.

해당 문단에서는 best-effort 네트워크 환경에서도 application layer에서 VoIP 성능을 향상시킬 수 있는 방법들을 다룬다. 이에 대한 논의를 구체적으로 하기 위해서, 다음의 VoIP 예시를 사용한다:

  • 송신자는 초당 8,000 바이트를 생성한다.
  • 송신자는 20ms마다 바이트들을 모아 하나의 청크로 만든다.
  • 이 chunk는 특수 헤더와 함께 UDP 세그먼트에 캡슐화되어 전송된다.
    • 계산하면, 20ms × 8,000 bytes/sec = 160 bytes. 즉, 20ms마다 160바이트 UDP 세그먼트가 전송된다.

이 상황에서 수신자는 언제 청크를 재생할지, 누락된 청크에 대해서 어떻게 대응할지에 대해서 결정해야 한다. VoIP 애플리케이션에서 생성된 UDP 세그먼트는 IP 데이터그램으로 캡슐화되어 전송된다. 이 데이터그램은 전송 중에 라우터의 버퍼(큐)를 거치는데, 이 중 하나라도 버퍼가 가득 차 있다면, 해당 IP 데이터그램은 폐기(dropped)되고 수신자에게 도달하지 못한다. 하지만 패킷 손실은 생각보다 치명적이지 않을 수도 있는데, 실제로 VoIP 애플리케이션에서 1~20% 정도의 손실률은 허용 가능하며, 이는 음성의 인코딩 방식과, 패킷 손실을 은폐하는 기술에 따라 달라진다. 예를 들어 FEC(Forward Error Correction) 기법은 중복되는 정보를 담은 비트를 추가적으로 전송하여, 일부 손실된 데이터를 복구할 수 있다. 하지만 손실률이 10~20% 이상이거나 링크가 매우 혼잡하면 QoS를 더 이상 유지할 수 없다.

VoIP 애플리케이션에게는 종단 간 지연(end-to-end delay)도 매우 중요한 요소이며, 종단 간 지연은 다음의 총 합이다:

  • transmission delay
  • processing delay
  • queueing delay
  • propagation delay
  • end-system processing delays

이때 VoIP 애플리케이션 기준으로, 150ms 미만의 지연은 사용자에게 감지되지 않으며, 150~400ms의 지연 시간은 받아들일 수 있는 수준의 지연시간이다. 또한 400ms 이상의 지연 시간은 현실적으로 대화가 더 이상 불가능한 수준이다. 이에 따라 수신 측은 보통 400ms 초과된 패킷은 무시하며, 이는 결과적으로 패킷 손실과 유사하다.

지연 시간에 대해 특히 고려해야 하는 것은 jitter이며, 이는 패킷 간 도착 간격의 불규칙성을 의미한다. 예를 들어 송신자는 20ms 간격으로 패킷 전송을 하지만, 수신 시점의 간격은 20ms보다 크거나 작을 수 있다는 것이다. 예를 들어 첫 패킷이 라우터의 거의 빈 큐에 도착하고, 두 번째 패킷은 도착 후 다른 패킷들과 겹친다면, 두 패킷은 20ms 간격으로 전송됐지만, 실제 수신 간격은 20ms보다 더 길어진다. 이 경우 오디오가 끊기거나 느려진 느낌을 줄 수 있다.
반대로 첫 번째 패킷은 라우터의 큐 뒤쪽에 도착해서 오래 기다리고, 두 번째 패킷은 거의 곧바로 뒤따라 도착해서 바로 처리된다면 실제 수신 간격은 20ms보다 짧아진다. 이 경우 음성이 너무 빨리 나와 들리기도 전에 다음 소리가 덮을 수 있다. 따라서 jitter를 완화하는 것이 QoS를 위해서 필요하다.

Removing Jitter at the Receiver for Audio

각주