1.WebRTC 란?
Web Real-Time Communications
웹 기반의 실시간 음성, 영상 통신 기술.
별도의 플러그인이나 소프트웨어 없이 통신할 수 있도록 설계된 API.
브라우저 간 실시간 미디어 통신에 최적화된 기술.
2.WebRTC 종류
1. Mesh
- P2P 방식 : 서버 없이 브라우저 간의 직접적인 연결을 가능하게 해준다.
- 중앙 서버의 부하가 적고, 지연 시간이 가장 적다.
- 참여자가 많아질수록 클라이언트의 부담이 커진다.
- UDP ( User Datagram Protocol )로 동작하기 때문에 NAT ( Network Address Translation )을 거치게 된다면, 상대방의 주소를 정확히 알 수 없다. 이에따라 STUN & TURN Sever가 필요하다.
(모든 클라이언트가 직접 연결되어야 하기 때문에 항상 필요하다.)
2. MCU (Multipoint Control Unit)
- 중앙 집중형 구조
- 각 클라이언트가 MCU 서버와만 연결되며, MCU 서버가 모든 데이터를 처리한다.
- 클라이언트의 부담은 매우 줄어들지만, 서버의 부하가 커진다.
- 중앙 서버를 거치기 때문에 지연 시간이 증가할 수 있다.
- 클라이언트들이 직접적으로 연결되지 않기 때문에, 통신은 주로 TCP를 통해 이루어진다.
NAT 문제를 신경 쓸 필요가 없기 때문에 TURN/STUN 서버가 불필요하다.
(단순 중계가 아닌 MCU 서버가 데이터를 처리하기 때문에 TCP 통신을 사용함으로 필요가 없다.)
3. SFU (Selective Forwarding Unit)
- 중앙 집중형 구조
- MCU와 달리, SFU는 미디어 스트림을 수정하거나 혼합하지 않고, 단순히 전달만 한다.
- MCU에 비해 서버 부하가 적고, 지연 시간도 적다.
- 클라이언트와 SFU 서버간의 연결은 P2P 연결처럼 동작하기 때문에 TURN/STUN 서버가 필요할 수 있다.
(단순 중계이기 때문에 UDP를 사용하고, 클라이언트가 NAT이나 방화벽 뒤에 있는 경우 필요할 수 있다.)
3. WebRTC - Mesh
3.1 Signaling Server
WebRTC 기반의 애플리케이션에서 클라이언트 간의 연결 설정 및 메타 데이터 교환을 담당하는 중개 서버.
연결하고자 하는 Peer들을 논리적으로 묶고 서로간의 SDP ( Session Description Protocol )와 ICE ( Interactive Connetivity Establishment ) Candidate를 교환해 준다.
* SDP : 스트리밍 미디어의 해상도, 형식, 코덱 등의 멀티미디어 컨텐츠의 연결을 설명하기 위한 표준
* ICE Framework : P2P Networking에서 두 컴퓨터가 가능한 직접 통신하는 방법을 찾기 위해 사용되는 기술
두개의 단말이 P2P 연결 가능하게 하도록 최적의 경로를 찾아주는 프레임워크
* ICE Candidate : P2P 연결 최적 경로 후보
Signaling에 필요한 데이터는 10KB정도로 매우 작은데, 많은양의 통신을 가지는 WebRTC의 특성상 부하를 다룰 수 있는 Signaling Server가 필요하다.
Singnaling Server 개발에는 SIP, XMPP 등의 기존 시그널링 프로토콜을 사용해도 되고, Ajax long Polling, Websocket 등의 적절한 쌍방향 통신 채널을 사용해도 된다.
3.2 STUN Server
STUN : Session Traversal Utilities for Nat
NAT을 우회하여 미디어 스트림을 P2P로 전송하기 위한 프로토콜
STUN Sever에 요청을 보내면, STUN Server는 해당 요청을 받아 Public IP Address와 Port 정보를 응답해준다.
UDP ( User Datagram Protocol ) 기반으로 동작하며, 주로 TURN과 함꼐 사용된다.
WebRTC에서 STUN Server는 Google에서 제공해주는 서버를 많이 사용한다.
*아래 server list 참고 ( stun.l.google.com:19302 )
3.3 TURN Server
TURN : Traversal Using Relays around NAT
STUN Server로 해결할 수 없는 상황에서 사용된다.
* 두 클라이언트가 같은 네트워크게 존재하는 경우
* Symmetic NAT 환경일 경우
모바일 네트워크일 경우(모바일도 wifi를 사용하면 STUN으로 가능)
public WIFI를 사용하는 경우
P2P 기반의 미디어 스트림 전송에서 NAT을 우회하여 통신할 수 있도록 해주는 Protocol
P2P 연결이 실패할 경우, 중계 서버 역할을 수행.
TURN Server가 Relay Server(중개 서버) 역할을 하게 되면 더이상 P2P 방식의 연결이 아니게 된다.
TURN Server를 사용하면 서버와의 통신이 추가적으로 수행되므로, 오버헤드가 발생하여 다른 대안이 없을 경우에만 사용한다.
TURN Server는 ICE Framework와 함께 사용 된다.
ICE는 STUN Server를 사용하여 NAT ( Network Address Translation ) 장치의 IP 주소와 Port 정보를 확인하여, 연결을 시도한다.
TURN Server는 개발자가 직접 구축할 수도 있지만, 외부에서 제공해주는 TURN Server를 사용할 수도 있다.
*Coturn TURN Server : 유명한 오픈소스 TURN Server, STUN과 TURN 모두 제공한다.
외부 제공 STUN, TURN SERVER
webRTC stun / turn server list
webRTC stun / turn server list. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
3.4 Trickle ICE
예전에는 각 Peer가 ICE Candidate들을 수집해서 그 목록을 한번에 교환했다.
이 방법은 모으는데도 시간이 오래 걸리고,
한 Peer의 작업이 완료된 후에 다른 Peer의 작업이 가능하기 때문에 비효율적이었다.
이에 기존의 동기 프로세스를 비동기 프로세스로 처리할 수 있게 나온 것이 Tricle ICE이다.
Trickle ICE는 ICE Candidate 교환 작업을 병렬 프로세스로 수행할 수 있게 해준다.
Trickle ICE를 사용하게 되면 ICE Candidate를 찾는 즉시 교환이 가능해진다.
Tirckle ICE 사용 이전과 이후의 차이점은 아래 이미지에서 보여준다.
동영상 이미지 캡처 출처 : Trickle ICE explained • BlogGeek.me
Trickle ICE
Trickle ICE is a common term used in the WebRTC environment. Learn more in the WebRTC Glossary where all relevant terms are explained!
bloggeek.me
4. WebRTC - Mesh Flow
'Etc' 카테고리의 다른 글
| CQRS (Command and Query Responsibility Segregation) (0) | 2024.02.26 |
|---|---|
| Window Fpp 인증 해제 및 신규 인증 (0) | 2023.04.05 |
| Maven Phase & Scope & Copy Dependencies (0) | 2023.02.09 |
| Git (0) | 2023.01.20 |
| Rest API 참고 (0) | 2023.01.19 |