WebRTC는 Web Real-Time Communication의 약자로, 웹 브라우저에서 별도의 플러그인이나 프로그램 설치 없이 실시간으로 음성, 영상, 데이터를 주고받을 수 있도록 해주는 기술
WebRTC의 특징
- 실시간 통신: 낮은 지연 시간으로 실시간 음성, 영상 통신을 가능하게 합니다.
- P2P 연결: 중앙 서버를 거치지 않고 브라우저 간 직접 연결하여 더욱 빠르고 안정적인 통신을 제공합니다.
- 다양한 기능: 음성/영상 통화, 화면 공유, 파일 전송 등 다양한 기능을 지원합니다.
- 오픈 소스: 누구나 자유롭게 사용하고 수정할 수 있는 오픈 소스 기술입니다.
플러그인 불필요: 별도의 플러그인 설치 없이 웹 브라우저만으로 이용 가능합니다.
WebRTC가 사용되는 분야
- 화상 회의: Zoom, Google Meet 등 화상 회의 서비스
- 온라인 교육: 실시간 강의, 튜터링
- 원격 지원: 원격으로 사용자의 화면을 보면서 지원
- 게임 스트리밍: 게임 화면을 실시간으로 스트리밍
- 채팅 앱: 실시간 텍스트 채팅, 음성 채팅
- IoT 기기 제어: 웹 브라우저를 통해 IoT 기기를 제어
간략한 WebRTC의 작동 원리
- ICE (Interactive Connectivity Establishment): 브라우저 간 최적의 연결 경로를 찾습니다. - (프레임워크 또는 프로토콜 이다.) (홀펀칭이나 TURN 서버 같은 통신 방식에 필요한 "재료")
- STUN (Session Traversal Utilities for NAT): NAT(Network Address Translation) 환경에서도 통신이 가능하도록 합니다.
- TURN (Traversal Using Relays around NAT): STUN으로 연결이 불가능할 경우(네트워크 방화벽 또는 복잡한 NAT환경일 경우) 중계 서버를 이용하여 연결합니다.
p2p방식에서 직접 통신이 불가능 할 경우 turn서버의 중계를 통해 통신하는것과 유사하게 1:N, N:N통신이 필요할 경우 사용되는 미디어서버가 존재한다면 피어는 시그널 서버를 통해 미디어 서버의 통신규격및 네트워크주소등을 전달받고 피어가 미디어 서버와 직접통신을 하게된다.
● ICE: 연결을 위한 전체적인 프레임워크
● ICE Candidate: ICE 프레임워크가 사용하는 통신 경로 후보 정보
- 호스트 후보(Host Candidate): 기기의 로컬 IP 주소와 포트입니다. 가장 직접적인 경로이지만, 방화벽이나 NAT 뒤에 있으면 사용할 수 없습니다.
- 서버-리플렉스 후보(Server-Reflexive Candidate): STUN 서버를 통해 NAT 외부에서 보이는 공용 IP 주소와 포트입니다.
스마트폰이 Wi-Fi 공유기 뒤에 있을 때, 외부에서 보이는 공용 IP가 이 후보에 해당합니다.- 릴레이 후보(Relay Candidate): TURN 서버를 통해 데이터를 중계하는 공용 IP 주소와 포트입니다.
두 피어가 직접 연결될 수 없는 경우, TURN 서버가 중개자 역할을 하여 데이터를 주고받게 합니다.
● 홀펀칭 / TURN 서버: ICE가 실제로 사용하는 구체적인 통신 방식
WebRTC를 사용하는 이유
- 개발 편의성: 복잡한 네트워크 통신 프로토콜을 직접 구현하지 않아도 됩니다.
- 확장성: 다양한 기능을 추가하여 맞춤형 서비스를 구축할 수 있습니다.
- 보안: WebRTC는 보안에 대한 고려가 많이 되어 있어 안전하게 사용할 수 있습니다.
- 미래 지향적: 웹 기술의 발전과 함께 WebRTC 역시 지속적으로 발전하고 있습니다.
WebRTC 어플리케이션 수행단계
- Fetching : 상대 peer 에게 보낼 사용자의 음성 및 영상 데이터를 수집합니다.
- Signaling : 이 세상 어딘가에 있는 상대 peer 와 연결을 맺기 위해서, 상대 peer 의 정보를 탐색합니다.
- Connection : 발견한 peer 와 p2p connection 을 맺습니다. channel 을 개방해둡니다.
- Communication : 개방해놓은 채널을 통해 음성/영상/텍스트 데이터를 주고 받습니다.
미디어 서버에서 사용되는 네트워킹 방식
미디어 서버에서 실시간 음성/영상 통신을 구현하기 위해 다양한 네트워킹 방식이 사용됩니다. 대표적인 방식으로 Mesh, SFU, MCU를 들 수 있습니다.
1. Mesh Networking (메시 네트워킹)
- 개념: 모든 클라이언트가 서로 직접 연결되어, 각 클라이언트가 다른 모든 클라이언트와 P2P 방식으로 미디어를 주고받는 방식입니다.
장점:
서버 부담이 적다.
네트워크 지연이 적어 실시간성이 높다.
단점:
참여자가 많아질수록 네트워크 트래픽이 급증하여 성능 저하가 발생할 수 있다.
NAT 문제, 방화벽 문제 등 네트워크 환경에 민감하다.
특정 클라이언트의 네트워크 상태가 나쁠 경우 전체 시스템의 성능에 영향을 미칠 수 있다.
2. SFU (Selective Forwarding Unit)
- 개념: 중앙 서버가 각 클라이언트의 미디어 스트림을 받아서 필요한 클라이언트에게만 전달하는 방식입니다.
장점:
Mesh 방식에 비해 네트워크 트래픽을 줄일 수 있다.
서버에서 미디어 믹싱, 트랜스코딩 등의 작업을 수행할 수 있다.
네트워크 환경에 대한 의존도가 낮다.
단점:
서버 부담이 Mesh 방식에 비해 크다.
서버 장애 발생 시 서비스 전체가 중단될 수 있다.
3. MCU (Multi-point Control Unit)
- 개념: 모든 클라이언트의 미디어 스트림을 수집하여 하나의 스트림으로 믹싱한 후 모든 클라이언트에게 전달하는 방식입니다.
장점:
하나의 스트림만 관리하면 되므로 서버 부담이 상대적으로 적다.
다양한 미디어 처리 기능을 제공할 수 있다.
단점:
실시간성이 떨어질 수 있다.
모든 클라이언트에게 동일한 품질의 스트림이 전달된다.
서버 장애에 대한 취약성이 높다.
※ 각 방식의 적용 사례
- Mesh: 소규모 화상 회의, 게임 등 낮은 지연 시간이 중요하고, 참여자가 적은 경우에 적합합니다.
- SFU: 중규모 화상 회의, 웹 세미나 등 다양한 기능이 필요하고, 안정적인 서비스 제공이 중요한 경우에 적합합니다.
- MCU: 대규모 웹캐스팅, 방송 등 많은 수의 시청자가 동시에 접속하는 서비스에 적합합니다.
이미지 출처 : https://post.naver.com/viewer/postView.naver?volumeNo=29147132&memberNo=50640104
