💬 WebRTC를 알아보자

키워드

P2P TCP UDP SRTP SCTP Signaling SDP STUN/TURN NAT Traversal ICE Trickle ICE Mesh SFU

WebRTC란?

WebRTC(Web Real-Time Communications)은 웹 어플리케이션 및 모바일 기기에서 별도의 소프트웨어나 플러그인 없이 음성, 영상 미디어, 텍스트, 파일과 같은 데이터를 주고받을 수 있는 기술이다. 주로 P2P( Peer-to-Peer) 화상회의 및 데이터 공유를 지원하며, 브라우저 간의 실시간 통신을 가능하게 한다.

WebSocket과 차이점

WebSocket과 WebRTC 모두 실시간 통신을 지원하지만, 그 용도와 구조가 다르다.

WebSocket

클라이언트와 서버 간의 양방향 통신을 가능하게 하는 프로토콜이다. WebSocket은 텍스트와 바이너리 형식으로 데이터를 주고받을 수 있다.

WebSocket 연결은 처음에 HTTP로 시작한다. 이때 특별한 헤더들을 포함시켜 이 연결을 WebSocket으로 업그레이드하고 싶다는 의사를 전달한다. HTTP를 기반으로 handshake를 통해 TCP 연결이 수립된다.

TCP 연결 수립과 종료

연결 수립: 3-way handshake (쓰리 웨이 핸드셰이크)

세 개의 단계로 이루어진 연결 수립 과정을 의미한다.

호스트 A, B의 쓰리 웨이 핸드셰이크 단계

송수신 방향	세그먼트	세그먼트에 포함된 주요 정보
A → B	SYN 세그먼트	- 호스트 A의 초기 순서 번호 - 1로 설정된 SYN 비트
B → A	SYN + ACK 세그먼트	- 호스트 B의 초기 순서 번호 - 호스트 A가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 SYN 비트 - 1로 설정된 ACK 비트
A → B	ACK 세그먼트	- 호스트 A의 다음 순서 번호 - 호스트 B가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 ACK 비트

handshake가 완료되면, HTTP 프로토콜이 아닌 WebSocket 프로토콜을 사용해 통신하게 된다. TCP 기반으로 데이터를 주고받아 신뢰성을 보장한다. 한번 연결이 수립되면 양쪽에서 자유롭게 메시지를 주고받을 수 있다.

WebRTC

서버를 경유하지 않고 브라우저 간 직접 통신(P2P)을 지원하는 기술이다. 데이터를 P2P로 직접 전송할 수 있어 지연 시간 및 서버의 부하를 줄일 수 있다. 텍스트/바이너리 형태의 데이터만 전송할 수 있는 WebSocket과 달리 비디오, 오디오 등 미디어 스트림을 지원하여 다양한 형태의 데이터 실시간 통신이 가능하다. getUserMedia(), RTCPeerConnection, RTCDataChannel 등의 API를 통해 카메라/마이크 접근부터 데이터 전송까지 다양한 기능을 제공한다.

Mesh 방식과 SFU 방식

WebRTC에서 다자간 연결을 구현할 때 두 가지 방식이 자주 사용된다.

Mesh 방식

모든 피어가 각 피어와 직접 P2P 연결을 맺는 방식이다. 참가자가 적을 때(4-5명까지)는 구현이 간단하고 지연시간이 짧다는 장점이 있지만, 참가자가 늘어날수록 필요한 연결 수가 기하급수적으로 증가하여 네트워크와 디바이스에 큰 부담을 준다.

SFU 방식

SFU(Selective Forwarding Unit) 방식은 중앙에 미디어 서버를 두고 이를 통해 스트림을 중계하는 방식이다. 각 참가자는 자신의 스트림을 SFU 서버에 한 번만 전송하고, SFU는 이를 다른 모든 참가자에게 전달한다. 이 방식은 클라이언트의 부담을 줄일 수 있고, 대규모 연결도 효율적으로 처리할 수 있지만, 서버 인프라가 필요하고 서버를 거치면서 추가적인 지연이 발생할 수 있다.

P2P 연결 절차

1. 시그널링 서버 연결 설정
   - WebSocket 등을 통한 시그널링 서버 연결
   - 사용자 인증 및 세션 설정

2. 로컬 미디어 획득
   - getUserMedia() API를 통한 카메라/마이크 접근
   - 미디어 제약조건 설정 (해상도, 프레임레이트 등)

3. RTCPeerConnection 객체 생성
   - STUN/TURN 서버 설정
   - 미디어 처리 파이프라인 초기화
   - 이벤트 핸들러 등록

4. SDP 교환 (Offer/Answer)
   - Offer 생성 및 전송 (발신측)
   - Answer 생성 및 전송 (수신측)
   - 로컬/원격 SDP 설정

5. ICE Candidate 수집 및 교환
   - 로컬 candidate 수집
   - STUN 서버를 통한 공인 주소 확인
   - Candidate 정보 교환

6. P2P 연결 수립
   - ICE 연결 확인
   - DTLS/SRTP 보안 협상
   - 미디어/데이터 채널 설정

7. 스트림 전송
   - 미디어 인코딩/디코딩
   - 네트워크 상태에 따른 적응형 비트레이트 조정

Signaling이란?

WebRTC 연결 설정 과정에서 피어 간 초기 정보를 교환하는 절차이다. WebRTC는 시그널링을 위한 별도 프로토콜을 정의하지 않아 주로 WebSocket으로 구현된 시그널링 서버가 이 역할을 수행하게 된다.

시그널링이 필요한 이유는 피어 간 서로의 정보(예: IP주소, 포트)를 모르기 때문이다. P2P 연결을 설정하기 위해 이러한 초기 정보를 교환할 수 있도록 해주는 것이 시그널링 서버의 역할이다. 시그널링 서버는 사용자 세션 관리, SDP 교환, ICE candiate 전달 등을 담당한다. 예를 들어, 사용자 A가 화상 통화를 시작하려고 한다면, 시그널링 서버는 사용자 B에게 A의 연결 요청을 전달하고 양쪽의 SDP 정보와 ICE candidate를 중개한다. 시그널링 프로토콜은 WebRTC 표준에 포함되어 있지 않기 때문에 개발자가 프로그램의 요구사항에 맞게 자유롭게 설계할 수 있다.

Signaling 과정

1. 사용자 연결
   - WebSocket 연결 수립
   - 사용자 인증/식별

2. 방 생성/참여
   - 방 ID 생성/공유
   - 참여자 관리

3. SDP 교환
   - Offer 생성/전달
   - Answer 생성/전달

4. Candidate 교환
   - ICE candidate 수집
   - 실시간 전달

5. 연결 상태 관리
   - 연결/해제 이벤트 처리
   - 오류 처리

NAT Traversal과 방화벽

NAT(Network Address Translation)은 사설 IP 주소를 공인 IP 주소로 변환하는 기술이다. 하나의 공인 IP를 여러 사설 IP가 공유할 수 있게 해준다.

NAT Traversal은 이러한 NAT 환경에서 P2P 연결을 가능하게 만드는 기술들을 총칭한다. NAT 뒤에 있는 기기와의 통신을 설정할 수 있도록 하는데, WebRTC는 STUN과 TURN 서버, ICE 등 다양한 NAT Traversal 기술들을 사용해 NAT와 방화벽 문제를 해결한다.

방화벽은 네트워크 트래픽을 제한하여 외부 공격으로부터 네트워크를 보호한다. WebRTC 연결 시 특정 포트가 차단된 경우 연결이 어려울 수 있다.

즉, 라우터를 통과해 공인 IP 주소, 사설 IP 주소를 알아내어 클라이언트 간 P2P 연결을 할 수 있는 방법을 찾는 과정을 NAT Traversal이라고 한다.

공인 IP 주소와 사설 IP 주소

공인 IP 주소

전 세계에서 고유한 IP 주소이다. 네트워크 간의 통신, 이를테면 인터넷을 이용할 때 사용하는 IP 주소가 바로 공인 IP 주소이다. 공인 IP 주소는 ISP나 공인 IP 주소 할당 기관을 통해 할당받을 수 있다.

사설 IP 주소와 NAT

사설 네트워크에서 사용하기 위한 IP 주소이다. 사설 네트워크란 인터넷, 외부 네트워크에 공개되지 않은 네트워크를 의미한다. IP 주소 공간 중 사설 IP 주소로 사용하도록 특별히 예약된 IP 주소 공간이 있다. 다음 범위에 속하는 IP 주소는 사설 IP 주소로 간주하기로 약속되어 있다.

• 10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
• 172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
• 192.168.0.0/16 (192.168.0.0 - 192.168.255.255)

사설 IP 주소의 할당 주체는 일반적으로 라우터이다. 할당받은 사설 IP 주소는 해당 호스트가 속한 사설 네트워크상에서만 유효한 주소이므로, 얼마든지 다른 네트워크상의 사설 IP 주소와 중복될 수 있다. 그렇다면 사설 IP 주소를 사용하는 호스트가 외부 네트워크와 통신하려면 어떻게 해야 할까? 이때 사용되는 기술이 NAT(Network Address Translation)이다. NAT는 IP 주소를 변환하는 기술이다. 주로 네트워크 내부에서 사용되는 사설 IP 주소와 네트워크 외부에서 사용되는 공인 IP 주소를 변환하는 데 사용된다. NAT를 통해 사설 IP 주소를 사용하는 여러 호스트는 적은 수의 공인 IP 주소를 공유할 수 있다. 대부분의 라우터와 (가정용) 공유기는 NAT 기능을 내장하고 있다. 그렇기에 사설 네트워크상에서 만들어진 패킷 속 사설 IP 주소는 공유기를 거쳐 공인 IP 주소로 변경되고, 외부 네트워크로 전송된다. 반대로 외부 네트워크로부터 받은 패킷 속 공인 IP 주소는 공유기를 거쳐 사설 IP 주소로 변경되어 사설 네트워크 속 호스트에 이르게 된다.

STUN/TURN 서버

STUN(Session Traversal Utilities for NAT) 서버

NAT 뒤에 있는 클라이언트가 자신의 공인 IP 주소와 포트를 알아내는 데 사용된다. 클라이언트가 STUN 서버에 요청을 보내면, STUN 서버는 해당 클라이언트가 보이는 공인 주소 정보를 응답으로 전송한다. STUN 서버는 단순히 주소 정보만을 제공하여 서버 리소스 사용이 적고 구현이 비교적 간단하다. STUN 서버는 P2P 연결이 가능한 상황에서는 직접 통신을 할 수 있게 해준다.

TURN(Traversal Using Relays around NAT) 서버

P2P 연결이 불가능한 경우 미디어 데이터를 중계해 주는 서버이다. Symmetric NAT와 같이 제한적인 환경에서는 직접적인 P2P 연결이 불가능할 수 있는데, 이때 TURN 서버가 중간에서 트래픽을 중계한다. 모든 미디어 스트림이 TURN 서버를 경유하여 서버의 대역폭과 처리 능력이 중요하다. TURN 서버는 비용이 많이 들고 확장성에도 제약이 있어 직접 P2P 연결이 실패했을 때 마지막 수단으로 사용된다.

Symmetric NAT(대칭형 NAT)

내부 네트워크의 장치가 외부 네트워크와 통신할 때, 같은 내부 IP 주소와 포트 번호를 사용하더라도, 대상이 되는 외부 주소에 따라 서로 다른 매핑된 공용 IP 주소와 포트 번호를 할당하는 NAT 유형 통신하려는 대상에 따라 공용 IP 주소와 포트가 다르게 설정된다.

Symmetric NAT의 P2P 연결 문제

P2P 통신에서는 각 피어의 공용 IP 주소와 포트를 통해 직접 통신하려 한다. 그러나 Symmetric NAT에서는 각기 다른 대상과 통신할 때마다 새로운 매핑이 생성되므로, P2P 통신이 복잡해지거나 불가능할 수 있다. 이 경우, TURN 서버를 사용해 P2P 연결을 우회하거나, 중계 서버를 통한 간접 연결이 필요하다. Symmetric NAT는 일반적으로 보안성이 높지만, NAT 트래버설에 어려움을 주어 WebRTC나 P2P 통신 환경에서는 문제점으로 작용할 수 있다.

SDP

SDP(Session Description Protocol)는 피어 간에 주고받을 미디어의 종류, 코덱, 해상도, 대역폭 등의 정보를 텍스트로 기술한 프로토콜이다. 피어 간의 미디어 특성을 협상하고, 이 정보를 바탕으로 미디어 스트림이 설정된다. 즉, SDP 교환은 “어떤 종류의 미디어를 어떤 방식으로 주고받을지” 협의하는 과정이고, 이후 ICE candidate 교환은 “어떤 경로로 연결할지”를 찾는 과정이다.

ICE와 candidate

ICE(Interactive Connectivity Estabishment)는 두 피어 간의 최적 연결 경로를 찾아내는 프레임워크이다. NAT와 방화벽이 존재하는 복잡한 네트워크 환경에서, 가능한 모든 연결 경로를 시도하고 최적의 경로를 선택하는 과정을 담당한다. ICE는 여러 개의 candidate(후보)를 수집하고 우선순위에 따라 연결을 시도한다.

candidate 종류

1. Host Candidate
   - 로컬 네트워크 인터페이스 주소
   - 최우선 사용 시도
   - 예: "192.168.1.100:9999"

2. Server Reflexive Candidate
   - STUN 서버로 확인한 공인 주소
   - NAT 바인딩 주소
   - 예: "203.0.113.100:12345"

3. Relay Candidate
   - TURN 서버 할당 주소
   - 최후의 수단으로 사용
   - 예: "turn.example.com:3478"

ICE 프로세스는 단계적으로 연결을 시도한다.

1. Host Candidate (로컬 주소) 수집

• 먼저 자신의 로컬 네트워크 인터페이스 주소를 수집
• 같은 네트워크에 있는 경우 이 주소로 직접 연결 시도

2. Server Reflexive Candidate (STUN을 통한 공인 주소) 수집

• STUN 서버를 통해 NAT 뒤의 공인 IP:Port 확인
• 다른 네트워크에 있지만 NAT 환경이 허용적인 경우 이 주소로 연결 시도

3. Relay Candidate (TURN 서버 주소) 수집

• 위의 두 방법으로 연결이 안 되는 경우
• 특히 Symmetric NAT 같은 제한적인 환경에서
• TURN 서버를 통한 중계 연결 시도

이는 마치 계단식 폴백(fallback) 메커니즘처럼 작동한다.

1. Host Candidate 시도
    ↓ (실패시)
2. Server Reflexive Candidate(STUN) 시도
    ↓ (실패시)
3. Relay Candidate(TURN) 시도

ICE는 이러한 candidate들을 순차적으로 시도하면서 연결이 가능한 경로를 찾아낸다. 이 과정에서 양쪽 피어의 candidate들을 조합해 가능한 모든 경로를 테스트하고, 네트워크 상태와 지연시간 등을 고려해 최적의 경로를 선택한다.

Trickle ICE

ICE 프로세스를 최적화하는 기술이다. 전통적인 ICE 프로세스에서는 모든 candidate를 수집 후 한꺼번에 전송하는데, Trickle ICE는 candidate를 발견하는 즉시 전송한다. 이 방식의 장점은 연결 설정 시간을 크게 단축할 수 있다는 것이다. candidate들을 수집하는 작업을 병렬로 진행할 수 있다. 빨리 발견되는 candidate부터 연결을 시도해 볼 수 있어 전체적인 연결 설정 시간이 단축된다.

데이터 전송 프로토콜

WebRTC는 미디어 스트림과 데이터 채널 위해 서로 다른 프로토콜을 사용한다. 미디어 스트림의 경우 RTP(Real-time Transport Protocol)를 기반으로 한다. RTP는 UDP를 기반으로 동작하는, 실시간 데이터 전송을 위해 설계된 프로토콜로, 패킷에 시퀀스 번호와 타임스탬프를 포함해 수신 측에서 패킷의 순서를 재구성하고 적절한 시점에 재생할 수 있게 한다.

보안을 위해 RTP는 SRTP(Secure Real-time Transport Protocol)로 암호화된다. SRTP는 미디어 스트림의 기밀성, 메시지 인증, 재전송 방지 등을 제공한다.

데이터 채널의 경우 SCTP(Stream Control Transmission Protocol)를 사용한다. SCTP는 TCP와 유사하게 신뢰성 있는 데이터 전송을 제공하면서도, UDP의 장점을 살려 여러 개의 독립적인 스트림을 동시에 처리할 수 있다. 또한 메시지 기반의 전송을 지원하여 채팅이나 파일 전송과 같은 애플리케이션에 적합하다.

미디어스트림과 데이터 채널

미디어 스트림 (MediaStream)

• 실시간 오디오/비디오 데이터를 전송하기 위한 스트림
• getUserMedia() API를 통해 카메라/마이크에서 가져온 데이터
• 미디어 처리를 위한 특별한 기능 제공:
  • 인코딩/디코딩
  • 에코 제거
  • 노이즈 감소
  • 비트레이트 조절
  • 패킷 손실 보정 데이터 채널 (DataChannel)
• 임의의 데이터를 주고받을 수 있는 채널
• 텍스트, 파일, JSON 등 모든 종류의 데이터 전송 가능
• TCP나 UDP 같은 특성 선택 가능:
  • ordered/unordered (순서 보장 여부)
  • reliable/unreliable (신뢰성 보장 여부) 주요 차이점

1. 용도: 미디어 스트림은 비디오/오디오 전용, 데이터 채널은 모든 종류의 데이터
2. 처리 방식: 미디어 스트림은 실시간 미디어 처리 최적화, 데이터 채널은 일반적인 데이터 전송
3. 제어: 데이터 채널은 신뢰성과 순서 보장 여부를 설정할 수 있음

참고 자료

https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html
https://k0zdevel.tistory.com/129
https://www.youtube.com/watch?v=bWcNEk0H4Y0