WebRTC 기반 서비스를 지원하기 위한 서버의 종류

WebRTC

웹 어플리케이션 및 사이트들이 별도의 소프트웨어 없이 음성, 영상, 텍스트, 파일 데이터를 브라우저끼리 주고 받을 수 있게 만든 기술

cf.

• Mozilla WebRTC

• How Discord handles two and half Million concurrent voice users using WebRTC

---

WebRTC Servers

WebRTC는 미디어 스트림을 양단의 유저 간 주고받을 수 있게 하는 기술. 이 WebRTC를 이용해서 다자간 음성 또는 화상 채팅을 하기 위해서는 어떤 서버들이 필요할까

• 크게 4가지 종류의 서버가 필요
  • WebRTC Servers

1. 애플리케이션 서버

• 웹 사이트를 호스팅하기 위한 서비스
• 우리에게는 Vue와 별도의 마이크로서비스들이 사이트를 호스팅하기 위한 서비스

---

2. 시그널링 서버

• 사용자 간의 연결을 지원하기 위한 서버
• WebRTC는 다른 사용자와 미디어 스트림을 전송하기 위해 SDP를 생성
• 시그널링 서버가 이 SDP를 전달
  • SDP (Session Description Protocol)
    • WebRTC가 세션의 정보 전달 및 제어를 위해 사용
• WebSocket을 통해 구현 가능
  • Spring WebSocket

WebRTC 통신 원리

크게 3가지 클래스에 의해 실시간 데이터 교환이 이루어짐

• MediaStream - 카메라/마이크 등 데이터 스트림 접근
• RTCPeerConnection : 암호화 및 대역폭 관리 및 오디오 또는 비디오 연결
• RTCDataChannel - 일반적인 데이터 P2P통신

1. A가 MediaDevices.getUserMedia를 사용하여 로컬 미디어를 캡처한다.
2. A는 RTCPeerConnection을 생성하고 다른 피어로 전송될 트랙에 새 미디어 트랙을 추가하는 RTCPeerConnection.addTrack()을 호출한다.
3. A는 offer 생성을 위한 RTCPeerConnection.createOffer()를 호출한다.
4. A는 RTCPeerConnection.setLocalDescription()를 호출하여 본인의 local description으로 offer를 저장한다.
5. setLocalDescription()후에, STUN server에게 ice 후보자 생성을 요청한다.
6. A는 시그널링 서버를 사용하여 B에게 offer를 전송한다.
7. B는 offer를 받고, 이것을 RTCPeerConnection.setRemoteDescription()을 호출해 remote description으로 기록한다.
8. B는 로컬 미디어를 캡처하고 각 미디어 트랙을 RTCPeerConnection.addTrack()을 호출하여 피어 연결에 첨부한다.
9. 그 후, B는 RTCPeerConnection.createAnswer()를 호출하여 Answer를 만든다.
10. B는 RTCPeerConnection.setLocalDescription()를 호출하여 본인의 local description으로 Answer를 저장한다. 이제 B는 양쪽의 구성을 알게된다.
11. B는 시그널링 서버를 통해 A에게 Answer를 보낸다.
12. A는 Answer를 받는다.
13. A는 RTCPeerConnection.setRemoteDescription()를 호출해 remote description으로 기록한다. 이제 두 Peer 모두 구성을 알고 있고, 시작된다.

• 시그널링 서버는 세션을 설정하기 위해 메세지를 전달

• 크게 4가지 프로토콜이 주로 사용된다.

  • SIP : The dominant telecom VoIP protocol out there. When used with WebRTC, it is done as SIP over WebSocket. CPaaS and telecom vendors end up using it with WebRTC, mostly because they already had it in use in their infrastructure
  • XMPP : A presence and messaging protocol. Some of the CPaaS vendors picked this one for their signaling protocol
  • MQTT – Messaging protocol used mainly for IOT (Internet of Things). First time I’ve seen it used with WebRTC was Facebook Messenger, which makes it a very popular/common/widespread signaling server for WebRTC
  • Proprietary : the most common approach of all, where people just implement or pick an alternative that just works for them

• cf.

  • Mozila - Singaling and Video Calling
  • 시그널링 서버 관련 포스트 1
  • 시그널링 서버 관련 포스트 2 - 클라이언트 코드 포함

---

3. NAT traversal 서버

• WebRTC에서 여러 세션을 올바르게 연결하려면 NAT traversal이 중요
• 사용자가 한 브라우저에서 다른 브라우저로 미디어를 보낼 수 있는지 확인하는 역할을 담당
• NAT 서버에는 STUN과 TURN의 두 가지 유형이 필요
  • TURN 서버는 STUN서버를 포함

STUN

STUN은 자신의 공용 IP 주소가 무엇인지 확인한 다음, 세션의 다른 사용자와 답변을 공유하기 위해 사용되므로 해당 주소를 사용하여 미디어를 직접 보낼 수 있음

TURN

TRUN은 미디어를 릴레이(전달)하는 데 사용됨(bandwidth cost 증가). 실제로 다른 사용자와 직접 연결할 수 없을 때 사용

• cf.
  • ICE
  • • STUN, TUNR 서버 설명 잘 나옴 - The technology that powers Google Meet/Hangout, Facebook Messenger and Discord
  • coturn 설치 방법
  • TURN 서버 설치 확인

4. 미디어 서버

• WebRTC는 기본적으로 P2P 방식으로 동작하는데 1:1인 경우 크게 상관어 없지만 다자간 통신을 하는 경우 아래 그림처럼 작동

  • Mesh Networking

    

• 이용자가 증가하면 증가할수록 피어가 많아지기 때문에 다자간 커뮤니케이션을 지원하기 위해 미디어 서버를 활용

SFU

• SFU 방식은 중앙 서버를 통해 종단간 미디어 트래픽을 중계하는 중앙 서버 방식
• 사용자들로부터 각각의 미디어 스트림을 받아 매 순간마다 선택적으로 전달하는 라우팅 머신 역할의 중간 서버(미디어 서버)를 배치
• 중간 서버에서는 별도의 미디어 가공 과정을 거치지 않고 그대로 각 사용자들에게 전달하며, 각 피어간 연결 할당·암호화 및 복호화 처리 비용 정도를 감수
• 비교적 서버에 부하가 적게 걸리고 지연시간 역시 낮기에 영상 방송과 같은 1:N 스트리밍 서비스, 혹은 조금 더 확장하여 N:N 소통에 활용

MCU

• MCU 방식은 각 참여자의 미디어 스트림을 중앙 서버에 한꺼번에 모아 믹싱한 후, 그 결과물을 다시 각각의 참여자들에게 전달

• 다수 참여자의 송출 미디어를 중앙 서버에서 가공하여 수신단으로 전달하는 방식이기 때문에 클라이언트와 네트워크의 트래픽이 줄어드나 서버의 부담이 증가(CPU 사용량 증가)

• cf.

  • Mesh vs. SFU vs. MCU

미디어 서버 종류

• Kurento

• mediasoup

• Jitsi

• Janus WebRTC Server

• Ant Media

• cf.

  • 미디어 서버 관련 포스트

cf.

• Spring WevRTC Baeldung