실시간 통신 (1) - RTP와 실시간 전송 - soo:bak

작성일 : 2026년 01월 20일

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

화상 통화, 음성 통화, 라이브 스트리밍 같은 실시간 애플리케이션은 웹 페이지 로딩이나 파일 다운로드와 다른 요구사항을 갖습니다.

소켓과 전송 계층 시리즈에서 TCP가 신뢰성을 보장하는 원리를 살펴보았습니다. 패킷이 손실되면 재전송하고, 순서가 바뀌면 정렬합니다.

음성 통화 중에 0.5초 전 패킷이 뒤늦게 재전송되어 온다면 어떨까요? 대화는 이미 지나갔고, 늦게 도착한 패킷은 쓸모가 없습니다. 재전송을 기다리는 동안 생긴 지연이 오히려 통화 품질을 떨어뜨립니다.

실시간 미디어에서는 완벽한 전달보다 시간 내 전달이 더 중요합니다. TCP와 다른 전용 프로토콜이 필요한 이유입니다.

실시간 통신의 요구사항

낮은 지연 (Low Latency)

편도 지연이 150ms를 넘으면 대화가 어색해집니다. ITU-T G.114는 지연과 통화 품질의 관계를 세 구간으로 나눕니다.

대화 품질과 편도 지연 (ITU-T G.114):
0-150ms:    우수 (대부분 사용자가 감지 안 함)
150-400ms:  수용 가능 (에코 제어 필요)
400ms+:     대화 어려움

일정한 간격 (Low Jitter)

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

이상적:
패킷 1 ──────────────► t=0ms
패킷 2 ──────────────► t=20ms
패킷 3 ──────────────► t=40ms

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

Jitter가 크면 수신 측 버퍼에 패킷이 너무 빨리 쌓이거나 비게 됩니다. 재생이 끊기거나 품질이 저하될 수 있습니다.

손실 허용 (Loss Tolerance)

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

TCP는 패킷 하나라도 빠지면 재전송으로 복구합니다. 하지만 음성 통화에서 20ms짜리 음성 조각 하나가 빠져도 사람의 귀는 거의 인지하지 못합니다. 영상에서도 한두 프레임이 빠지면 잠깐 화면이 흐려질 뿐입니다. 재전송을 기다리며 전체가 멈추는 것보다 낫습니다.

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

TCP가 부적합한 이유

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

재전송 지연

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

시간
 │
 │  패킷 1 전송 ─────►
 │  패킷 2 전송 ─────►  (손실!)
 │  패킷 3 전송 ─────►
 │
 │  ACK 1 수신 ◄─────
 │
 │  (타임아웃 대기...)
 │
 │  패킷 2 재전송 ─────►
 │
 │  ACK 2, 3 수신 ◄─────
 │
 ▼

재전송을 기다리는 동안:

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

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

Head-of-Line Blocking

TCP는 순서를 보장하기 때문에, 패킷 2가 손실되면 패킷 3, 4, 5도 애플리케이션에 전달되지 못합니다.

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

하지만 실시간 미디어에서는 패킷 3, 4, 5를 먼저 처리하는 쪽이 낫습니다.

혼잡 제어의 문제

TCP의 혼잡 제어는 패킷 손실을 네트워크 혼잡 신호로 해석하여 전송률을 절반으로 줄입니다. 일반 데이터 전송에서는 합리적인 전략이나, 실시간 미디어는 일정한 비트레이트를 유지해야 자연스럽게 재생할 수 있습니다.

일시적 손실에도 전송률이 절반으로 줄어들고, 회복에 수 초가 걸립니다. TCP로 영상을 전송한다면 해상도가 급격히 떨어졌다 서서히 회복되는 현상이 반복됩니다.

RTP (Real-time Transport Protocol)

TCP의 재전송, 순서 보장, 혼잡 제어가 실시간 미디어에 오히려 방해가 된다면, 어떤 프로토콜을 써야 할까요?

RTP는 RFC 3550에 정의된 프로토콜로, UDP 위에서 동작하며 실시간 미디어 전송에 적합하게 설계되었습니다.

RTP의 역할

RTP는 미디어 데이터와 함께, 수신 측이 올바른 타이밍과 순서로 재생하는 데 필요한 메타데이터를 전달합니다. 다만 TCP처럼 손실을 복구하거나 품질을 보장하지는 않습니다. 손실 대응 전략은 애플리케이션이 상황에 맞게 결정합니다.

RTP가 제공하는 것:

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

RTP가 제공하지 않는 것:

신뢰성 (재전송 없음)
순서 보장 (시퀀스 번호로 정렬은 가능)
QoS(Quality of Service, 서비스 품질) 보장

RTP는 미디어 전송에 필요한 정보를 제공하는 프레임워크이며, 손실과 Jitter에 대한 구체적인 대응은 애플리케이션의 몫입니다.

RTP 헤더 구조

 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             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

UDP 헤더 8바이트를 더하면 전송 계층 오버헤드는 20바이트가 됩니다. 여기에 IP 헤더 20바이트까지 포함하면 총 40바이트로, TCP/IP(40바이트)와 크기는 같습니다.

다만 RTP/UDP/IP는 재전송·순서 보장·혼잡 제어를 수행하지 않고, 실시간 재생에 필요한 타이밍과 순서 정보만 담습니다.

각 필드가 어떤 역할을 하는지 살펴봅니다.

RTP 헤더 필드

Sequence Number (16비트)

각 패킷의 순서를 식별합니다.

수신 측은 이 번호로 패킷 손실과 순서 이상을 감지하고, 재생 품질 유지 여부를 판단합니다. 시퀀스 번호 100 다음에 102가 도착하면 101번 패킷이 손실되었음을 바로 알 수 있습니다.

용도:

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

초기값은 무작위로 정합니다. 0처럼 고정된 값에서 시작하면 공격자가 다음 번호를 예측하여 위조 패킷을 끼워넣을 수 있기 때문입니다.

Timestamp (32비트)

마이크는 소리를 초당 수천 번 디지털 값으로 변환합니다. 이 샘플링(Sampling) 과정에서 각 샘플이 만들어진 시점이 곧 타임스탬프입니다.

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

타임스탬프는 패킷이 네트워크에 도착한 시간과는 무관합니다. “이 미디어가 언제 생성되었는가”를 나타내므로, 수신 측은 네트워크 지연에 관계없이 원래의 재생 간격을 복원할 수 있습니다. 화상 회의에서 오디오와 비디오의 입술 싱크가 맞는 것도 이 타임스탬프가 있기에 가능합니다.

용도:

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

SSRC (32비트)

Synchronization Source 식별자로, 각 미디어 스트림을 고유하게 구분합니다. 중앙 서버가 번호를 배정하지 않으므로, 각 참가자가 무작위로 32비트 값을 생성하여 충돌 가능성을 최소화합니다.

화상 회의:
SSRC 0x12345678: A의 오디오
SSRC 0xABCDEF00: A의 비디오
SSRC 0x87654321: B의 오디오
SSRC 0x00FEDCBA: B의 비디오

CSRC (가변)

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

믹서:
A 오디오 + B 오디오 → 믹스된 오디오
CSRC 리스트: [A SSRC, B SSRC]

Payload Type (7비트)

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

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

동적 할당은 SDP(Session Description Protocol)에서 정의:
a=rtpmap:96 opus/48000/2

RTCP (RTP Control Protocol)

RTP는 미디어를 전송하지만, 상대방이 제대로 수신하고 있는지는 알 수 없습니다. 패킷 손실 여부, Jitter 수준, 비트레이트 조정 필요성 — 이런 피드백 없이는 품질 관리가 불가능합니다.

RTCP는 RTP의 제어 프로토콜로, 품질 피드백과 참가자 정보를 교환하고 세션의 시작과 종료를 관리합니다. 일반적으로 RTP 포트 + 1번 포트를 사용합니다 (예: RTP 5004, RTCP 5005).

RTCP 패킷 유형

SR (Sender Report)

송신자가 보내는 보고서입니다. NTP 타임스탬프(절대 시간), RTP 타임스탬프(상대 시간), 송신 패킷/바이트 수를 담고 있으며, 오디오/비디오 동기화에 활용됩니다.

RR (Receiver Report)

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

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

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)

소스에 대한 설명 정보를 전달합니다.

SSRC 값만으로는 참가자가 누구인지 알 수 없으므로, SDES가 부가 정보를 제공합니다. 그중 CNAME(Canonical Name)은 동일한 소스를 일관되게 식별하는 필수 항목입니다.

CNAME 외에도 사용자 이름(NAME), 이메일(EMAIL), 애플리케이션 이름(TOOL) 등을 포함할 수 있습니다.

BYE

세션 종료를 알리는 패킷입니다. 참가자가 통화에서 나가면 BYE 패킷을 보내, 다른 참가자들이 해당 SSRC 스트림의 의도적 종료를 인지할 수 있게 합니다. BYE 없이 스트림이 끊기면 수신 측은 네트워크 장애인지 퇴장인지 구분할 수 없습니다.

APP

애플리케이션 고유 데이터를 전송하는 패킷입니다. 표준 RTCP 패킷 유형으로 표현할 수 없는 제어 정보(예: 화면 공유 상태 변경, 커스텀 품질 지표)를 교환할 때 쓰입니다.

RTT 측정

SR과 RR에 담긴 타임스탬프 정보를 조합하면 두 참가자 사이의 왕복 시간(RTT)을 측정할 수 있습니다.

송신자 A                          수신자 B
    │                                 │
    │ ─── SR (NTP 타임스탬프 T1) ──► │
    │                                 │ T1을 기억 (= LSR)
    │                                 │ (처리 시간 DLSR)
    │                                 │
    │ ◄─── RR (LSR, DLSR) ────────  │
    │                                 │
    │     T2 = 현재 시간               │
    │     RTT = T2 - LSR - DLSR      │

A는 SR에 자신의 NTP 타임스탬프(T1)를 담아 보냅니다. B는 이 값을 기억해 두었다가(LSR, Last SR), RR에 LSR과 자신의 처리 시간(DLSR)을 담아 돌려보냅니다. A는 RR을 받은 현재 시각(T2)에서 LSR과 DLSR을 빼면 순수 네트워크 왕복 시간을 구할 수 있습니다. 이 RTT 값은 적응형 비트레이트 조절이나 Jitter Buffer 크기 결정에 활용됩니다.

마무리: RTP는 기반이다

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

RTP가 제공하는 것	RTP가 제공하지 않는 것
타이밍 정보 (Timestamp)	신뢰성
순서 정보 (Sequence Number)	QoS 보장
소스 식별 (SSRC)	암호화 (SRTP로 별도 처리)
품질 피드백 (RTCP)

RTP가 “어떻게 보낼 것인가”의 틀을 제공한다면, “무엇을 보정하고, 어떻게 적응할 것인가”는 애플리케이션이 직접 해결해야 합니다.

브라우저에서 별도 플러그인 없이 RTP 기반 실시간 통신을 하려면, 시그널링과 NAT 통과, 암호화까지 브라우저 수준에서 처리해야 합니다.

Part 2에서는 WebRTC가 브라우저에서 P2P 통신을 구현하는 과정을 살펴봅니다. ICE를 통한 NAT 통과, DTLS-SRTP를 통한 암호화, SDP를 통한 미디어 협상을 다룹니다.

관련 글

소켓과 전송 계층 (1) - 소켓의 개념과 5-tuple

시리즈

실시간 통신 (1) - RTP와 실시간 전송 (현재 글)
실시간 통신 (2) - WebRTC 스택
실시간 통신 (3) - 품질 관리와 적응