[Web] Web RTC (Real Time Communication)

WebRTC 핵심 개념 정리

WebRTC(Web Real-Time Communication)는 브라우저 또는 모바일 환경에서 플러그인 없이 실시간 음성, 영상, 데이터 통신을 가능하게 하는 기술입니다. 일반적인 WebRTC 연결은 다음과 같은 단계로 이루어집니다.

Signaling
SDP Exchange
ICE Candidate Gathering
Connectivity Check
Secure Media Transmission

각 구성 요소를 조금 더 자세히 살펴보겠습니다.

Signaling

시그널링(Signaling)은 각 peer가 서로 통신하기 위한 초기 연결 정보를 교환하는 과정입니다.
WebRTC 자체는 시그널링 방식을 표준으로 정의하지 않습니다.
따라서 보통 다음과 같은 프로토콜을 이용하여 구현합니다.

WebSocket
HTTP
Socket.io
MQTT 등

시그널링 서버의 역할은 다음과 같습니다.

Peer 간 연결 요청 전달
SDP Offer / Answer 교환
ICE Candidate 교환

즉, 시그널링은 실제 미디어 데이터를 전달하는 역할이 아니라 연결을 위한 협상(Negotiation) 과정만 담당합니다. 연결이 완료되면 미디어 스트림은 Peer-to-Peer로 직접 전달되며 시그널링 서버는 더 이상 필요하지 않습니다.

SDP (Session Description Protocol)

SDP(Session Description Protocol)는 peer 간 통신 방식(Media capability)을 설명하는 메타데이터 형식입니다. 쉽게 말하면 각 peer가 어떤 방식으로 통신할 수 있는지를 서로 설명하는 문서라고 볼 수 있습니다. SDP에는 다음과 같은 정보가 포함됩니다.

지원 가능한 Codec (VP8, H264, Opus 등)
미디어 타입 (Audio / Video / DataChannel)
미디어 전송 프로토콜 (RTP/RTCP)
암호화 방식 (DTLS-SRTP)
네트워크 정보 (IP, Port 등)

WebRTC 연결 과정에서는 다음과 같은 Offer / Answer 모델이 사용됩니다.

Caller가 SDP Offer 생성
Signaling 서버를 통해 전달
Callee가 SDP Answer 생성
연결 협상 완료

SDP example

v=0
o=- 46117317 2 IN IP4 127.0.0.1
s=WebRTC Session
t=0 0
m=audio 9 RTP/SAVPF 111
a=rtpmap:111 opus/48000/2

이 과정을 통해 양쪽 peer가 모두 지원하는 공통 통신 방식이 결정됩니다.

ICE (Interactive Connectivity Establishment)

SDP를 통해 통신 방식이 결정되면 다음 단계는 실제로 데이터를 전달할 네트워크 경로를 찾는 과정입니다. 이 과정이 바로 ICE(Interactive Connectivity Establishment) 입니다. 인터넷 환경에서는 다양한 네트워크 환경이 존재합니다.

예를 들면,

사설 네트워크 (NAT)
방화벽
서로 다른 ISP

이 때문에 단순히 IP 주소만으로는 peer 간 연결이 어렵습니다. ICE는 다음 과정을 통해 가능한 모든 연결 경로 후보(candidate) 를 수집하고 테스트합니다.

Local Candidate (로컬 네트워크 IP)
Server Reflexive Candidate (STUN을 통해 확인된 공인 IP)
Relay Candidate (TURN 서버 경유)

이 후보들을 서로 교환한 뒤 Connectivity Check를 통해 실제로 통신 가능한 경로를 테스트합니다. 그 중 가장 효율적인 경로가 최종적으로 선택됩니다.

ICE Candidate 종류

ICE는 크게 3가지 후보를 수집합니다.

1️⃣ Host Candidate

로컬 네트워크 주소입니다.

192.168.0.2
10.0.0.3

같은 LAN 환경에서는 이것만으로도 연결이 가능합니다.

2️⃣ Server Reflexive Candidate (srflx)

STUN 서버를 통해 확인한 공인 IP 주소입니다.

203.0.113.15:54321

NAT 뒤에 있는 peer가 외부에서 보이는 주소입니다.

3️⃣ Relay Candidate

TURN 서버를 통해 생성된 주소입니다.
이 경우 TURN 서버가 데이터를 중계합니다.

STUN / TURN

WebRTC에서 가장 어려운 부분 중 하나는 NAT 환경에서 peer 간 연결을 만드는 것입니다.
이를 해결하기 위해 STUN과 TURN 서버가 사용됩니다.

STUN (Session Traversal Utilities for NAT )

일반적으로 사용자의 디바이스는 사설 IP (예: 192.168.x.x) 를 사용합니다. 하지만 인터넷에서는 공인 IP가 필요하기 때문에 NAT(Network Address Translation)가 이를 변환합니다. 문제는 peer가 자신의 공인 IP를 알기 어렵다는 것입니다. STUN 서버는 다음 역할을 합니다.

Peer가 STUN 서버에 요청
STUN 서버가 요청을 받은 공인 IP + Port 확인
해당 정보를 Peer에게 반환

이를 통해 Peer는 외부에서 접근 가능한 자신의 주소(Server Reflexive Address) 를 알 수 있습니다. STUN 서버는 내가 인터넷에서 어떤 공인 IP로 보이는지 알려주는 서버입니다.

내 공인 IP: 203.0.113.15
Port: 54321

이를 통해 peer는 Server Reflexive Candidate를 생성합니다.

TURN (Traversal Using Relay around NAT)

일부 NAT 환경에서는 Peer-to-Peer 연결이 아예 불가능한 경우가 있습니다.
대표적인 경우

Symmetric NAT
기업 방화벽
UDP 차단 네트워크

이 경우에는 STUN으로도 직접 연결이 되지 않습니다.
이때 TURN 서버가 중계 서버 역할을 합니다.

TURN 서버는 P2P 연결이 불가능할 때 사용하는 Relay 서버입니다.

TURN 사용 구조

Peer A → TURN Server → Peer B

즉, 미디어 데이터가 TURN 서버를 통해 릴레이됩니다.
단점은 다음과 같습니다.

서버 트래픽 증가
지연 증가
운영 비용 증가

그래서 WebRTC에서는 가능하면 P2P 연결을 우선 시도하고, 실패하면 TURN을 사용하는 방식으로 동작합니다.

WebRTC 연결 흐름

전체 흐름을 정리하면 다음과 같습니다.

1. Signaling
Peer 간 연결 협상 시작

2. SDP Exchange
통신 방식 협상 (Codec, Media)

3. ICE Candidate Gathering
가능한 네트워크 경로 수집

4. STUN
공인 IP 확인

5. ICE Connectivity Check
실제 연결 가능한 경로 테스트

6. TURN (Fallback)
직접 연결이 안되면 Relay 사용

7. P2P Media Transmission
실제 음성 / 영상 데이터 전달

WebRTC 내부 핵심 객체

WebRTC API에서 가장 중요한 객체는 다음 3가지입니다.

RTCPeerConnection

WebRTC 연결의 핵심 객체입니다.

ICE 처리
네트워크 연결 관리
media stream 전송
encryption 처리

const pc = new RTCPeerConnection(configuration);

MediaStream

카메라와 마이크에서 가져온 audio/video stream입니다.

navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true
});

RTCDataChannel

Peer 간 데이터 전송 채널입니다.

채팅
파일 전송
게임 데이터

TCP-like / UDP-like 설정이 가능합니다.

WebRTC 보안 (DTLS-SRTP)

WebRTC는 모든 미디어 데이터를 기본적으로 암호화합니다.
사용되는 기술

DTLS

Datagram TLS
→ key exchange

SRTP

Secure RTP
→ media encryption

구조

DTLS Handshake
       ↓
Encryption Key 생성
       ↓
SRTP로 Media Stream 암호화

즉 WebRTC에서는 평문 Media 전송이 불가능합니다.

WebRTC Connection Flow

아래는 WebRTC 연결이 이루어지는 전체 흐름입니다.

Caller                        Signaling Server                      Callee
   |                                 |                                |
   |------ SDP Offer --------------->|                                |
   |                                 |------ SDP Offer -------------> |
   |                                 |                                |
   |                                 |<----- SDP Answer ------------- |
   |<------ SDP Answer --------------|                                |
   |                                 |                                |
   |---- ICE Candidate ------------->|                                |
   |                                 |---- ICE Candidate -----------> |
   |                                 |                                |
   |<--- ICE Candidate --------------|                                |
   |                                 |<--- ICE Candidate ------------ |
   |                                 |                                |
   |-------- ICE Connectivity Check (P2P Attempt) ------------------->|
   |                          P2P Connection                          |
   |<================ Secure Media Stream (SRTP) ====================>|

WebRTC 연결 단계 요약

전체 과정은 다음 순서로 진행됩니다.

1. Signaling 시작
2. SDP Offer / Answer 교환
3. ICE Candidate 수집
4. STUN 통해 공인 IP 확인
5. ICE Connectivity Check
6. 가능하면 P2P 연결
7. 실패하면 TURN Relay 사용
8. DTLS-SRTP 암호화 Media 전송

WebRTC 주요 특징

WebRTC의 중요한 특징을 정리하면 다음과 같습니다.

실시간 통신

low latency
P2P 기반

자동 네트워크 탐색

ICE
STUN
TURN

다양한 코덱 지원

Video

VP8 : WebRTC 기본 코덱
VP9 : 고효율 코덱
H.264 : 하드웨어 가속
AV1 : 최신 고효율 코덱

Audio

Opus : WebRTC 기본
G.711 : Legacy Telephony Codec
G.712 : Wideband Audio
iLBC : Low-bitrate Audio

강력한 보안

DTLS
SRTP
end-to-end encryption

저작자표시 비영리 동일조건 (새창열림)

NSLog(@“Hello!! MB”);