UDP & Real-time Communication

1. Overview

UDP와 실시간 통신(UDP & Real-time Communication)은 데이터 무결성(TCP)을 위해 지불해야 했던 3-Way Handshake와 재전송(Retransmission)이라는 족쇄를 완전히 박살 내고, 깎여나갈지언정 멈추지 않는 초저지연(Ultra-Low Latency) 스트리밍의 세계를 해부합니다.

학습자는 연결 수립도 없고 확인증(ACK)도 없는, 미친 듯이 데이터를 쏴대는 **UDP(User Datagram Protocol)**의 뼈대를 뜯어봅니다. 나아가 화상 회의(Zoom)나 FPS 게임(Valorant)처럼 프레임 1개가 유실되었다고 전체 화면을 멈추는(Head-of-Line Blocking) TCP의 끔찍한 병목을 UDP로 어떻게 우회하는지 설계의 당위성을 장악합니다. 마지막으로, 브라우저끼리 중간 서버 없이 직접 영상과 음성을 밀어 넣는 WebRTC 마법과, 이를 방해하는 공유기(NAT)의 장벽을 구멍(Hole Punching) 내어 뚫어버리는 TURN/STUN 릴레이 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• UDP Core Mechanics: Connectionless, No Retransmission, No Congestion Control, Header Structure.
• Real-time Use Cases: VoIP, Video Streaming, Multiplayer FPS Gaming.
• WebRTC Architecture: Peer-to-Peer(P2P), SDP (Session Description Protocol).
• NAT Traversal: STUN (공인 IP 탐색), TURN (릴레이 서버), ICE (최적 경로 협상), UDP Hole Punching.

Out-of-Scope

• 비디오/오디오 코덱 인코딩: H.264, VP9, Opus 압축 및 디코딩 물리학 $\rightarrow$ 미디어 프로세싱 공학 영역으로 위임.
• HTTP/3 (QUIC): UDP 기반이긴 하나, 웹 프로토콜로서의 진화 과정 $\rightarrow$ 08-04-01 HTTP Protocol Evolution 영역으로 분리.

Boundaries

• TCP (정확성) vs UDP (적시성): 1GB짜리 백업 파일을 전송할 때 1바이트라도 깨지면 파일 전체가 쓰레기가 됩니다(TCP 필요). 그러나 줌(Zoom) 화상 회의 중 33번째 프레임이 유실되었을 때, 이를 다시 받겠다고 1초를 멈추고 기다리면 사람들은 통신이 끊겼다고 욕을 합니다(UDP 필요). UDP는 무책임한 게 아니라, '과거의 완벽함'보다 '현재의 적시성(Timeliness)'을 우선시하는 실시간 비즈니스의 유일한 해답임을 명확히 경계 짓습니다.

3. Counterexample

• TCP 실시간 스트리밍의 비극: 인디 게임 개발자가 실시간 FPS 게임의 캐릭터 좌표 동기화를 TCP로 짰습니다. 유저 A가 총을 쏘며 이동하다가 패킷 1개가 드롭(Drop)되었습니다. TCP 특성상 이 유실된 패킷이 재전송되어 도착할 때까지(약 200ms) 그 뒤에 도착한 최신 좌표 패킷들마저 수신 버퍼(Buffer)에 갇혀 게임 엔진에 전달되지 않습니다(Head-of-Line Blocking). 결과적으로 유저 A의 캐릭터가 화면에서 0.5초간 멈췄다가 갑자기 순간이동을 하는 끔찍한 랙(Lag)이 발생합니다.
• NAT 릴레이 서버(TURN) 비용 폭탄: P2P 화상 채팅 앱을 만들며 WebRTC를 도입했습니다. 두 유저가 모두 빡센 방화벽(Symmetric NAT) 뒤에 있어 직접 연결(Hole Punching)이 실패하자, 모든 화상 트래픽이 회사가 띄워놓은 TURN(릴레이) 서버를 경유하게 됩니다. "P2P니까 서버 트래픽 비용은 0원일 거야!"라고 호언장담했던 개발자는 한 달 뒤 수천 기가바이트의 AWS 트래픽 폭탄 청구서를 맞고 멘붕에 빠집니다. NAT Traversal의 fallback 메커니즘을 제대로 예측하지 못한 인프라 재앙입니다.

4. Prerequisites

• L4 포트와 프로토콜 비교 (Basic): TCP와 UDP의 철학 차이. (08-01-03 Transport Layer)
• NAT와 사설 IP (Basic): 공유기의 IP/포트 변환. (08-01-02 Network Layer)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 멈추지 않는 질주, UDP (The Speed of UDP)

• Why to Learn: 신뢰성을 버리는 대가로 얻을 수 있는 압도적인 오버헤드 감소와 전송 속도 향상을 무기로, 실시간 애플리케이션의 L4 뼈대를 세우기 위함입니다.
• What to Learn:
  • Concepts: UDP (User Datagram Protocol), UDP Header (8 Bytes - Src/Dst Port, Length, Checksum), Connectionless, Stateless.
  • Skills: TCP 헤더(20 Bytes)와 UDP 헤더(8 Bytes) 구조를 비교하고, 왜 DNS 질의(Query)처럼 작고 빠른 요청에 UDP가 쓰이는지 분석하기.
• How to Learn:
  • 1단계: 인사 생략(Connectionless): TCP는 데이터 1바이트를 보내기 위해 무조건 SYN-ACK 3번의 인사(1 RTT 지연)를 해야 합니다. UDP는 주소 적고 그냥 우체통에 넣어버립니다. 첫 응답 속도에서 물리적으로 TCP를 압살하는 구조를 해부합니다.
  • 2단계: 깃털 같은 헤더(8 Bytes): TCP 헤더에는 순서 번호(Seq), ACK, 윈도우 사이즈 등 20바이트의 제어 정보가 덕지덕지 붙어있습니다. UDP는 [출발 포트, 도착 포트, 길이, 에러 체크(Checksum)] 딱 4개, 8바이트만 붙여서 던지는 극강의 경량성을 뜯어봅니다.
• Implement: TCP vs UDP 지연시간(Latency) 비교 시뮬레이터. Server(미국, RTT 200ms). 클라이언트가 DNS 조회(UDP)와 HTTP 요청(TCP)을 던짐. UDP 결과: 요청(100ms) + 응답(100ms) = 총 200ms 소요. TCP 결과: SYN(100ms) + SYN-ACK(100ms) + ACK+요청(100ms) + 응답(100ms) = 총 400ms 소요. 터미널에 2배 차이나는 타임라인 렌더링.

Recommended

Core Topic 02: 최신이 아니면 버려라, 실시간 렌더링 (Head-of-Line Blocking)

• Why to Learn: 패킷 하나 유실되었다고 전체 시스템이 멈춰서는 TCP의 결함(HoL Blocking)을 이해하고, 실시간 게임/스트리밍에서 과거 데이터를 미련 없이 버리는 아키텍처를 장악하기 위함입니다.
• What to Learn:
  • Concepts: Head-of-Line (HoL) Blocking, TCP Receive Buffer, Interpolation(보간법), Dead Reckoning.
  • Skills: UDP를 사용해 실시간 좌표(x, y) 데이터를 받을 때, 과거 시간(Timestamp)의 패킷이 지연되어 도착하면 즉각 버리는(Drop) 앱 레벨 필터링 구현.
• How to Learn:
  • 1단계: TCP 버퍼의 함정 (HoL Blocking): 게임 서버가 유저의 위치 패킷 [1번, 2번, 3번, 4번]을 보냈습니다. 2번이 유실되었습니다. TCP는 3, 4번이 도착했음에도 OS 버퍼에 가둬놓고 2번이 재전송될 때까지 앱에 올려주지 않습니다. 게임 화면이 1번 위치에서 '완전히 정지'해 버립니다.
  • 2단계: UDP의 미련 없는 전진: UDP를 씁니다. 2번이 유실되어도 앱은 즉시 3번, 4번 패킷을 받아 게임 캐릭터를 최신 위치로 그립니다. 2번 위치가 살짝 끊겨 보일 수는 있지만(보간법으로 부드럽게 무마 가능), 화면이 멈추는 일은 절대 없는 실시간 철학을 해부합니다.
• Implement: HoL Blocking 렌더링 (파이썬). 좌표 리스트 [{seq:1, x:10}, {seq:2, x:20}, {seq:3, x:30}]. 네트워크에서 seq 2 지연(Delay).
  • TCP 모드: 1 처리 $\rightarrow$ 3번 도착(버퍼에 킵, 렌더링 멈춤!) $\rightarrow$ 뒤늦게 2번 도착 $\rightarrow$ 그제야 2, 3 연속 렌더링.
  • UDP 모드: 1 처리 $\rightarrow$ 3번 도착(즉시 렌더링: x=30) $\rightarrow$ 뒤늦게 2번 도착(현재 상태 30보다 과거이므로 무시하고 Drop). 이 끊김 없는 움직임의 본질을 텍스트로 애니메이션화.

Practical

Core Topic 03: 브라우저 간의 직통 터널, WebRTC (WebRTC & P2P Magic)

• Why to Learn: 1대1 화상 채팅을 할 때 거대한 미디어 트래픽이 비싼 백엔드 서버를 거치지 않고, 유저들끼리(P2P) 알아서 주고받게 만들어 서버 비용을 0원으로 만드는 마법을 쥐기 위함입니다.
• What to Learn:
  • Concepts: WebRTC, Peer-to-Peer (P2P), SDP (Session Description Protocol), Signaling Server.
  • Skills: WebRTC 통신을 맺기 위해, 실제 영상(UDP)은 P2P로 쏘지만 그전에 서로의 IP와 코덱 정보(SDP)를 교환하기 위한 시그널링(TCP/WebSocket) 서버 설계.
• How to Learn:
  • 1단계: 중앙 서버의 비용 지옥: 화상 통화 영상(10Mbps)을 백엔드 서버로 보내고, 서버가 그걸 다시 상대방에게 보냅니다. 동시 접속자 1,000명이면 서버 대역폭 10Gbps가 터져나가고 회사는 파산합니다.
  • 2단계: WebRTC와 시그널링 (Signaling): 클라이언트 A와 B가 통신하고 싶습니다. 서로의 IP를 모릅니다. 먼저 가벼운 채팅 서버(Signaling Server)를 통해 "내 IP는 이거고 비디오 코덱은 이거 쓸래(SDP)"라는 텍스트 종이만 교환합니다(TCP). 주소 교환이 끝나면 브라우저끼리 서버를 거치지 않고 거대한 영상 트래픽을 UDP로 직접 쏴버리는(P2P) 궁극의 오프로딩을 뜯어봅니다.
• Implement: WebRTC 시그널링 핸드셰이크 모사. A 브라우저가 SDP Offer (내 IP: 1.1.1.1, 코덱: VP8)를 생성. 이를 웹소켓(시그널링 서버)을 통해 B에게 전달. B는 이를 받고 SDP Answer (내 IP: 2.2.2.2, 코덱: VP8 동의)를 생성해 A에게 반환. 서버 역할은 끝났고 [P2P TUNNEL OPENED: 1.1.1.1 <--> 2.2.2.2 via UDP] 로그를 띄우는 시퀀스.

Advanced

Core Topic 04: 공유기 벽 뚫기, NAT 트래버설 (NAT Traversal - STUN/TURN)

• Why to Learn: P2P로 연결하려 해도 양쪽 다 공유기(NAT 사설 IP) 뒤에 숨어 있어 외부에서 먼저 치고 들어갈 수 없는 물리적 장벽을 해킹 기법(Hole Punching)으로 박살 내기 위함입니다.
• What to Learn:
  • Concepts: NAT (Network Address Translation), STUN (Session Traversal Utilities for NAT), TURN (Traversal Using Relays around NAT), ICE (Interactive Connectivity Establishment), UDP Hole Punching.
  • Skills: P2P 직결을 위해 STUN으로 내 공인 IP를 알아내고 Hole Punching을 시도한 뒤, 실패하면 TURN 릴레이 서버로 폴백(Fallback)하는 ICE 파이프라인 이해.
• How to Learn:
  • 1단계: 방패와 창 (공유기의 벽): 유저 A(192.168.0.2)와 B(10.0.0.5)는 둘 다 사설 IP입니다. A가 B의 공유기 공인 IP로 영상 패킷을 쏘면, B의 공유기는 "내부에서 요청한 적 없는 웬 외부 패킷이냐?" 하고 방화벽 룰에 의해 가차 없이 버려버립니다(Drop).
  • 2단계: STUN과 홀 펀칭 (Hole Punching): A가 외부 STUN 서버에게 "내 공인 IP랑 포트 좀 알려줘"라고 찔러봅니다. 이때 A의 공유기에 '바깥으로 나가는 구멍(Hole)'이 뚫립니다. A와 B가 시그널링 서버를 통해 이 구멍 정보(공인 IP)를 교환하고, 서로 동시에 패킷을 쏘면 공유기가 "어? 내가 뚫어놓은 구멍으로 응답이 오네?"라고 착각하고 패킷을 통과시키는 기막힌 NAT 우회술을 해부합니다. 실패하면 최후의 수단으로 릴레이 서버(TURN)를 거칩니다.
• Implement: UDP Hole Punching 통과 시뮬레이터. NAT_A_Table = {}, NAT_B_Table = {}. A가 B로 다이렉트 쏘면 NAT_B가 차단(Drop). 하지만 A가 STUN 찌름 $\rightarrow$ NAT_A_Table에 [Port 5000 허용] 구멍 뚫림. B도 STUN 찌름 $\rightarrow$ NAT_B_Table에 [Port 6000 허용] 구멍 뚫림. 이제 서로 (A:5000 <-> B:6000)으로 동시에 쏘면 양쪽 NAT가 모두 이를 '정상 응답'으로 간주하여 P2P 통신이 성공(SUCCESS)하는 상태 변환 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Transport Layer Protocols (UDP)
• [P5] SFIA - Network Design (NTDS) - Real-time Protocol Design

Secondary

• [Computer Networking: A Top-Down Approach] Kurose & Ross - Connectionless Transport: UDP
• [WebRTC For The Curious] - WebRTC Architecture and NAT Traversal

Industry

• [Cloudflare Learning Center] - What is UDP? / What is WebRTC?
• [IETF RFC 5389] - Session Traversal Utilities for NAT (STUN)
• [IETF RFC 5766] - Traversal Using Relays around NAT (TURN)

9. Final Checklist

Primary

• 3-Way Handshake(연결 지향)를 생략하고 8바이트의 극소형 헤더만 사용하는 UDP의 비연결성(Connectionless) 구조가, TCP 대비 초기 응답 속도(Latency)와 서버 오버헤드 측면에서 갖는 우위를 설명할 수 있는가?
• TCP를 실시간 멀티플레이어 게임이나 화상 회의(VoIP)에 사용했을 때, 특정 패킷 유실로 인해 후속 데이터 처리가 전면 중단되는 Head-of-Line (HoL) Blocking 병목의 참사를 증명할 수 있는가?

Secondary

• WebRTC 아키텍처에서 P2P 통신을 맺기 위해, 클라이언트들이 미디어 연결 전 서로의 IP와 코덱 설정(SDP)을 교환하는 '시그널링(Signaling) 서버'의 필수적 중개 역할을 해부할 수 있는가?
• 공유기(NAT) 뒤에 있는 사설 IP 클라이언트들이 외부 STUN 서버를 찔러 자신의 공인 IP 매핑을 파악하고, 방화벽 규칙의 빈틈을 이용해 양방향 통신을 성사시키는 UDP 홀 펀칭(Hole Punching) 기법을 논증할 수 있는가?

Industry

• WebRTC의 ICE(Interactive Connectivity Establishment) 프레임워크가 P2P 직결(STUN) 시도를 먼저 한 뒤, 가장 폐쇄적인 NAT 환경에서 최후의 수단으로 릴레이 서버(TURN) 트래픽을 타게 되는 Fallback 파이프라인을 설계할 수 있는가?
• 도메인을 IP로 변환하는 DNS 쿼리(Query)가 왜 무겁고 신뢰성 높은 TCP를 버리고 가볍고 빠른 UDP를 기본 포트(Port 53) 프로토콜로 채택했는지, 그 아키텍처적 트레이드오프(응답 속도 vs 재전송 책임)를 평가할 수 있는가?