작성일 :

실시간 미디어는 어떻게 전송되는가

화상 통화, 음성 통화, 라이브 스트리밍과 같은 실시간 애플리케이션은 일반 웹과 다른 요구사항을 갖습니다.


실시간 통신의 요구사항

낮은 지연 (Low Latency)

대화에서 지연이 150ms를 넘으면 불편합니다.


1
2
3
4
5
대화 품질과 지연:
0-150ms:    우수 (감지 안 됨)
150-300ms:  수용 가능
300-500ms:  눈에 띄는 지연
500ms+:     대화 어려움


일정한 간격 (Low Jitter)

Jitter는 패킷 도착 시간의 변동을 의미합니다.


1
2
3
4
5
6
7
8
9
이상적:
패킷 1 ──────────────► t=0ms
패킷 2 ──────────────► t=20ms
패킷 3 ──────────────► t=40ms

실제 (Jitter 있음):
패킷 1 ──────────────► t=0ms
패킷 2 ──────────────► t=25ms (+5ms 지터)
패킷 3 ──────────────► t=35ms (-5ms 지터)


Jitter가 크면 재생이 끊기거나 품질이 저하됩니다.


손실 허용 (Loss Tolerance)

실시간 미디어에서는 일부 패킷 손실을 감수합니다.


  • 음성: 1-5% 손실까지 수용 가능
  • 영상: 프레임 일부 손실 시 품질 저하
  • 완벽한 전달보다 적시 전달이 중요

TCP가 부적합한 이유

TCP는 신뢰성 있는 전송을 제공하지만, 실시간 통신에는 오히려 문제가 됩니다.


재전송 지연

패킷이 손실되면 TCP는 재전송을 시도합니다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
시간
 │
 │  패킷 1 전송 ─────►
 │  패킷 2 전송 ─────►  (손실!)
 │  패킷 3 전송 ─────►
 │
 │  ACK 1 수신 ◄─────
 │
 │  (타임아웃 대기...)
 │
 │  패킷 2 재전송 ─────►
 │
 │  ACK 2, 3 수신 ◄─────
 │
 ▼


재전송을 기다리는 동안:

  • 음성: 무음 구간 발생
  • 영상: 프레임 정지


재전송된 패킷이 도착할 때쯤이면 이미 재생 시점이 지나 무의미해집니다.


Head-of-Line Blocking

TCP는 순서를 보장하므로, 패킷 2가 손실되면 패킷 3, 4, 5도 애플리케이션에 전달되지 않습니다.


1
2
3
4
5
6
버퍼:
패킷 1: 전달됨
패킷 2: 손실 (대기 중)
패킷 3: 대기 (2번 때문에)
패킷 4: 대기 (2번 때문에)
패킷 5: 대기 (2번 때문에)


그러나 실시간 미디어에서는 패킷 3, 4, 5를 먼저 처리하는 편이 나을 수 있습니다.


혼잡 제어의 문제

TCP 혼잡 제어는 손실이 발생하면 전송 속도를 줄입니다.


실시간 미디어에서:

  • 비트레이트가 급격히 변동
  • 품질 불안정
  • 미디어 특성을 고려하지 않음

RTP (Real-time Transport Protocol)

RTP는 RFC 3550으로 정의된 프로토콜로, UDP 위에서 동작하며 실시간 미디어 전송에 최적화되어 있습니다.


RTP의 역할

RTP가 제공하는 것:

  • 타임스탬프
  • 시퀀스 번호
  • 페이로드 타입 식별
  • 소스 식별


RTP가 제공하지 않는 것:

  • 신뢰성 (재전송 없음)
  • 순서 보장 (시퀀스 번호로 정렬은 가능)
  • QoS 보장


RTP는 프레임워크로서, 손실과 Jitter에 대응하는 방법은 애플리케이션이 결정합니다.


RTP 헤더 구조

1
2
3
4
5
6
7
8
9
10
11
12
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Synchronization Source (SSRC) Identifier            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Contributing Source (CSRC) Identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


최소 12바이트 헤더입니다.


RTP 헤더 필드

Sequence Number (16비트)

각 패킷의 순서를 식별하는 데 사용됩니다.


용도:

  • 손실 감지: 번호가 건너뛰면 손실
  • 순서 복원: 도착 순서와 무관하게 재정렬
  • 중복 제거: 같은 번호 패킷 폐기


보안을 위해 초기값은 무작위로 설정됩니다.


Timestamp (32비트)

미디어가 샘플링된 시점을 나타내며, 패킷이 네트워크에 도착한 시간과는 무관합니다.


1
2
3
4
오디오 (8kHz 샘플링):
패킷 1: timestamp = 0     (0ms)
패킷 2: timestamp = 160   (20ms, 160샘플 후)
패킷 3: timestamp = 320   (40ms)


용도:

  • 재생 타이밍 결정
  • Jitter 보상
  • 오디오/비디오 동기화


SSRC (32비트)

Synchronization Source 식별자로, 각 미디어 스트림을 고유하게 식별하며 무작위로 생성됩니다.


1
2
3
4
5
화상 회의:
SSRC 0x12345678: Alice의 오디오
SSRC 0xABCDEF00: Alice의 비디오
SSRC 0x87654321: Bob의 오디오
SSRC 0x00FEDCBA: Bob의 비디오


CSRC (가변)

Contributing Source 식별자로, 믹서가 여러 소스를 합칠 때 원본 소스들을 표시합니다.


1
2
3
믹서:
Alice 오디오 + Bob 오디오 → 믹스된 오디오
CSRC 리스트: [Alice SSRC, Bob SSRC]


Payload Type (7비트)

미디어 형식을 식별하는 필드입니다.


1
2
3
4
5
6
7
일부 표준 페이로드 타입:
0:  PCMU (G.711 μ-law)
8:  PCMA (G.711 A-law)
96-127: 동적 할당

동적 할당은 SDP에서 정의:
a=rtpmap:96 opus/48000/2

RTCP (RTP Control Protocol)

RTCP는 RTP의 제어 프로토콜로, 품질 피드백과 참가자 정보를 교환하는 역할을 합니다.


일반적으로 RTP 포트에 1을 더한 포트를 사용합니다 (예: RTP 5004, RTCP 5005).


RTCP 패킷 유형

SR (Sender Report)

송신자가 보내는 보고서로, NTP 타임스탬프(절대 시간), RTP 타임스탬프(상대 시간), 송신 패킷/바이트 수를 포함합니다.

이 정보는 오디오/비디오 동기화에 활용됩니다.


RR (Receiver Report)

수신자가 보내는 보고서로, 다음 정보를 포함합니다.

  • 손실 패킷 수
  • 손실률
  • 수신된 최대 시퀀스 번호
  • Jitter 추정치
  • 마지막 SR 이후 시간


1
2
3
4
5
6
7
8
Receiver Report 예시:
SSRC: 0x12345678 (보고 대상)
Fraction Lost: 2% (손실률)
Cumulative Lost: 150 (총 손실 패킷)
Extended Highest Seq: 5000 (최대 시퀀스)
Jitter: 15ms (지터)
LSR: 0x... (마지막 SR 타임스탬프)
DLSR: 100ms (SR 수신 후 경과 시간)


송신자는 이 피드백으로:

  • 품질 상태 파악
  • 비트레이트 조절
  • 문제 진단


SDES (Source Description)

소스에 대한 설명 정보를 담고 있습니다.


포함 가능 항목:

  • CNAME: 정식 이름 (필수)
  • NAME: 사용자 이름
  • EMAIL: 이메일
  • TOOL: 애플리케이션 이름


BYE

세션 종료를 상대방에게 알리는 패킷입니다.


APP

애플리케이션 고유의 데이터를 전송하는 데 사용됩니다.


RTT 측정

RTCP SR/RR을 이용하여 왕복 시간(RTT)을 측정할 수 있습니다.


1
2
3
4
5
6
7
8
9
10
11
송신자 A                          수신자 B
    │                                 │
    │ ─── SR (LSR = T1) ──────────► │
    │                                 │
    │                                 │ (처리 시간 DLSR)
    │                                 │
    │ ◄─── RR (LSR, DLSR) ────────  │
    │                                 │
    │     T2 = 현재 시간               │
    │                                 │
    │     RTT = T2 - LSR - DLSR      │

정리: RTP는 프레임워크다

RTP는 실시간 미디어 전송의 기반을 제공합니다.


제공하는 것:

  • 타이밍 정보 (Timestamp)
  • 순서 정보 (Sequence Number)
  • 소스 식별 (SSRC)
  • 품질 피드백 (RTCP)


제공하지 않는 것:

  • 신뢰성
  • QoS 보장
  • 암호화 (SRTP 사용)


애플리케이션은 RTP 위에 필요한 기능을 직접 구축해야 합니다.


Part 2에서는 WebRTC가 브라우저에서 어떻게 P2P 통신을 구현하는지 살펴봅니다.


관련 글

Tags: RTCP, RTP, VoIP, 네트워크, 스트리밍, 실시간

Categories: ,