Web Real-Time Communication
웹, 앱 서비스에서 별 다른 소프트웨어 없이 카메라, 마이크 등을 사용해서 실시간 커뮤니케이션을 제공해주는 기술
⇒ 화상통화, 화상 공유 등을 구현 할 수 있는 오픈소스이다.
✨ 특징
Javascript API로 제공한다.
비디오, 음성 및 일반 데이터가 P2P(peer 2 peer) 방식으로 전송되도록 지원한다.
⇒ 기존의 WebSocket과 SocketIO의 경우 반드시 서버를 통해 데이터를 전달하고 받는 과정이 필요!
👍 장점
1️⃣ 지연시간이 짧다.
인스타라이브, 유튜브라이브, 트위치 등은 RTMP를 사용하여 실시간 스트리밍을 하고 있다.
WebRTC는 RTMP보다 낮은 지연시간을 가지고 있고, 지연시간이 없는 Real-Time과 비슷한 방송을 할 수 있다.
지연시간(Latency) ?
하나의 데이터 패킷을 한 지점에서 다른 지점으로 보내는데 소요되는 시간을 표현한 것
2️⃣ 별 다른 소프트웨어 없이 실시간 커뮤니케이션이 가능하다.
별도의 플러그인이나 미디어 송출 관련 소프트웨어를 따로 설치할 필요가 없다.
👎 단점
1️⃣ 크로스 브라우징 문제가 있을 수 있다.
Chrome, Opera, Firefox 뿐만 아니라 안드로이드, IOS 등 브라우저, 앱에서 활용할 수 있으나,
사람들이 잘 사용하지 않는 브라우저나 최신 버전을 사용하지 않는 사용자는 사용이 불가능하다.
EX) Internet Explorer ⇒ 지원종료
2️⃣ STUN/TURN 서버가 필요하다.
P2P 통신을 하기 위해서는 사용자의 IP주소를 알아야한다. 하지만, 대부분의 사용자는 방화벽을 사용한다.
⇒ 다른 네트워크 상에서 연결이 이루어지기 위해서는 STUN/TURN 서버가 꼭 필요하다.
⚙️ 서버의 종류
🚥 Signaling (Full-Mesh)
서버를 통해 통신 정보를 주고 받고 peer 끼리 직접 연결되는 방식
✨ 특징
peer 간의 offer, answer(session 정보) signal을 서버가 중계한다.
⇒ peer 간의 연결 정보만 중계 하기 때문에 연결 후에는 서버에 부하가 없다.
⇒ 1 : 1 연결에 적합하다.
👍 장점
서버의 부하가 적어 서버 자원이 적게 든다.
peer간의 직접 연결로 데이터를 송수신하기 때문에 실시간성이 보장된다.
👎 단점
peer간의 직접 연결로 데이터를 송수신하기 때문에 연결이 많아질 경우 클라이언트의 과부하가 급격하게 증가한다.
🖥 SFU (Selective Forwarding Unit)
하나의 중앙 서버에서 모든 스트림 데이터를 관리하는 방식
✨ 특징
클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결한다.
1:1, 1:N, N:N, N:M 등 모든 연결 형식에서 클라이언트는 서버에게만 자신의 영상 데이터를 보내면 된다.
하지만, 상대방의 수만큼 데이터를 받는 peer를 유지해야한다. (Down은 p2p와 동일)
⇒ 1:N, 소규모 N:M 형식의 실시간 스트리밍에 적합하다.
👍 장점
데이터가 서버를 거치기 때문에 p2p보다 느리지만, 비슷한 수준의 실시간성을 유지한다.
클라이언트가 받는 부하가 줄어든다.
👎 단점
서버 비용이 증가한다.
대규모 N:M 구조에서는 여전히 클라이언트가 많은 부하를 감당한다.
🍔 MCU (Multi-point Control Unit)
다수의 송출 미디어를 중앙 서버에서 혼합/가공해서 클라이언트에게 전달하는 중앙서버 방식
⇒ 5명이 연결한다면 4명의 비디오 정보를 하나의 데이터로 편집하여 전송한다.
✨ 특징
클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결한다.
1:1, 1:N, N:N, N:M 등 모든 연결 형식에서 클라이언트는 서버에게만 자신의 영상 데이터를 보내면 된다.
클라이언트는 연결된 사용자 수와 상관없이 서버에게 하나의 peer로 데이터를 받으면 된다.
⇒ 중앙 서버의 높은 컴퓨팅 파워가 요구된다.
👍 장점
클라이언트가 받는 부하가 현저히 줄어든다.
N:M 구조가 가능하다.
👎 단점
WebRTC의 최대 장점인 실시간성이 저해된다.
video, audio를 결합하는 과정에서 비용이 많이 든다.
📚 Reference
