451. RTP (Real-time Transport Protocol) - UDP 위에서 동작 (순서번호, 타임스탬프)

핵심 인사이트 (3줄 요약)

본질: RTP(Real-time Transport Protocol)는 통화나 실시간 영상을 보낼 때 굼벵이 같은 TCP를 버리고 엄청나게 빠른 UDP를 쓰긴 써야 하는데, UDP의 치명적 단점인 "패킷의 순서 뒤섞임"을 해결하기 위해 UDP 알맹이 속에 몰래 들어가 '타임스탬프'와 '순서 번호'를 매겨주는 실시간 전용 반쪽짜리(?) 전송 프로토콜이다.

UDP 위에서 기생하는 구조: RTP는 그 자체로 독립적인 4계층 프로토콜이 아니다. UDP라는 가벼운 박스를 빌려 쓴 다음, 그 안에 12바이트짜리 RTP 헤더를 하나 더 덧씌워서 **"야, 이 패킷은 15초에 찍힌 영상이고, 3번째 조각이야!"**라고 딱지만 붙여 애플리케이션으로 넘겨준다.

보장 없는 최선 (No QoS): 이름에 'Transport'가 들어가지만 TCP처럼 유실된 데이터를 재전송해주거나 속도를 제어(QoS)하는 기능은 1도 없다. 잃어버리면 쿨하게 버리고, 오직 도착한 패킷들을 화면에 "제시간(Timing)"에 "순서대로(Sequence)" 예쁘게 조립해 뿌려주는 역할에만 올인한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: IP 네트워크 상에서 오디오, 비디오 등의 실시간(Real-time) 데이터를 전송하기 위해 송수신 간의 동기화(시간 정보)와 데이터 순서를 제공하는 종단 간(End-to-End) 애플리케이션-전송 계층 프로토콜 (RFC 3550).
필요성: 화상 회의를 한다. TCP로 쏘자니 0.1초 늦은 입술 모양 패킷을 재전송받느라 화면이 멈춰버린다. "그냥 UDP로 냅다 던져!" 그런데 인터넷은 패킷 순서를 마구잡이로 뒤집어 놓는다. UDP로 1번, 2번, 3번 입술 모양을 쐈는데 도착은 3번, 1번, 2번으로 온다. 이대로 화면에 뿌리면 괴물이 탄생한다. "아니! UDP를 쓰되, 최소한 얘네가 몇 초에 녹화된 건지(시간표), 그리고 몇 번째 조각인지(번호표)만이라도 봉투에 좀 적어서 던지면 안 되냐? 그래야 받는 쪽 플레이어가 1, 2, 3번 순서대로 퍼즐을 맞출 거 아니야!"
💡 비유: RTP는 방송국의 **"생방송 필름 슬레이트(딱딱이)"**와 같습니다.
- 카메라맨(UDP)이 생방송 테이프 조각을 마구잡이로 방송국에 집어 던집니다.
- 그런데 테이프마다 **"이 씬은 12시 30분에 찍은 5번째 조각임(RTP 타임스탬프와 순서 번호)"**이라고 슬레이트 기록이 철저하게 붙어 있습니다.
- 방송국 편집실(수신자 플레이어)은 테이프가 뒤죽박죽 도착해도, 이 슬레이트 번호만 보고 순서대로 줄을 쫙 세워서(Jitter Buffer) 시청자에게 매끄러운 화면을 내보냅니다.

📢 섹션 요약 비유: RTP는 패스트푸드점의 **"주문 대기표 번호"**입니다. 종업원(UDP)이 햄버거를 무작위로 막 던져줘도, 손님들은 햄버거 포장지에 붙은 번호표(RTP)를 보고 자기가 먼저 시킨 게 맞는지 순서를 완벽하게 가려낼 수 있습니다.

Ⅱ. RTP의 헤더 구조와 시간 동기화 마법 (Deep Dive)

1. RTP의 12바이트 뼈대 구조

RTP는 보통 L4(전송)와 L7(애플리케이션) 사이의 **세션/표현 계층(L5/L6)**에 위치한다고 본다. 패킷의 구조는 [IP 헤더] -> [UDP 헤더] -> [RTP 헤더(12B)] -> [진짜 영상/음성 데이터] 순서로 샌드위치 된다.

Sequence Number (16비트): UDP는 번호표가 없지만 RTP가 이 칸에 번호를 채워준다. 100번이 오고 102번이 오면 수신자는 "아 101번이 중간에 터져 죽었네"라고 귀신같이 알아챈다. (재전송은 안 하고 그냥 101번 프레임을 빈 화면으로 뭉개고 102번을 튼다).
Timestamp (32비트) ★핵심: 영상이나 음성이 '녹음(샘플링)된 정확한 순간'의 시간표다. 이 타임스탬프 덕분에, 네트워크 지연으로 패킷들이 고무줄처럼 늘어지며 도착하더라도(Jitter 발생), 수신자의 플레이어(유튜브 등)가 원래 녹화된 시간 간격 그대로 화면에 촤라락 뿌려줄 수 있다.
Payload Type (7비트): 뱃속에 든 데이터가 MP3인지, H.264 영상인지, AAC인지 포맷을 명시한다. 수신자는 이걸 보고 코덱을 킨다.

2. 멀티캐스트의 단짝 친구

RTP는 본질적으로 1:1 과외(유니캐스트)보다 1:N 방송(멀티캐스트)을 위해 태어났다.

사내 방송을 할 때 서버는 UDP 껍데기에 RTP 번호표를 붙여서 멀티캐스트 주소(239.1.1.1)로 한 방에 쏜다.
전국에 있는 수백 대의 셋톱박스가 이 영상을 알아서 낚아채서 화면에 재생한다.

 ┌─────────────────────────────────────────────────────────────┐
 │                RTP와 Jitter Buffer(지터 버퍼)의 환상적인 콤비       │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 인터넷의 혼란 (Jitter) ]                                    │
 │   서버 발송:  ①(0.1초)  ②(0.2초)  ③(0.3초)                    │
 │   PC 도착:    ①(0.5초) ........ ②, ③(0.9초에 동시 도착!)        │
 │   (네트워크 렉 때문에 2, 3번이 한꺼번에 훅 들어옴)                   │
 │                                                             │
 │   [ 수신자 플레이어의 지터 버퍼 (Jitter Buffer) ]                 │
 │   - 도착한 패킷을 화면에 바로 뿌리지 않고 0.3초 정도 "버퍼에 가둬둠".   │
 │   - RTP 타임스탬프를 읽어봄. "아 2번은 0.2초짜리네, 3번은 0.3초짜리네" │
 │   - 가둬둔 패킷을 버퍼에서 뺄 때, 원래 타임스탬프 간격(0.1초)에 맞춰   │
 │     일정하고 부드럽게 화면에 튕겨냄!                              │
 │                                                             │
 │   ▶ 결과: "인터넷이 널뛰기(Jitter)를 쳐도 사용자는 렉을 거의 못 느낀다!" │
 └─────────────────────────────────────────────────────────────┘

3. 포트 번호의 짝짜꿍 룰 (짝수 포트)

실무에서 방화벽 룰을 짤 때 알아둬야 할 팁이다. RTP는 자기가 쓸 UDP 포트를 고를 때 무조건 **'짝수' 번호(예: 50000번)**를 고른다. 그리고 다음 장에서 배울 자신의 단짝 친구이자 감시자인 RTCP에게는 무조건 **'그다음 홀수' 번호(50001번)**를 배정하여 항상 둘이 손을 잡고 다니게 만든다.

📢 섹션 요약 비유: RTP 헤더는 마구잡이로 날아오는 영상 조각들에 붙여진 **"이케아(IKEA) 가구 조립 설명서 스티커"**입니다. 부품(패킷)이 박스 속에서 이리저리 섞여 있어도, 설명서 스티커(순서와 타임스탬프)만 꼼꼼히 확인하면 누구나 완벽한 가구를 순서대로 조립해 낼 수 있습니다.