[WebRTC API] WebRTC 초보자 가이드

WebRTC 간단 소개

• 브라우저에서 오디오, 비디오와 같은 미디어 장치를 포착하여 타 브라우저에 스트림 할 수 있을 뿐만 아니라 데이터 통신도 지원하는 기술이다.
• 별도의 중개 서버 없이 peer to peer 데이터 공유와 화상 회의를 가능하게 한다.
• 상호 연관된 API와 프로토콜로 구성되어 작동한다.
  
  
  

WebRTC API

* WebRTC API에는 3가지 주요 구성 요소가 있으며 고유한 역할을 한다.

1. MediaStream (GetUserMedia)

• MediaStream API는 JavaScript 를 사용하여 카메라 및 마이크 장치에 접근 및 제어를 할 수 있는 방법을 제공한다.

2. RTCPeerConnection

• 참가자들이 중개 서버 없이 peer와 직접 연결을 생성할 수 있는 방법을 제공한다. MediaStream API를 사용하여 얻은 미디어 정보로 peer에 연결한다. 이 과정에서 PeerConnection API는 SDP negotiation, codec 구현, NAT Traversal, 패킷 손실, 대역폭 관리 및 미디어 전송 처리를 한다.

3. RTCDataChannel

• peer와 나 사이에 모든 유형의 데이터 양방향 전송이 가능하게 한다. WebSocket API와 다르게 TCP 연결 대신 UDP 기반 스트림을 사용한다.
  
  
  

연결 과정

* Peer To Peer 화상 통화를 하기 전에 클라이언트 간의 연결을 설정한다.

* 시그널링이라고 하는 이 연결은 webRTC의 스펙은 아니지만 클라이언트간 미디어 연결을 하게 도와주는 중요한 역할을 한다.

시그널링

• 두명의 클라이언트 (두 개의 엔드포인트)가 화상 통화를 시작하려면 한쪽이 전화를 해야 하고 한쪽은 응답을 해야 한다.
• 이 제공-응답 메시지 흐름의 과정에는 발생할 스트리밍에 대한 중요한 세부 정보 (스트림 수 및 유형, 미디어 인코딩 방법)가 포함되어 있다.
• 표준 형식인 SDP (Session Description Protocol)를 사용한다.

NAT Traversal, ICE candiate, TURN, STUN

• 시그널링이 발생하면 두 엔드포인트는 NAT (Network Address Translation) 통과 프로세스를 거처 야한다.
• NAT가 사설망 내 컴퓨터에 공융 주소를 할당하면 실시간 비디오 연결 설정에 어려움이 있을 수 있다.
• NAT Traversal은 IP주소 변환과 관련된 문제를 해결하는 방법이다.
• 일반적으로 두 엔드포인트가 동일한 로컬 네트워크에 있지 않으면 둘 사이에 하나 이상의 네트워크 장치 (라우터 혹은 게이트웨이)가 있다.
• 이를 극복하기 위해 WebRTC는 다음과 같은 세 가지 주요 기술을 사용한다.
  
  

1. ICE (Interactive Connectivity Establishment) 혹은 ICE Candidate

• 두 클라이언트가 통신할 수 있는 경로를 모두 찾아 최적의 경로를 찾아준다. 이 과정에서 STUN과 TURN 두 개의 프로토콜을 사용한다.

2. STUN (Session Traversal Utilities for NAT)

• NAT 용 Session Traversal Utilities이며 WebRTC 클라이언트가 STUN 서버에 요청하여 자신의 공용 IP 주소를 찾을 수 있도록 합니다.

3. TURN ( Traversal Using Relay NAT)

• Peer 간에 직접 통신이 실패할 경우 데이터를 연계하여 통신을 가능하게 하는 서버이다.
  
  
  

WebRTC 토폴로지 (연결 유형)

* Peer-to-Peer 토폴로지는 WebRTC에서 다루는 유일한 연결 유형이지만 다자간의 영상통화에는 좋지 않은 연결 유형이다.

* 서버 기반 토폴로지를 사용하여 이러한 단점을 해결할 수 있다.

* WebRTC를 사용하는 애플리케이션에서 사용하는 연결 유형은 대표적으로 아래와 같은 4가지가 있다.

1. Peer to Peer (Mesh)

• 연결된 클라이언트는 서버를 사용하지 않고 든 참여자에게 직접 연결된다.
• 비용이 낮고 설정이 쉬우며 소규모 화상회의에 적합하다.
• 참여자가 많아질수록 CPU 부하와 network traffic이 심해진다.
• 녹화 같은 서버가 필요한 기능을 사용할 수 없다.

2. Selective Forwarding (SFU)

• 각 참가자는 암호화된 스트림을 서버에 업로드한 후 서버가 스트림을 다른 참가자 각각에게 전달한다.
• 서버로의 업로드 효율성은 좋지만 참여자가 많아질수록 증가하는 다운로드 스트림에 의해 클라이언트 리소스가 부족하게 될 수 있다.

3. Multipoint Control (Mixing)

• 각 참가자로부터 미디어를 수신하고 이를 단일 스트림으로 믹싱 다음 각 참가자에게 전송된다.
• 단일 스트림으로 믹싱 처리하는 서버와 이에 맞는 CPU가 필요하다.
• 클라이언트는 대역폭 사용량과 CPU가 덜 필요하다

4. Hybrid Topology

• 사용자 수나 원하는 기능에 따라 Peer to Peer, SFU, MCU를 혼합해서 사용할 수 있다.
• 예를 들어 비용이 중요하다면 Peer to Peer를, 기록이 중요한 경우 SFU로 전환을, 대규모 방송인 경우 MCU로 전환할 수 있다.
  
  
  

WebRTC API 샘플 코드 링크

• https://webrtc.github.io/samples/

WebRTC samples

 

 

참고자료 :

https://www.frozenmountain.com/ultimate-guide-to-webrtc

https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API