WebRTC
- Web Real-Time Communication
- 웹 애플리케이션과 사이트가 별도의 중간 단계 없이 브라우저 간에 오디오나 영상 미디어를 스트리밍 해주고나, 임의의 데이터도 교환할 수 있도록 하는 기술이다.
- 별도의 중개 서버 없이 peer to peer 데이터 공유와 화상 회의를 가능하게 한다.
MediaStream(GetUserMedia)
- javascript 사용하여 카메라 및 마이크 장치에 접근 및 제어를 할 수 있는 방법을 제공한다.
RTCPeerConnection
- 중개 서버 없이 Peer to Peer 가능하게 해준다.(peer와 직접 연결 생성해줄 수 있는 방법 제공)
- 이 과정에서 PeerConnection API는 SDP negotiation, codec 구현, NAT Traversal, 패킷 손실, 대역폭 관리 및 미디어 전송 처리를 한다.
RTCDataChannel
- peer와 나 사이에 모든 유형의 데이터 양방향 전송이 가능하게 한다.
- WebSocket API와 다르게 TCP 연결 대신 UDP 기반 스트림을 사용한다.
시그널링(연결과정)
- Peer to Peer 화상 통화 하기 전 클라이언트 간의 연결 설정한다.
- 두 개의 엔드포인트가 있으면 한쪽이 전화를 해야 하고 한쪽은 응답해야한다.
- 이땐, 발생할 스트리밍에 대한 중요한 세부정보(스트림 수 및 유형, 미디어 인코딩 방법 등)가 포함되어 있다.
- 표준 형식인 SDP 사용한다.
SDP?
세션 기술 프로토콜(Session Description Protoco)
인터넷에 연결된 인프라(서버, 라우터 등) 숨기는 방식
- 시그널링이 발생하면 두 엔드포인트는 NAT(Network Address Translation) 통과 프로세스를 거쳐야 한다.
- NAT가 사설망 내 컴퓨터에 공융 주소를 할당하면 실시간 비디오 연결 설정에 어려움이 있을 수 있다.
NAT Traversal
- IP주소 변환과 관련된 문제를 해결하는 방법
- 일반적으로 두 엔드포인트가 동일한 로컬 네트워크에 있지 않으면 둘 사이에 하나 이상의 네트워크 장치 (라우터 혹은 게이트웨이)가 있어야 하는데, 이를 극복하기 위해 WebRTC는 다음과 같은 세 가지 주요 기술을 사용한다.
ICE (Interactive Connectivity Establishment), ICE Candidate
- 두 클라이언트가 통신할 수 있는 경로를 모두 찾아 최적의 경로를 찾아준다. 이 과정에서
STUN과TURN두 개의 프로토콜을 사용한다.
1. STUN (Session Traversal Utilities for NAT)
- NAT 용 Session Traversal Utilities이며 WebRTC 클라이언트가 STUN 서버에 요청하여 자신의 공용 IP 주소를 찾을 수 있도록 한다.
2. TURN (Traversal Using Relay NAT)
- Peer 간에 직접 통신이 실패할 경우 데이터를 연계하여 통신을 가능하게 하는 서버이다.
Peer-to-Peer 토폴로지는 WebRTC에서 다루는 유일한 연결 유형이지만 다자간의 영상통화에는 좋지 않은 연결 유형이다.
WebRTC 토폴로지 (연결 유형)
- 다자간의 영상통화를 위해 서버 기반 토폴로지를 사용한다.
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로 전환할 수 있다.
참고자료
https://dont-stay-hungry.tistory.com/23
https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API
https://webrtc.github.io/samples/
