WebRTC

leesj·2022년 4월 21일
2

Protocol

목록 보기
1/1
  • WebRTC(Web Real-Time Communication)
    웹 브라우저 간에 플러그인(드라이버나 중간자)의 도움 없이 서로 통신할 수 있도록 설계된 기술 이며 음성 통화, 영상 통화, P2P 파일 공유 등으로 활용될 수 있다.
  • 공식사이트 - https://webrtc.org/

기원

웹 브라우저 기반의 통신 방식인 WebRTC 는 구글이 오픈소스화한 프로젝트에서 기원함.
그 뒤로 국제 인터넷 표준화 기구가 프로토콜 표준화 작업을, W3C 가 API 표준화 작업을 진행하였음.

기술요소

설계

자바스크릡트 API 를 포함하는 WebRTC 의 주요 구성요소
getUserMedia
오디오와 비디오 미디어를 가져온다(예: 장치의 카메라와 마이크로폰에 접근)
RTCPeerConnection
피어 간 오디오, 비디오 통신을 활성화 한다.
신호 처리, 코덱 관리, P2P 통신, 보안, 대역폭 관리를 수행
WebRTC 에서 두 피어 간의 연결을 설정하고 제어하기 위한 중심점 역할
RTCDataChannel
피어 간 양방향 임의 데이터 통신을 허용한다.
웹소켓과 동일한 API를 사용하며 매우 낮은 레이턴시를 보인다.
또, WebRTC API 는 통계 함수를 포함한다.
getStats
웹 애플리케이션에 webRTC 세션에 관한 통계 집합의 검색을 허용한다.
이 통계 데이터는 별도의 W3C 문서에 기술되어 있다.

피어 연결

일반적인 P2P 절차

WebRTC 는 P2P 방식의 커뮤니케이션이기 때문에 각각의 웹 브라우저는 다음과 같은 절차를 밟아야 한다.
1) 각 브라우저가 P2P 커뮤니케이션에 동의
2) 서로의 주소를 고융
3) 보안 사항 및 방화벽 우회
4) 멀티미디어 데이터를 실시간으로 교환

위 단계에서 2번, 3번 단계가 일반적인 웹 개발의 접근 방법으로 해결하기 어려운데 그 이유는 브라우저는 외부에서 접근할 수 있는 주소가 없기 때문이며 WebRTC 가 P2P 기반이긴 하지만 통신 설정 초기 단계에서는 중재자의 역할이 필요하다.

WebRTC 의 피어연결

  • 피어 연결은 P2P 프로토콜을 사용하여 통신하기 위해 여러 컴퓨터의 두 애플리케이션을 연결하는 작업하는 하는 WebRTC 사양의 일부이다.
  • 피어 간의 통신은 동영상, 오디오 또는 임의의 바이너리 데이터일 수 있다.
  • 두 피어가 어떻게 연결할 수 있는지 알아보려면 두 클라이언트 모두 ICE 서버 구성을 제공해야 하며, 이 서버는 STUN 또는 TURN 이며 각 서버에 ICE 후보를 제공하여 원격 피어로 전송된다.
  • 이러한 ICE 후보의 전송을 일반적으로 신호라고 한다.

WebRTC 가 실시간으로 웹에서 데이터를 교환할 수 있는 이유는 시그널링이라고 일컫어지는 NAT 우회과정을 거치기 때문이다.

NAT Traversal

일반적으로는 라우터가 NAT 역할을 하는데 외부에서 접근하는 공인 IP와 포틉 번호를 확인하여 현재 네트워크 내의 사설 IP 들을 매핑한다.
(특정 브라우저 2개가 서로 직접 통신을 하려면, 각자 현재 연결된 라우터의 공인 IP 주소와 포트를 먼저 알아내야 한다.)

이러한 라우터를 통과해서 연결할 방법을 찾는 과정이 NAT Traversal 이다.

NAT Traversal 은 STUN 과 TURN 서버에 의 해 이루어진다.

STUN(Session Traversal Utilities for NAT)

  • 단말이 자신의 공인 IP주소와 포트를 확인하는 과정에 대한 프롵콜
  • 즉, STUN 서버는 인터넷의 복잡한 주소들 속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환해 준다.
  • STUN 서버를 향해 요청을 보내면 STUN 서버는 NAT 뒤에 있는 피어들이 서로 연결할 수 있도록 공인 IP 와 포트를 찾아준다

TURN(Traversal Using Relay NAT)

  • 클라이언트가 동일한 로컬 네트워크에 상주하지 않는 한 클라이어늩 간에 직접 소켓을 사용할 수 없는 경우가 많은데 이 문제를 해결하는 일반적인 방법은 TURN서버를 사용하는 것이다.
  • 네트워크 트래픽을 릴레이 하는 프롵콜인 릴레이 NAT 를 사용하는 순회를 의미한다.
  • STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우(특정 라우터는 방화벽 정책을 달리 할 수도 있고, 이전에 연결된 적이 있는 네트워크만 연결할 수 있게 제한을 걸기도 하기 때문에(Symmetric NAT)) TURN 서버를 대안으로 이용한다.
  • TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 것이다.
  • TURN 방식은 중간에 서버를 한 번 거치기 때문에, 엄밀히 이야기하자면 P2P 통신이 아니게 되며 그 구조상 지연이 필연적으로 발생한다.
  • 하지만 보안 정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이기 때문에 TURN 방식은 최후의 수단으로 선택된다.

현재 TURN 서버는 온라인에서 호스팅되는 애플리케이션 (오픈소스 COTURN 프로젝트 등) 및 클라우드 제공 서비스 등 온라인에서 사용할 수 있는 여러 가지 옵션이 있다.

✔️ STUN 과 TURN
WebRTC 는 P2P 로 디자인되어 있으며 실제 서비스 환경에서 P2P 연결을 위해서는 STURN 서버를 사용해 컴퓨터의 공인 IP 를 가져오고 TURN 서버는 P2P 통신이 불가능 할 경우 릴레이 서버로 동작 함.

ICE(Interactive Connectivity Establishment)

  • ICE 는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크이다.
  • STUN, TURN 서버를 이용해서 획득했던 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소들을 후보(Candidate) 라고 부른다. 그리고 이 과정을 후보 찾기(Finding Candidate) 라고 부른다.
  • ICE 프레임워크는 STUN, 또는 TURN 서버를 이용해 상대방과 연결 가능한 후보들을 갖고 있다는 것이다.

서버가 포함된 WebRTC 통신 구조

서버가 포함된 WebRTC 구조에서 서버의 역할은 다음과 같다

  • 사용자 탐색과 통신/signaling
  • NAT / 방화벽 탐색
  • Peer to Peer 통신 서버 시 중계서버

->>>>>>>> 그림추가

WebRTC 의 통신유형

P2P

1:1, 소규모 미디어 교환에 적합하다

Mesh

P2P 기반으로 다수의 1:1 통신을 수행함
서버 비용이 들지 않는 장점이 있으나 많은 네트워크 리소스를 사용하게 되고, 실제 사용 환경에서 네트워크 지연으로 인해 쾌적한 도이기화를 제공하지 못하여 현재 대부분의 그룹 영상통화에서는 사용되지 않는 방식이라고 함

MCU(Multipoint Control Unit)

한쪽 Peer 에 서버를 두고, 들어오는 트래픽을 서버에서 믹싱해서 다시 내보내는 방식이다. 클라이언트와 네트워크의 부담이 줄어드는 반면, 중앙서버의 컴퓨팅 파워가 많이 요구된다.

특징

  • 다수의 송출 미디어를 중앙 서버에서 혼합(muxing) 또는 가공(transcoding)하여 수신측으로 전달하는 중앙 서버 방식이다.
  • 클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결한다.
  • 모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보내면 된다.(즉, Uplink가 1개다.)
  • 모든 연결 형식에서 클라이언트는 연결된 사용자의 수와 상관없이 서버에게서 하나의 peer로 데이터를 받으면 된다.(즉, Downlink가 1개다.)
    중앙 서버의 높은 컴퓨팅 파워가 요구된다.

장점

  • 클라이언트의 부하가 현저히 줄어든다.(항상 Uplink 1개, Downlink 1개로 총 2개)
  • N:M 구조에 사용 가능하다.(적합...하다고 할 수 있을 지는 잘 모르겠다. 다른 서버들보다는 적합하다.)

단점

  • Signaling 서버보다 서버 비용이 증가한다.
  • 대규모 N:M 구조에서는 여전히 클라이언트가 많은 부하를 감당한다.

SFU(Selective Forwarding Unit)

믹싱하지 않고 트래픽을 선별적으로 배분해서 보내주는 방식, 각 peer 연결 할당과 encrypt/decrypt 역할을 서버가 담당하며 1:N 스트리밍 구조에 적합

특징

  • 종단 간 미디어 트래픽을 중계하는 중앙 서버 방식
  • 클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결한다.
    1:1, 1:N, N:N 혹은 N:M 등 모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보내면 된다.(즉, Uplink가 1개다.)
  • 하지만 1:N, N:N 혹은 N:M 형식이라면 상대방의 수만큼 데이터를 받는 peer를 유지해야한다.(Downlink는 P2P(Signaling서버)일 때와 동일하다.)
  • 1:N 형식 또는 소규모 N:M 형식의 실시간 스트리밍에 적합하다.

장점

  • 데이터가 서버를 거치고 Signaling 서버(P2P 방식)를 사용할 때 보다 느리긴하지만 비슷한 수준의 실시간성을 유지할 수 있다.
  • Signaling 서버를 사용하는 것보다 클라이언트가 받는 부하가 줄어든다.

단점

  • Signaling 서버보다 서버 비용이 증가한다.
  • 대규모 N:M 구조에서는 여전히 클라이언트가 많은 부하를 감당한다.

XDN(Experience Delivery Network)

XDN 은 SFU 와 MCU 의 요소를 결합하여 WebRTC 확장에 대한 새로운 접근 방식을 제시한다. SFU 나 MCU 와는 달리 XDN 은 중앙 집중식 서버가 아닌 클라우드 기반 클러스터링 아키텍처를 사용하여 WebRTC 의 확장성 문제를 해결한다.

  • 각 클러스터는 분산 서버 인스턴스 또는 노드의 시스템으로 구성되며 오리진, 릴레이 또는 에지 노드를 포함한다.
  • 이 토폴로지 내에서 지정된 원본 노드는 들어오는 스트림을 수집하고 여러 에지 노드와 통신하여 수천 명의 참가자를 지원한다.
  • 대규모 배포의 경우 원본 노드는 릴레이 노드로 스트리밍 할 수 있으며 릴레이 노드는 차례로 여러 에지 노드로 스트리밍하여 클러스털르 더욱 확장하여 사실상 무제한 확장을 실현 할 수 있다.
  • 믹서: 게시자와 원본 노드 사이에 배치할 수 있으며 많은 스트림을 단일 스트림으로 결합한 다음 원본 노드로 전달한다. 믹선느 기본적으로 단일 서버 MCU 가 처리할 수 있는 것보다 더 많은 스트림을 결합하기 위해 클러스터링할 수 있는 MCU 이다.

OSS 솔루션들


출처 및 세부비교 - https://alnova2.tistory.com/1118

참고자료

0개의 댓글