WebRTC(Web Real-Time Communication)

WebRTC란 무엇인가

WebRTC(Web Real-Time Communication)란

WebRTC(Web Real-Time Communication)는 웹 어플리케이션 및 모바일 기기에서 별도의 소프트웨어나 플러그인 없이 음성, 영상 미디어, 텍스트, 파일과 같은 데이터를 주고받을 수 있는 기술이다.

역사

월드 와이드 웹(World Wide Web)이 1990년대에 처음 등장했을 때, 웹은 단순히 하이퍼링크로 연결된 정적인 문서 기반의 모델이었다.
000년대 중반에 이르러서는 XHR(XMLHttpRequest) 방식을 통해 페이지 전환 없이 동적으로 데이터를 받아올 수 있게 되면서, 웹은 동적인 어플리케이션을 제작할 수 있는 플랫폼이 되었다.
WebRTC는 기존의 웹 2.0에서 한층 더 나아가, 서버와 같은 중간자를 거치지 않고 브라우저 간을 P2P로 연결하는 기술이다.(심지어 플로그 인도 필요없다.)

특징

Google WebRTC팀이 시작한 오픈소스이며 Apple, Google, Microsoft, Mozilla 등의 지원을 받는다.
WebRTC는 구글이 주도한 오픈소스 프로젝트를 기반으로 하는 웹 표준이기 때문에, 특히 크롬(Chrome)에서 호환성이 높다.
WebRTC는 아직까지 다양한 플랫폼에서 표준화가 완전히 구현되지는 않은 기술이다.
각 브라우저의 WebRTC API에는 moz, webkit 같은 벤더 프리픽스(vendor prefix)가 붙어있다.
대부분의 실시간 시스템(예:SIP)과 달리, WebRTC 통신은 자바스크립트 API를 사용해서 일부 웹서버에 의해 직접 제어된다.
WebRTC는 단일 브라우저 벤더에서 제공하는 API가 아니며, 브라우저와 운영체제별로 개발되는 속도와 지원되는 버전이 다르므로 호환성과 상호 운용성을 항상 체크해야한다.

지원하는 브라우저 https://caniuse.com/rtcpeerconnection

WebRTC의 동작 원리

WebRTC는 두 클라이언트가 P2P로 연결되어 UDP를 사용한 통신을 수행학 때문에 이에 맞는 연결과정이 수립되어야 한다. 우선 어떻게 통신 순서가 수행되는지 확인하고, 이러한 연결과정이 필요한 이유와 각 과정의 디테일한 수행 내용을 확인해보자. 통신 과정은 크게 Signaling/ NAT Traversal/ 데이터 통신으로 구분된다. (주의할 점은 WebRTC는 현재 비 표준 상태로 해당 과정은 일반적인 구현 방식을 의미하는 것이다.)

통신 순서 요약

1. Signaling

통신에 참여한 클라이언트가 상호 연결정보, 데이터 형식을 공유하는 기초 정보를 설정하는 과정이다. 시그널링 서버가 이 역할을 수행한다.

1-1. SDP 교환

미디어 스트림의 코덱, 해상도, 대역폭 등 데이터 형식에 대한 세부 정보를 공유한다.

1-2. ICE Candidate

각 클라이언트의 네트워크 경로 정보(공인 IP, 로컬 IP, TURN 서버 정보 등)를 탐색하고 공유한다. 즉 연결을 위한 경로의 후보를 탐색하고 공유한다.

2. NAT Traversal

NAT 뒤에 있는 클라이언트 간의 직접 연결(P2P)을 설정한다. 이떄 우선 STUN을 사용한 후보(ICE)로 시도하고, 불가능하다면 TURM을 이용해 연결한다.

3. 데이터 통신

연결이 완료된 두 클라이언트가 UDP 통신을 수행한다.

왜 이런 과정이 필요한가.

처음본다면 위 과정이 낯설 수 있다. 지금 부터 용어와 원리를 자세하게 정리해보겠다. P2P 연결은 일반적인 서버에 클라이언트가 접근하는 것과는 차이가 있다.

1. NAT

일반적으로 많은 클라이언트는 NAT환경 뒤에 위치한다. 이로 인해 게이트웨이(라우터)가 공용 IP를 부여받고, 라우터에 연결된 단말들은 사설 IP를 부여받는다. 이로인해 아웃바운드 요청은 가능하나, 인바운드 요청이 불가능하다.

방화벽
- 대부분의 로컬 컴퓨터는 인바운드에 대한 방화벽이 설정되어 있어 외부에서의 접근이 어렵다.
NAT(Router)
- 라우터에 연결되어 있는 경우 사설 IP주소(내부 IP) 까지 알아야 접근이 가능하다. 포트포워딩을 일일이 시킬 수는 없으니 문제요소이다.
Symmetric NAT
- 이전에 연결된적 있는 네트워크만 연결 가능하게 제한을 걸어두는 것
DHCP
- IP 네트워크에서 사용되는 프로토콜로, 네트워크에 연결된 장치에 IP 주소를 자동으로 할당한다. 일반적인 사용자의 단말은 고정된 공인 IP가 아니라 통신사에서 유동적으로 조절하는 IP를 부여받는다. 이로인해 사설 ip가 변동적으로 배정된다.

2. UDP

그렇다면 한쪽만 NAT뒤에 위치하고 다른 클라이언트는 공인 IP에 연결되어 있다면 문제가 없다고 생각할수 있다. NAT뒤의 클라이언트가 공인 IP에 연결된 컴퓨터로 마치 HTTP 요청을 하듯 요청을 보내면 되지 않는가 하는 생각을 할 수 있다. (이것은 아래에서 설명하게 될 미디어 중계서버를 두는 SFU 구조에서도 NAT이 문제가 되는 이유를 설명한다.) 그러나 WebRTC에서 이것이 불가능한 이유는 UDP를 사용하기 때문이다. (항상 그렇다고는 할 수 없지만 목적을 생각했을때 주로 UDP를 사용하게 됨이 분명하다.)

미디어스트림은 데이터 손실을 감수하고 전송 속도가 빠른 UDP를 사용하는 것이 일반적이다. 이러한 UDP로 연결을 수행하려면 TCP와 달리 3-way handshake와 같은 연결상태를 보장하고 연결을 확립하는 초기 과정이 부재하다. 이로인해 NAT뒤에 있는 사용자가 연결을 확립하지 못하고 데이터를 수신해야하는 경우가 생긴다.

이것은 TCP에서 서버로 먼저 요청을 보내고 응답을 받는것과는 다르게 NAT 뒤의 사용자가 데이터를 최초로 수신해야한다.

이러한 특성상 WebRTC는 일반적인 HTTP, Websocket등의 TCP기반 통신과는 다르게 NAT환경이 문제가 된다.

정리하자면 NAT환경이 문제가 되는 경우는

NAT 뒤의 수신자가 최초로 TCP 요청을 받아야할떄(서버의 역할일떄)

NAT 뒤의 수신자가 UDP 통신을 통해 데이터를 수신받아야 할떄이다. 이러한 요소를 해결하고 P2P연결을 수행하기 위해 NAT 트래버셜(NAT traversal)을 수행한다.

TCP에서 서버는 NAT뒤의 사용자에게 어떻게 응답할까?

HTTP나 WebSocket 통신에서 NAT 뒤에 있는 클라이언트가 외부 서버와 통신할 때, NAT와 라우터는 요청을 처리하고 응답을 전달하는 역할을 한다. 이를 이해하기 위해 NAT 라우터의 동작 방식을 살펴보자.

NAT 라우터와 클라이언트-서버 통신

클라이언트의 요청
NAT 뒤에 있는 클라이언트는 사설 IP를 사용하여 HTTP 또는 WebSocket 요청을 공인 IP를 가진 외부 서버로 보낸다. 요청에는 클라이언트의 사설 IP 주소와 송신 포트가 포함되지만, NAT 라우터는 이를 외부로 직접 사용하지 않는다.
NAT의 포트 매핑
NAT 라우터는 클라이언트의 사설 IP와 송신 포트를 라우터의 공인 IP와 새로운 송신 포트로 변환한다. 이를 포트 매핑이라고 한다. 변환된 요청은 NAT 라우터의 공인 IP와 변환된 포트를 사용해 외부 서버로 전달된다. NAT 라우터는 이때 매핑 테이블을 만들어, 클라이언트와 매핑된 정보를 저장한다.
예시:
```
  (사설 IP:사설 포트) <--> (공인 IP:변환된 포트)
```
서버의 응답
외부 서버는 요청을 처리하고, NAT 라우터의 공인 IP와 변환된 포트로 응답을 보낸다.
NAT 라우터의 매핑 테이블 참조
NAT 라우터는 수신한 응답의 목적지 포트를 확인하고, 매핑 테이블을 참조하여 이를 생성한 클라이언트를 식별한다. 이를 기반으로 응답을 클라이언트의 사설 IP와 사설 포트로 전달한다.
클라이언트의 응답 수신
클라이언트는 NAT 라우터로부터 전달된 응답을 받고 통신을 완료한다.

요약

서버는 클라이언트의 사설 IP를 직접 알지 못하고, NAT 라우터의 공인 IP와 변환된 포트를 통해 통신한다.
NAT 라우터는 매핑 테이블을 유지하며, 클라이언트와 서버 간 통신을 중계한다.
NAT 라우터는 클라이언트의 사설 IP를 공인 IP로 변환하고, 서버 응답을 다시 사설 IP로 변환하여 전달한다.

NAT 트래버셜(NAT traversal)

라우터를 통과해서 연결할 방법을 찾는 과정이다.

STUN, TURN 서버를 이용해서 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소인 후보(Candidate)를 찾는 과정이다.
Finding Candidate라고 한다.
아래의 3가지 정보를 얻게된다.
- 자신의 사설 IP와 포트 넘버
- 자신의 공인 IP와 포트 넘버 (STUN, TURN 서버로부터 획득 가능)
- TURN 서버의 IP와 포트 넘버 (TURN 서버로부터 획득 가능)

STUN

1. STUN(Session Traversal Utilities for NAT)

NAT 트래버셜 작업은 STUN(Session Traversal Utilities for NAT) 서버에 의해 수행된다.
STUN 방식은 단말이 자신의 공인 IP 주소와 포트를 확인하는 과정에 대한 프로토콜이다.
STUN 서버는 인터넷의 복잡한 주소들 속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환한다.
WebRTC 연결을 시작하기 전에 STUN 서버를 향해 요청을 보내면, STUN 서버는 NAT 뒤에 있는 피어(Peer)들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아준다.

2. TURM(Traversal Using Relay NAT)

네트워크 미디어를 중개하는 서버를 이용하는 것
STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우 대안으로 이용
P2P의 장점을 손실한다(미디어 품질이 떨어지고, 통신 대기 시간이 길어질 수 있다.)
높은 성공을 보장할 수 있다
서버 대역폭이 소모된다.
TURN 서버 자체는 일반적으로 자유롭게 액세스 할 수 없으며 애플리케이션 공급자가 자체적으로 구축해야 한다.

Signaling

Signalling_Architecture

RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정

WebRTC의 스펙이 아니기 때문에, 한 가지로 딱 정해진 방법이 없다.
두 장치가 언제 어떤 방식으로 연결될 수 있는지의 모든 경우를 예측하는 것이 불가능하기 때문이다.
시그널링 서버는 웹 소켓(Web Socket)이나 서버 전송 이벤트(Server-sent Event) 방법을 적용하는 방식을 고려해보자.
시그널링 정보를 조회할 수 있는 API를 만든 후 브라우저 단에서 주기적으로 XHR을 요청하는 폴링(polling) 기법도 가능하다.
서로 알지 못하는 당사 간 간의 연결을 위한 초기화 과정이다.
tl그널링 프로세스는 WebRTC 스펙에 명확하게 명시되어 있지 않다. 그래서, 개발자들은 자신만의 프로토콜을 선택해서 구현해야 한다

다양한 시그널링 조회 구현 방법 리파지 토리

1. ICE

두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크

ICE 프레임워크가 STUN, 또는 TURN 서버를 이용해 상대방과 연결 가능한 후보들을 갖고 있다
ICE는 P2P 통신 전에, 인터넷을 통해 피어 간의 연결을 설정하는 데 사용된다.
아래와 같은 옵션에서 오버헤드 가장 작은 경로가 선택 된다
- 직접 P2P 통신
- STUN 사용 및 NAT 트래버설 포트 매핑 사용 (결국, 직접 P2P 통신)
- TURN을 중개자로 사용 (P2P가 아닌 릴레이 통신을 사용)

1-2. Trickle ICE

비효율적인 후보 교환 작업을 병렬 프로세스로 수행할 수 있게 만드는 ICE의 옵션

두 개의 피어가 ICE 후보를 수집하고 교환하는 과정을, 동기적 프로세스 에서 비동기적 프로세스 로 만드는 기술이다.
각 피어에서 ICE 후보를 찾아내는 그 즉시 교환을 시작한다. 그래서 상호 간 연결 가능한 ICE를 보다 빨리 찾아낼 수 있다.
피어 간의 연결 상태를 체크함과 동시에 연결에 걸리는 시간을 최적화할 수 있다.

2. SDP(Session Description Protocol)

스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 사용되는 프로토콜

WebRTC에서 채택

웹캠 비디오의 해상도를 보낼 수 있고, 오디오 전송 또는 수신 여부등을 보낸다.
어떤 피어가 이러한 미디어 스트림을 교환할 것이라고 제안 을 하면, 상대방으로부터 응답 이 오기를 기다리는 제안 응답 모델(Offer/Answer)이다. (발행 구독 모델(Pub/Sub)과 유사)

직렬화된 SDP 데이터. JS에서 읽기 쉽게 보려면 별도의 라이브러리를 쓰는 것이 좋다. sdp-transform

포함하는 데이터
- 미디어 기능(비디오, 오디오) 및 사용된 코덱
- IP 주소 및 포트 번호
- P2P 데이터 전송 프로토콜(WebRTC는 SecureRTP 사용)
- 사용 가능한 통신용 대역폭(이름, 식별자 등) (단, WebRTC에서는 사용되지 않는다.)
- 기타 관련 메타데이터

SDP는 Session Initiation Protocol(SIP), Real-time Transport Protocol(RTP), Real-time Streaming Protocol(RSP)로서 널리 사용된다

시그널링 서버를 제공해주는 솔루션

직접 구축하는 것이 힘들다면 솔루션을 활용해보자

WebRTC를 구현하는 방법

adapter.js 라이브러리

webRTC의 여러 표준과 api중 가장 널리 사용되는 라이브러리이다. webRTC 오픈소스를 시작하고 컨트리뷰터인 구글이 만든 라이브러이다.여러 크로스 브라우징 이슈를 해결하고 벤더 프리픽스를 내부에서 제공하여 개발자가 신경쓸 필요 없게한다.

shim 패턴 및 polyfill을 이용해 다양한 브라우저에서 발생할 수 있는 크로스 브라우징 이슈를 사전에 처리
벤더 프리픽스를 신경 쓸 필요 없이 동일한 API를 호출할 수 있게 만들어 주기 때문에, 코드 컨벤션 유지와 개발 생산성 향상에서도 큰 도움을 준다.
NPM 패키지로도 제공

주요 API

webRTC_protocol_stack

WebRTC는 웹애플리케이션 실시간 통신을 위해서 아래와 같은 3개의 API에 의존한다.

1. getUserMedia

HTML5부터 제공하는 플러그인 설치 없이 카메라 또는 마이크를 사용할 수 있는 자바스크립트 API이다.

2. RTCPeerConnection

WebRTC 연결을 나타내며 두 피어 간의 효율적인 데이터 스트리밍을 처리하기 위해서 사용된다.

각 피어 간 연결의 전체 라이프사이클 관리
커넥션이 이루어지고 열리면, 미디어 스트림들 (MediaStream) 과 데이터 채널(RTCDataChannel)들을 커넥션에 연결할 수 있다.
모든 연결 설정 및 상태를 관리하기 위한 API를 사용하기 쉽게 인터페이스 내에 캡슐화해서 제공
브라우저간 직접 P2P 통신
UPD 통신

3. RTCDataChannel

피어간 데이터 교환 시 주요 통신 채널을 나타낸다.
데이터를 전송한다.(임의의 바이너리 데이터(이미지든 텍스트든 파일이든 모두 가능하다는 뜻)를 피어간 교환 가능)
“RTCDataChannel”는 웹소켓과 유사하지만, 사용자 지정 가능한 통신 속성을 제공하면서 P2P 형식을 사용한다는 차이점이 있다.

WebRTC Architecture

WebRTC_server

Uplink(나의 데이터를 연결된 다른 사용자에게 보내는 갯수)
Downlink(연결된 다른 사용자의 데이터가 나에게 들어오는 갯수)

P2P 연결로 3인, 4인 그리고 그 이상의 인원의 데이터 송수신을 지원하게 되면 클라이언트 측면에서의 과부하가 심하게 오기 때문에 권장하지 않는다. 이러한 문제의 해결책으로 나온 것이 SFU와 MCU 방식의 미디어 서버를 두는 것이다.

1. Signaling Server

peer 간의 offer, answer라는 session 정보 signal만을 중계하는 기본적인 방식이다.

1:1 연결에 적합하다.
N:N 혹은 N:M 연결에서 클라이언트의 과부하가 급격하게 증가한다.

2. SFU(Selective Forwarding Unit) Server

종단 간 미디어 트래픽을 중계하는 중앙 서버 방식

클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결
1:1, 1:N, N:N 혹은 N:M 등 모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보내면 된다.(즉, Uplink가 1개다.)
1:N, N:N 혹은 N:M 형식이라면 상대방의 수만큼 데이터를 받는 peer를 유지해야한다.(Downlink는 P2P(Signaling서버)일 때와 동일하다.)(대규모 N:M 구조에서는 여전히 클라이언트가 많은 부하를 감당)
1:N 형식 또는 소규모 N:M 형식의 실시간 스트리밍에 적합

3. MCU(Multi-point Control Unit) Server

다수의 송출 미디어를 중앙 서버에서 혼합(muxing) 또는 가공(transcoding)하여 수신측으로 전달하는 중앙 서버 방식

ex) 자신을 제외한 다른 사람의 video 데이터를 하나의 video 데이터로 편집하고, audio 데이터도 마찬가지로 편집하여 한 명에게 보낸다.

Uplink와 Downlink가 1개이다.
실시간성이 저해된다.
결합하는 과정에서 비용이 많이 든다.

미디어 중계서버 추천

1. Kurento

Kurento는 주로 WebRTC 기반의 실시간 미디어 처리와 스트리밍을 위한 오픈소스 미디어 서버이다. 주로 Java로 개발되어 있으며, 비디오 회의, 실시간 스트리밍, 비디오 필터링 및 녹화와 같은 기능을 제공한다. Kurento는 미디어 처리를 위해 다양한 기능을 제공하는 미디어 파이프라인을 구성할 수 있게 해준다. 예를 들어, 실시간 비디오와 오디오를 변환하거나 필터링하는 등의 작업을 쉽게 처리할 수 있다.

주요 특징:
- WebRTC 지원
- Java API 제공
- 비디오 필터링, 스트리밍, 녹화 등 다양한 미디어 처리 기능
- 멀티미디어 처리 및 전송에 강력한 성능

2. MediaSoup

MediaSoup은 WebRTC와 관련된 비디오 회의 및 멀티미디어 스트리밍을 위한 미디어 서버이다. 주로 Node.js 환경에서 사용되며, 낮은 레이턴시와 효율적인 데이터 처리에 강점을 가지고 있다. MediaSoup은 SFU(Selective Forwarding Unit) 구조를 사용하여, 클라이언트 간의 직접적인 P2P 연결 없이 서버가 중계 역할을 하도록 설계되어 있다. 이 방식은 다자간 회의에서 성능과 확장성에 유리하다.

주요 특징:
- SFU 구조로 다자간 회의 지원
- Node.js 기반
- 클라이언트 간의 직접적인 P2P 연결 없이 중계 서버를 통한 스트리밍
- 낮은 레이턴시 및 확장성

WebRTC 수행과정 정리

1. p2p 연결 단계_ICE

(1) 시그널링 서버만 이용해서 P2P 연결시도

(2) NAT등으로 방해받으면 STURN 사용

(3) 강력한 방해를 받으면 TURN 사용(P2P를 포기)

=> 이 과정이 끝나면 시그널링 서버를 이용해 SDP를 수행

2. 데이터 교환 단계_아래의 후보중 필요에 따라 구조를 구축

(1) 기본적으로는 P2P로 모두 1:1 연결

(2) 필요하면 SFU를 두어 N:M 수행

(3) MCU를 이용하여 Downlink를 1로 만들수도 있다.

추가지식

NAT Travesal Deepdive

UDP 홀펀칭

NAT Traversal 과정에서 STUN은 어떻게 NAT을 우회한다는 것일까? 그 방법이 UDP 홀펀칭이다.

UDP 홀펀칭은 NAT 뒤에 있는 두 클라이언트가 직접적으로 P2P 연결을 설정하기 위해 NAT의 매핑 특성을 활용하는 기술이다.
NAT는 기본적으로 외부에서 들어오는 패킷을 차단하지만, 클라이언트가 먼저 외부로 패킷을 보낸 경우 NAT 매핑을 유지한다. UDP 홀펀칭은 이 매핑 정보를 활용하여 두 클라이언트 간의 직접 연결을 가능하게 한다.

STUN은 클라이언트의 공인 IP 주소와 NAT 매핑된 포트를 확인해준다.
이 정보를 바탕으로 P2P 연결이 가능하도록 클라이언트 간 공인 IP와 포트를 교환할 수 있게 돕는다.
하지만 NAT 유형에 따라 홀펀칭이 실패할 수 있다.
TURN은 UDP 홀펀칭이 실패할 때 대체 방법으로 동작한다.

물론 TCP도 NAT뒤의 클라이언트 간의 P2P연결을 위해서는 TCP 홀펀칭이 필요하다 하지만 만일 NAT뒤에 서버가 있는 경우라면 홀펀칭보다 포트포워딩을 고려해보자

홀펀칭이 실패하는 경우

홀펀칭이 실패하는 경우는 주로 NAT의 유형이나 방화벽 설정과 관련이 있다. 다음은 UDP 홀펀칭이 실패할 수 있는 주요 원인들이다:

대칭형 NAT (Symmetric NAT) 대칭형 NAT은 클라이언트가 서로 다른 외부 서버에 요청할 때마다 다른 공인 IP와 포트를 매핑한다.
이는 클라이언트가 STUN을 통해 알아낸 공인 IP와 포트를 상대방 클라이언트에게 공유하더라도, 해당 정보를 사용해 직접 연결을 시도할 때 NAT가 이를 차단하게 만든다.
대칭형 NAT에서는 UDP 홀펀칭이 거의 불가능하며, TURN 서버를 통해 중계를 해야 한다.
엄격한 방화벽 설정 일부 네트워크 방화벽은 외부에서 들어오는 모든 UDP 트래픽을 차단하거나 특정 포트만 허용하도록 설정된다.
이 경우 클라이언트가 NAT 매핑을 통해 경로를 열어도 외부에서 들어오는 패킷이 방화벽에서 차단되어 홀펀칭이 실패한다.
NAT 매핑 테이블의 시간 초과 NAT 라우터는 매핑 테이블에 기록된 매핑 정보를 일정 시간 동안만 유지한다.
이 시간이 초과되면 NAT가 매핑 정보를 삭제하여 상대방의 데이터가 도착하지 못하게 된다.
홀펀칭을 성공시키기 위해서는 지속적으로 keep-alive 패킷을 보내 매핑을 유지해야 한다.
양쪽 모두가 대칭형 NAT인 경우 홀펀칭은 NAT 매핑 정보가 다른 클라이언트에 의해 사용 가능해야 하는데, 양쪽 클라이언트가 모두 대칭형 NAT일 경우, NAT 매핑 정보가 서로 호환되지 않아 연결이 불가능하다.
중간 네트워크에서 UDP 차단 일부 네트워크(예: 회사 또는 공공 Wi-Fi)는 UDP 프로토콜을 비활성화하거나 제한할 수 있다.
이 경우 UDP 트래픽이 완전히 차단되어 STUN을 통한 홀펀칭 시도 자체가 실패한다.
클라이언트의 NAT가 동일한 공인 IP를 공유하지 않는 경우 같은 네트워크 안에서 NAT를 공유하지 않는 클라이언트들이 공인 IP가 다를 경우, 내부 매핑 정보가 불일치해 연결이 실패할 수 있다.

WebRTC 이외에 P2P 연결의 대안

WebRTC는 P2P 통신을 위한 강력한 도구이지만, 특정 상황에서는 WebRTC 이외의 P2P 연결 대안을 고려할 수 있다. 다음은 WebRTC 외에 사용 가능한 P2P 연결 대안들이다:

1. Socket Programming

전통적인 소켓 프로그래밍을 사용하여 P2P 연결을 직접 구현하는 방법이다.
UDP 또는 TCP를 이용해 사용자 간 통신 경로를 수동으로 설정한다.
게임 서버나 사설 네트워크 통신.

2. Libp2p

IPFS(InterPlanetary File System)에서 사용되는 네트워크 라이브러리로, P2P 통신을 효율적으로 구현할 수 있다.
다양한 프로토콜을 지원하며, 확장성과 유연성이 뛰어나다.
다중 전송(Transport) 지원: TCP, UDP, WebSocket 등.
NAT Traversal과 같은 네트워크 문제를 자동으로 처리.
암호화와 인증 내장.
초기 학습 곡선이 가파르다.
일부 환경에서 설정이 복잡할 수 있다.
분산 파일 저장 시스템(IPFS), 블록체인 기반 애플리케이션에서 사용

3. Torrent Protocol (BitTorrent)

파일 공유를 위해 개발된 P2P 프로토콜로, 데이터 분산 및 전송에 최적화되어 있다.
실시간 통신에는 적합하지 않음.
트래커(tracker)와 같은 중앙 서버를 필요로 할 수 있다.
파일 공유 서비스(예: µTorrent, Transmission), 분산 네트워크에서의 대용량 데이터 전송에 사용

4. PeerJS

WebRTC의 기본적인 기능을 추상화한 라이브러리로, 간단한 P2P 연결을 제공한다.
데이터 채널 및 미디어 스트림 전송을 지원한다.

5. Custom Protocols over UDP/TCP

특정 목적에 맞는 P2P 통신 프로토콜을 설계하고, UDP 또는 TCP 위에서 동작하도록 구현한다.
완전한 커스터마이징 가능.
특정 도메인에 최적화된 동작 구현 가능.

6. Distributed Hash Table (DHT)

P2P 네트워크에서 데이터를 분산 저장하고 검색할 수 있는 구조를 제공한다.
분산된 노드 간의 라우팅 정보를 관리한다.
중앙 서버 없이 노드 검색과 데이터 공유 가능.
실시간 통신보다는 데이터 검색과 전송에 적합.
분산 데이터베이스. - BitTorrent의 트래커리스 모드에 사용

대안 선택 시 고려 사항

실시간성: 실시간 통신이 필요하다면 WebRTC, PeerJS, 또는 커스텀 UDP/TCP가 적합하다.
확장성: 대규모 네트워크를 지원하려면 DHT나 Libp2p가 유리하다.
복잡성: 간단한 구현이 필요하면 PeerJS나 WebRTC를 선택한다.
NAT Traversal 문제: TURN 서버나 대칭형 NAT 지원 여부를 검토해야 한다.

VoIP(Voice over IP)

VoIP(Voice over IP)는 인터넷을 통해 음성 데이터를 전송하는 기술을 뜻하며, API보다는 통신 기술의 한 유형에 가깝다. VoIP는 음성을 디지털 데이터로 변환하여 IP 네트워크(예: 인터넷)를 통해 송수신하는 방식이다. WebRTC와는 개념과 역할이 다르며, VoIP는 기술의 범주이고, WebRTC는 이를 구현할 수 있는 하나의 프레임워크나 API라고 할 수 있다.

역할과 주요 특징

기능
- VoIP는 음성 통화를 인터넷 프로토콜을 통해 전달한다.
- 기존 전화망(PSTN) 대신 인터넷을 활용하여 통화비용을 절감한다.
- 주로 SIP(Session Initiation Protocol), RTP(Real-Time Transport Protocol), SDP(Session Description Protocol) 등의 프로토콜을 사용한다.
예시
- Skype, Zoom, Microsoft Teams, Discord와 같은 음성 통화 서비스.
- WebRTC 기반 통신도 VoIP의 범주에 포함될 수 있다.
기술 구조
- 음성 데이터를 패킷 단위로 분할하여 전송하고, 수신 측에서 패킷을 재조립한다.
- 네트워크 지연과 손실을 최소화하기 위해 실시간 전송을 위한 QoS(Quality of Service) 기술을 적용한다.

VoIP와 WebRTC의 관계

WebRTC는 VoIP 기술을 포함할 수 있다. 예를 들어, WebRTC를 이용해 브라우저 간에 실시간 음성 통화를 구현하면 이는 VoIP의 일종이다.
VoIP는 브라우저 외의 환경에서도 사용할 수 있으며, 전통적인 SIP 기반 VoIP 시스템은 브라우저와 무관하게 동작한다.

VoIP는 음성 데이터를 인터넷으로 전송하는 기술이며, WebRTC는 이를 포함한 실시간 통신을 구현하는 API로 이해하면 된다. VoIP는 특정 API나 라이브러리가 아니라 기술적인 개념이며, 다양한 방식(SIP, RTP 등)으로 구현될 수 있다. WebRTC는 VoIP 외에도 영상, 데이터 전송까지 다룰 수 있는 더 포괄적인 실시간 통신 프레임워크이다.

WebRTC란 무엇인가