WebRTC란?

예전에 1:1 영상통화를 만들려고 수박 겉핥기 식으로 보고 말았던 기술인데, 내가 한 것들을 조금 되돌아보면서 이 기술을 왜 썼었는지 기억이 안 났다. 그래서 포스팅해서 기록이라도 해두려고 한다.

먼저 WebRTC라는 단어를 봤을 때 Web과 RTC가 붙어있는 형태라고 생각했다. 그래서 WebRTC 자체가 무엇인지 보기 전에 각 단어의 뜻에 대해서 확인해 보기로 했다.

 

웹은 뭘까? 웹은 월드 와이드 웹(WWW)의 약자로, 이것에 대한 위키백과의 내용은 아래와 같다. 주관적으로 봤을 때 웹과 관련된 것 같지 않은 내용은 생략했다.

https://en.wikipedia.org/wiki/World_Wide_Web

World Wide Web - Wikipedia

일반적으로 웹으로 알려진 월드 와이드 웹(WWW)은 문서, 기타 웹 리소스가 URL에 의해 식별되는 정보 시스템이다. 웹의 리소스는 HTTP를 통해 전송되고 사용자는 웹 브라우저라는 소프트웨어 응용 프로그램에서 액세스할 수 있으며, 웹 서버라고 하는 소프트웨어 응용 프로그램에서 게시할 수 있다. 웹은 인터넷과 동의어가 아니고, 팀 버너스 리가 1989년에 발명했다. 웹은 정보화 시대 발전의 중심이었고 수십억 사람들이 인터넷에서 상호작용하는 데 쓰이는 주요 도구다. 웹 리소스는 모든 유형의 다운로드된 미디어일 수 있지만, 웹 페이지는 HTML 형식의 하이퍼텍스트 문서다.

 

위키백과만으론 무슨 뜻인지 잘 이해가 안 되서 다른 글들을 확인해보니

 

• 인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있게 고안된 전세계적인 정보 공간
• 인터넷의 정보들이 얽혀있는 무형의 정보 네트워크

결국은 이런 뉘앙스의 말들을 각자 다르게 말하고 있다고 생각했다.

정리하면 인터넷 안에 웹이 포함돼 있고, 웹은 그 인터넷 안에서 서로 연결된 사람들이 데이터들을 공유할 수 있도록 하는 가상 공간이라고 이해했다.

 

그럼 RTC는 뭘까? 영문 위키백과에 검색했을 때 Real-time communication이라는 이름으로 문서가 하나 있었다.

https://en.wikipedia.org/wiki/Real-time_communication

Real-time communication - Wikipedia

실시간 통신은 실시간 컴퓨팅의 실시간 보장을 지원하는 데 필요한 소프트웨어 프로토콜 및 통신 하드웨어 미디어의 범주다.

실시간이란 단어만 3번 나오고 딱히 뭐 이해되지 않는 문구다. 그래서 위키백과 대신 다른 포스팅을 확인해봤다.

 

https://www.vonage.com.au/resources/articles/real-time-communications/

What Is Real-Time Communications?

실시간 통신(RTC)은 지연 시간이 거의 없이 송신자에서 수신자에게로의 모든 유형의 통신 서비스를 통해 거의 동시에 정보를 교환하는 것이다. RTC의 예시로는 유선 전화 및 핸드폰을 통한 음성, VoIP, 인스턴트 메시징(왓츠앱, 위챗, 페이스북 메신저 등), 비디오 및 원격 회의, Robotic telepresence 등이 있다.

 

https://searchunifiedcommunications.techtarget.com/definition/real-time-communications

What is Real-Time Communications (RTC)?

실시간 통신(RTC)은 모든 사용자가 즉시 또는 무시할 수 있는 지연 및 전송 지연으로 정보를 교환할 수 있는 모든 통신 모드다. 이 맥락에서 실시간이란 용어는 라이브와 동의어다.

 

https://www.techopedia.com/definition/24426/real-time-communications-rtc

What is Real-Time Communications (RTC)? - Definition from Techopedia

실시간 통신(RTC)은 전송 지연 없이 발생하는 모든 실시간 통신을 지칭하는 용어다. RTC는 최소한의 대기 시간으로 거의 즉각적이다. RTC 데이터와 메시지는 송수신 사이에 저장되지 않는다. RTC는 일반적으로 브로드 캐스팅이나 멀티캐스팅이 아닌 P2P 전송 방식이다

 

정리하면 실시간 통신이란 거의 동시에 다른 사람끼리 데이터를 교환할 수 있는 통신 방법이라는 것 같다.

 

---

 

이제 웹과 합쳐서 WebRTC란 단어를 보면, 인터넷으로 연결된 가상 공간 안에서 다른 사람들끼리 실시간으로 여러 형태의 데이터들을 교환할 수 있는 통신 방법이라고 생각된다. 이제 내 가설이 맞는지 WebRTC의 위키백과 항목을 봤다.

 

https://ko.wikipedia.org/wiki/WebRTC

WebRTC - 위키백과, 우리 모두의 백과사전

WebRTC(Web Real-Time Communication)는 웹 브라우저 간에 플러그인 도움 없이 서로 통신할 수 있도록 설계된 API다. W3C에서 제시된 초안이며 음성/영상 통화, P2P 파일 공유 등으로 활용될 수 있다.

https://en.wikipedia.org/wiki/WebRTC

WebRTC - Wikipedia

WebRTC(Web Real-Time Communication)는 웹 브라우저와 모바일 앱 간에 간단한 API(응용 프로그래밍 인터페이스)를 통해 실시간 통신(RTC)을 제공하는 무료 오픈소스 프로젝트다. 직접 P2P 통신을 허용해서 웹 페이지 안에서 오디오, 비디오 통신이 작동하도록 해서 플러그인을 설치하거나 기본 앱을 다운받을 필요가 없다.
애플, 구글, 마이크로소프트, 모질라 및 오페라의 지원을 받는 WebRTC의 사양은 W3C 및 IETF에서 만들었다.
이 프로젝트의 목적은 브라우저, 모바일 플랫폼 및 IoT 장치용으로 풍부한 고품질 RTC 응용 프로그램을 개발할 수 있도록 하고 이들 모두가 공통 프로토콜 세트를 통해 통신할 수 있도록 하는 것이다.

 

대충 맞는 것 같다. 이제 공식 홈페이지와 다른 블로그들에선 이것에 대해 어떻게 써놨는지 찾아봤다.

https://webrtc.github.io/webrtc-org/architecture/

Architecture | WebRTC

WebRTC는 웹 응용 프로그램 개발자에게 플러그인, 다운로드 또는 설치 없이 웹에서 실시간 미디어 응용 프로그램(영상 통화 등)을 작성할 수 있는 기능을 제공한다. 이것의 목적은 여러 플랫폼, 여러 웹 브라우저에서 작동하는 강력한 실시간 통신 플랫폼을 구축하는 것이다

 

https://medium.com/@hyun.sang/webrtc-webrtc%EB%9E%80-43df68cbe511

[WebRTC] WebRTC란?

WebRTC란 웹 어플리케이션(최근엔 안드로이드, iOS도 지원) 및 사이트들이 별도의 소프트웨어 없이 음성, 영상 미디어 혹은 텍스트, 파일 같은 데이터를 브라우저끼리 주고받을 수 있게 만든 기술이다. WebRTC로 구성된 프로그램들은 별도의 플러그인이나 소프트웨어 없이 P2P 화상회의 및 데이터를 공유한다.
즉, 웹 브라우저 상에서는 어떤 플러그인도 필요없이 음성채팅, 화상채팅, 데이터 교환도 가능하게 하는 기술이다.
WebRTC는 P2P 통신에 최적화되어 있다. WebRTC에 사용되는 기술은 여러 가지가 있지만 크게 3가지 클래스의 객체에 의해 실시간 데이터 교환이 일어난다.

1. MediaStream : 카메라, 마이크 등의 데이터 스트림 접근
2. RTCPeerConnection : 암호화 및 대역폭 관리, 오디오와 비디오의 연결
3. RTCDataChannel : 일반적인 데이터의 P2P 통신

여기서 RTCPeerConnection들이 데이터를 교환할 수 있게 처리해주는 과정을 시그널링(Signaling)이라고 한다.

https://andonekwon.tistory.com/53?category=447798 

WebRTC란? (1)

...(중략)...간단히 말해서 웹 브라우저 간에 Adobe Flash나 ActiveX와 같은 별도의 플러그인 없이 서로 통신할 수 있도록 만든 기술이며 이것을 이용해서 음성, 영상 통화 등 여러가지를 할 수 있다. WebRTC로 구성된 서비스는 디스코드가 있다.
일반적인 통신은 서버를 거쳐서 클라이언트1이 클라이언트2에게 전달하는 방식이지만 WebRTC는 클라이언트1이 서버에 보낸다고 통지하면 서버가 클라이언트2에게 클라이언트1이 보낸다고 알리고, 클라이언트 1이 클라이언트 2에게 전달하는 식으로 작동한다(이 부분은 해당 블로그에 그림으로 설명이 되어 있는 걸 글로 적었다). 본래 첫 태생 자체는 P2P를 위한 통신방식이었다.
그러나 아무래도 WebSocket 등 직접적으로 IP를 연결하는 방식을 차용하기 때문에, 방화벽이 있거나 허브(또는 라우터)를 사용하는 NAT 환경에서는 사용이 불가능하다. 따라서 시그널링을 위해서는 방화벽을 통과시켜주거나 프라이빗 ip를 퍼블릭 ip로 바꿔주는 STUN 서버 또는 TURN 서버를 써야 한다...(중략)

 

여기서 MediaStream~RTCDataChannel의 설명이 추상적이고 좀 더 있으면 좋겠다 생각했는데 아래의 논문 PDF에서 좀 더 설명을 해주고 있었다. 도움되는 내용들이 많아 보이고 한글로 작성돼 있으니 핸드폰 등에 담아서 틈틈이 보면 좋을 듯하다.

https://www.koreascience.or.kr/article/CFKO201435553773340.pdf

1. MediaStream API : 사용자의 카메라, 마이크 같은 디바이스의 음성, 화상 스트림을 획득 가능
2. RTCPeerConnection API : 암호화, 대역폭 제어 기능과 함께 음성, 화상 통신을 제공. UDP를 기반으로 하는 RTP(Real-time Transport Protocol)를 이용해 송수신 패킷의 구조를 정의하고, RTCP(RTP Control Protocol)을 통해 송수신 흐름 제어
3. RTCDataChannel API : 피어 간 데이터 통신을 제공한다
4. Signaling 기술 : 세션의 생성/유지/종료를 위해 상호간 메시지 전송 프로토콜로 특정 규격을 정하지 않은 Abstract Signaling을 이용하며, 세션 생성을 위해 상호간 네트워크, 미디어 정보교환을 위해 SDP(Session Description Protocol)를 이용한다. 기존 SIP(Session Initiation Protocol)을 이용한 Signaling 시스템의 구축도 가능하다.
5. NAT Traversal 기술 : 브라우저 간의 직접적 세션 연결을 위해 브라우저 간의 네트워크에 존재하는 연결 방해요소인 NAT나 Firewall을 극복하기 위한 기술. NAT와 Firewall의 종류를 검출하고 NAT의 Hole-punching을 통해 연결이 가능하도록 하며, 최악의 경우 중계 서버를 이용해 통신을 가능하게 한다. 지원 기술로 ICE가 있고 다수의 STUN과 TURN 서버를 이용해 최적의 네트워크 연결을 수행한다.

여기서 시그널링이란 통신을 조정해 두 피어(단말)가 통신할 수 있는 환경을 세팅하는 걸 말한다. WebRTC는 이걸 수행하지 않아 따로 작동하는 서버를 만들어야 한다. 시그널링이란 것에 대해선 이곳과 이곳을 참고해보는 것도 좋겠다.

 

https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API

WebRTC API - Web API | MDN

WebRTC는 웹 어플리케이션과 사이트가 중간자 없이 브라우저 간 오디오나 영상 미디어를 포착하고 마음대로 스트림할 수 있고, 임의의 데이터도 교환할 수 있게 하는 기술이다. WebRTC를 구성하는 일련의 표준들은 플러그인이나 제3자 소프트웨어 설치 없이 종단 간 데이터 공유와 화상 회의를 가능하게 한다.

 

그리고 WebRTC가 작동하는 구조는 어떤 형태인지 확인해봤다. 아래의 그림은 공식 홈페이지에서 확인해볼 수 있다.

 

브라우저 안에서 녹색 WebRTC 영역 안을 보면 VoiceEngine 등 3가지 큰 덩어리와 WebRTC C++ API 등 여러 개가 들어있는 게 보인다. 이것들을 전부 WebRTC가 처리해주는 듯하다.

만드는 사람 입장에선 번거로운 각종 처리들을 알아서 해주니 그냥 구현만 하면 되서 편하긴 하겠다.

 

그리고 MDN Web Docs에서 WebRTC 프로토콜을 소개하면서 STUN, TURN 서버라는 용어를 사용하고 있었다.

그래서 각 단어가 뭘 뜻하는지 확인해봤다. 일단 STUN, TURN 모두 어떤 단어의 약어같다는 생각이 드는데 이게 맞는지 검증도 하면서 진행했다.

 

https://ko.wikipedia.org/wiki/STUN

STUN - 위키백과, 우리 모두의 백과사전

STUN(Session Traversal Utilities for NAT)은 실시간 음성, 영상, 메시징 앱, 그리고 기타 상호작용 통신 부문에서 네트워크 주소 변환(NAT) 게이트웨이의 트레버설을 위한, 네트워크 프로토콜을 포함하는 메서드들의 표준화된 모임이다.
STUN은 상호 연결 확립(ICE), 세션 개시 프로토콜(SIP), WebRTC 등 기타 프로토콜들에 의해 쓰이는 도구다. 호스트가 네트워크 주소 변환기를 찾아내고 NAT의 원격 호스트에 대한 애플리케이션의 UDP 플로우를 위해 할당된 매핑된(보통은 퍼블릭) IP 주소와 포트 번호를 발견하기 위한 도구를 제공한다. 이 프로토콜은 대개 퍼블릭 인터넷인 NAT의 반대(퍼블릭)편에 위치한 서드파티 네트워크 서버(STUN 서버)로부터의 도움이 필요하다.
STUN은 통신 프로토콜들이 2개의 통신 종단점 사이의 경로에 있는 네트워크 주소 변환기를 찾아내고 횡단할 수 있게 하는 도구다. 가벼운 클라이언트-서버 프로토콜로 구현돼 있으며, 일반적으로 인터넷인 쉽게 접근 가능한 네트워크에 위치한 서드파티 서버의 단순 쿼리 및 응답 구성요소만 연구한다. 클라이언트 사이드는 음성 인터넷 프로토콜(VoIP) 전화 또는 인스턴트 메신저 클라이언트 등의 사용자의 통신 애플리케이션에 구현돼 있다.

 

https://www.3cx.com/global/kr/voip-sip-webrtc/stun-server/

STUN 서버

STUN(Simple Traversal of User Datagram Protocol(UDP) Through Network Address Translators(NATs)) 서버는 클라이언트(예를 들어 방화벽의 보호를 받는 컴퓨터)가 로컬 네트워크 외부에서 호스트되는 VOIP 제공업체에 전화 통화를 설정할 수 있도록 해준다.
STUN 서버는 클라이언트가 공용 주소, 이면에 있는 NAT의 유형 및 NAT에 의해 특정 로컬 포트와 연결된 인터넷 측 포트를 찾을 수 있도록 해준다. 이 정보는 클라이언트와 VOIP 제공업체 사이의 UDP 통신을 설정하는 데 사용되며, 따라서 통화 연결에 사용된다. STUN 프로토콜은 RFC3489에 정의되어 있다.
STUN 서버는 UDP 포트 3478에 연결되지만 서버는 클라이언트가 대체 IP 및 포트 번호에서 테스트를 실행하도록 힌트를 제공한다(STUN 서버에는 2개의 IP 주소가 있다). RFC에는 포트 및 IP가 임의적이라고 명시되어 있다.

https://gh402.tistory.com/45

[WebRTC] NAT, ICE, STUN, TURN 이란? ( WebRTC를 이해하기 위해 필요한 지식들)

STUN 서버는 공개 주소를 발견하거나 피어 간의 직접적인 연결을 막는 등 라우터의 제한을 결정하며 ICE를 보완하는 프로토콜이다. 간단하게 말하면 STUN 서버는 해당 피어의 공인 IP 주소를 보내는 역할을 한다.
STUN은 두 엔드 포인트 간의 연결을 확인하고 NAT 바인딩을 유지하기 위한 연결 유지 프로토콜로도 사용할 수 있다.
하지만 STUN은 항상 효과적이진 않다. 두 단말이 같은 NAT 환경에 있을 경우, 또는 NAT 보안정책이 엄격하거나 등의 이유에 따라 STUN이 완벽한 해결책이 되지는 않는다.

 

https://wecomm.tistory.com/3

WebRTC 의 기본요약

STUN 서버는 NAT 내부망에서 피어 간의 연결을 도와주는 서버로 일명 Hole-punching을 해주는 역할을 한다.
공유기가 라우터의 특성도 갖고 있어 Routing Table을 작성하기 위해 P2P 통신을 목적으로 사전에 상대방과 패킷을 주고받아 각자의 공유기에 Routing Table을 작성하는 걸 Hole-punching이라고 한다.
즉 A와 B 클라이언트가 STUN 서버를 통해 각자의 접속 포인트(IP, 포트)를 전달하고 STUN 서버를 통해 정보를 전달받아 직접 A, B 사이의 통신을 할 수 있다.
STUN은 구글 등에서 퍼블릭 STUN Server로 무상 제공하고 있으며 특별한 경우가 아니면 간단한 설정만으로 이런 서비스를 이용할 수 있다...(중략)

 

---

 

정리하면 STUN 서버는 NAT란 것의 내부에서 서로 다른 두 클라이언트가 직접 통신하도록 도와주는 서버란 게 된다.

그럼 TURN 서버는 뭘까?

https://ko.wikipedia.org/wiki/TURN

TURN - 위키백과, 우리 모두의 백과사전

TURN(Traversal Using Relays around NAT)은 멀티미디어 애플리케이션을 위해 네트워크 주소 변환(NAT) 또는 방화벽에서 보조하는 프로토콜이다. TCP / UDP와 사용 가능하다. NAT 장치 하의 네트워크 클라이언트에 유용하다.
TURN은 NAT를 경유하는 사설 네트워크의 잘 알려진 포트 상의 서버를 구동하는 데 도움을 주지 않는다. 예를 들어 전화처럼 NAT 뒤의 사용자가 하나의 피어에만 연결하는 걸 지원한다. TURN은 RFC 5766에 의해 규정된다. IPv6용 TURN의 업데이트는 RFC 6156에 규정돼 있다. TURN URI 스킴은 RFC 7065에 문서화되어 있다.
NAT는 수많은 장점을 제공하지만 수많은 단점이 따라오기도 한다. 해당 단점들 가운데 가장 큰 문제는 기존의 수많은 IP 애플리케이션의 동작을 막고 새로운 애플리케이션의 디플로이를 어렵게 만든다는 것이다. "NAT 친화" 프로토콜을 빌드하는 방법을 기술하는 여러 가이드라인이 개발되었으나 수많은 프로토콜들은 단순히 이 가이드라인을 따라 구성하는 것은 불가능하다. 이러한 프로토콜의 예로 멀티미디어 애플리케이션과 파일 공유를 들 수 있다.
STUN은 애플리케이션이 NAT를 경유하는 수단을 제공한다. STUN은 클라이언트가 트랜스포트 주소(IP 주소와 포트)를 취득할 수 있게 하는데, 이는 피어로부터 패킷을 수신하는데 유용하게 만들어 준다. 그러나 STUN을 통해 취득한 주소는 모든 피어에 유용하지 않을 수 있다. 이러한 주소들은 네트워크 위상 조건에 따라 동작한다. 그러므로 STUN 그 자체는 NAT 경유를 위한 완전한 해결책을 제공하는 것은 아니다.
완전한 해결책에는 패킷을 공용 인터넷에 내보낼 수 있는 피어로부터 미디어를 수신할 수 있는 트랜스포트 주소를 클라이언트가 취득할 수 있는 수단을 요구한다. 이는 공용 인터넷에 상주하는 서버를 통해 데이터를 릴레이(relay)하는 방식으로만 달성할 수 있다. TURN은 이러한 릴레이로부터 IP 주소와 포트를 클라이언트가 취득할 수 있게 도와준다.
TURN이 클라이언트에 연결을 거의 항상 제공함에도 불구하고 TURN 서버 제공자에게는 리소스가 상당히 집중된다. 그러므로 마지막 수단으로만 TURN을 사용할 것이 권고되며 가능하면 다른 구조(STUN 또는 직접 연결)가 선호된다. 이를 달성하기 위해 상호 연결 확립(ICE) 방식을 사용하여 연결의 최적 수단을 감지해낼 수 있다.

 

https://wecomm.tistory.com/3

WebRTC 의 기본요약

...(중략)...하지만 NAT가 설치된 방화벽 중 일부 경우엔 STUN 만으론 P2P가 불가능해 중계 서버가 피어 간의 통신채널을 중계하게 되는데 이것이 TURN 서버다. TURN 서버를 통해 연결되면 엄밀히 말해 P2P가 되는 걸수도 있지만, WebRTC의 객체 내부적으로 처리하기 때문에 유저 측에선 P2P로 봐도 무방할 것이다. TURN은 STUN/TURN 2가지 기능을 모두 지원하고, STUN은 STUN 기능만을 제공하기 때문에 TURN이 더 포괄적인 서버다.
TURN 서버는 STUN과 같이 접속을 위한 정보를 제공하는 게 아니고 정보 중계와 같은 작업이 일어나기 때문에 유료 서비스 또는 직접 구축해 운영하는 게 대부분이다. 대표적인 공개 소스는 구글이 배포하는 https://code.google.com/archive/p/rfc5766-turn-server/ 를 이용할 수 있다. (이 주소로 들어가면 해당 사이트는 레거시 사이트라고 나오며 어떤 깃허브 레포 주소로 이동하라고 한다. 이용 시 참고)

 

https://gh402.tistory.com/45

[WebRTC] NAT, ICE, STUN, TURN 이란? ( WebRTC를 이해하기 위해 필요한 지식들)

TURN 서버는 STUN의 확장으로 NAT 환경에서 릴레이해서 통신하게 된다. NAT 보안 정책이 너무 엄격하거나 NAT 순회를 하기 위해 필요한 NAT 바인딩을 성공적으로 생성할 수 없는 경우 사용한다.
TURN 서버는 인터넷망에 위치하고 각 피어(단말)들이 사설망(프라이빗 IP) 안에서 통신한다. 각 피어들이 직접 통신하는 게 아니라 릴레이 역할을 하는 TURN 서버를 사용해 경유한다. TURN은 이런 릴레이로부터 IP 주소와 포트를 클라이언트가 얻을 수 있는 릴레이 주소를 할당한다.
하지만 TURN은 클라와의 연결을 거의 항상 제공하지만, STUN에 비해 리소스 낭비가 심하다. 때문에 ICE Candidate 과정에서 로컬 IP로 연결할 수 있는지, 퍼블릭 IP로 연결할 수 있는지를(모든 후보군을 찾은 후) 알아낸 다음 최후의 수단으로 써야 한다.

 

정리하면 STUN보다 확장된 형태의 서버고 NAT 환경에 제약이 걸릴 경우 고려해볼 수 있겠지만, 섣불리 쓰지 말고 정 안되겠으면 써야 하는 게 TURN 서버같다.

 

 

마지막으로 WebRTC의 연결 구조 종류들을 살펴보고 포스팅을 마무리한다.

WebRTC의 연결 구조는 크게 P2P/MESH, MCU, SFU가 있다.

 

먼저 P2P는 서버 없이 클라이언트 간의 다중 연결 방식으로 MESH 구조와 비슷하다고 한다.

MESH 구조에 대한 위키백과의 정의는 아래와 같다.

https://ko.wikipedia.org/wiki/%EB%A9%94%EC%8B%9C_%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

메시 네트워크 - 위키백과, 우리 모두의 백과사전

메시(mesh) 네트워크는 각 노드가 네트워크에 대해 데이터를 릴레이하는 네트워크 토폴로지다. 모든 메시 노드들은 네트워크 내의 데이터 분산에 협업한다. 무선, 유선망에 모두 적용 가능하다.
무선 메시 네트워크는 무선 애드혹 네트워크의 일종으로 간주할 수 있다. 그러므로 무선 메시 네트워크들은 모바일 애드혹 네트워크(MANETs)와 밀접하게 관련돼 있다. MANETs가 특정 메시 네트워크 토폴로지에 국한되진 않지만, 무선 애드혹 네트워크나 MANETs는 어떤 형태의 네트워크 토폴로지라도 취할 수 있다.

https://en.wikipedia.org/wiki/Mesh_networking

Mesh networking - Wikipedia

메시 네트워크는 인프라 노드(브릿지, 스위치, 기타 인프라 장치)가 가능한 많은 다른 노드에 직접 동적으로 비계층적으로 연결하고 서로 협력해 다음을 수행하는 로컬 네트워크 토폴로지다. 클라에서 데이터를 효율적으로 라우팅한다.
한 노드에 대해 이런 종속성이 없기 때문에 모든 노드가 정보 릴레이에 참여할 수 있다. 메시 네트워크는 동적으로 자체 구성되므로 설치 오버헤드를 줄일 수 있다. 자체 구성 기능을 통해 특히 몇 개의 노드에 장애가 발생하는 경우 워크로드를 동적으로 분산할 수 있다. 이는 차례로 내결함성과 유지 관리 비용 절감에 기여한다.
메시 토폴로지는 브릿지, 스위치가 다른 브릿지, 스위치의 작은 하위 집합에만 직접 연결되고 이런 인프라 이웃 간의 링크가 계층적인 기존의 스타/트리 로컬 네트워크 토폴로지와 대조될 수 있다. star-and-tree 토폴로지가 매우 잘 확립돼 있고, 고도로 표준화돼 있으며 벤더 중립적이지만 메시 네트워크 장치 벤더는 아직 공통 표준에 대해 모두 동의하지 않았으며 다른 벤더의 장치 간 상호 운용성은 아직 보장되지 않았다.

 

역시 무슨 말인지 모르겠다. 하지만 저 안에 핵심이 있는 기분이라 그냥 지나치기엔 아쉽다. 다른 블로그를 찾아보긴 했지만 MESH 구조에 대해 설명하는 포스팅이 아니니 지금은 넘어간다.

각 구현 방식의 특징을 정리해보면 아래와 같다. 장단점은 내가 확인한 게 아니라 쓰기 애매해서 쓰지 않았다.

https://6987.tistory.com/entry/WebRTC-%EB%AF%B8%EB%94%94%EC%96%B4-%EC%97%B0%EA%B2%B0-%EB%B0%A9%EC%8B%9D-MCU-SFU-P2P

WebRTC 미디어 연결 방식 (MCU, SFU, P2P)

P2P : 서버 방식이 아닌 클라이언트 간의 다중 연결 방식으로 Mesh 구조를 생각하면 된다. 서버 자원을 쓰지 않는 대신 각 클라의 네트워크 I/O 부하가 높게 발생하고 컴퓨터의 하드웨어 리소스 사용률도 많이 증가한다. 그래서 연결된 클라의 수가 적을 경우 유리한 구조지만 클라가 많을 경우 부하를 줄일 수 있는 알고리즘을 구현해야 한다

SFU : 서버를 이용해 클라이언트의 미디어 스트림을 중계하는 역할을 수행하며 상황에 따라 연결된 클라이언트 일부만 중계하기도 한다. P2P의 경우 연결된 클라 수만큼의 업로드 트래픽이 발생했지만 SFU는 업로드 커넥션을 1개만 유지하면 나머지 서버에서 각 클라로 분배해준다. 대표적으로 줌(ZOOM)이 쓰고 있는 구조로 천 명이 한 번에 연결돼 회의할 수 있는 정도로 효율적이다.
단, 개별 클라이언트는 접속한 클라이언트 수(또는 내 화면이 디스플레이해야 하는 클라이언트 수)만큼의 영상, 음성을 디코딩해야 한다. 접속한 클라이언트 수가 많을수록 PC의 자원 사용량이 많아지면서 회의가 어려울 수 있다. 이를 해결하기 위해 SVC 코덱이나 Simulcast를 활용해야 한다. ZOOM은 PC에서 한 번에 25개 클라이언트의 미디어를 디코딩하도록 설계돼 있다.

MCU : 서버를 이용해 업로드된 미디어 스트림을 하나로 합쳐(Mixing)서 클라이언트에 1개의 미디어 스트림을 내려주는 구조다. P2P, SFU에서 발생하는 트래픽은 줄일 수 있으나 미디어 스트림을 합치는 동작에서 서버 자원을 많이 소모하게 된다. MCU 방식은 서버 자원을 활용해 각 클라의 부담을 줄이는 연결 방식이다. 보통 연결된 클라이언트의 영상을 1개로 믹싱하는 형태가 일반적이지만 유저가 많은 경우 2~3개 그룹 형태로 믹싱해서 대규모 접속을 처리할 수 있다. MCU 방식은 암호화된 미디어 스트림이 서버에서 한 번 복호화되고 다시 암호화되는 형태로 완벽한 종단 간 암호화라 보기 어렵다.

https://blog.xenomity.com/P2P-vs-SFU-vs-MCU/

P2P vs SFU vs MCU

P2P : 중앙 서버 없이 종단 간 직접 연결하는 방식. 비용 측면에서 유리하나 피어 수가 증가할수록(mesh structure) 시스템, 네트워크의 높은 capacity를 요구한다. 1:1 또는 소규모 미디어 교환에 적합하다

SFU(Selective Forwarding Unit) : 중앙 서버를 통해 종단 간 미디어 트래픽을 중계하는 중앙 서버 방식. 각 피어 연결 할당 및 암호화, 복호화 처리 비용 정도를 감수한다. 영상 방송 같은 일대다 스트리밍 서비스 구조에 적합하다.

MCU(Multi-point Control Unit) : 다수의 송출 미디어를 중앙 서버에서 혼합 또는 가공해서 수신 측으로 전달하는 중앙 서버 방식으로 클라이언트와 네트워크의 부담이 줄지만 중앙 서버의 높은 컴퓨팅 파워가 요구된다.

 

기타 다른 글들도 대충 위와 같은 느낌으로 설명하고 있어서, SFU와 MCU 같은 경우엔 따로 찾아서 공부해봐야 할 것 같다.

 

 

 

참고 URL)

 

아래의 PDF는 2019년 쓰여진 "WebRTC 애플리케이션의 설계 및 아키텍처"라는 논문이다. 영어로 써 있지만 WebRTC 자체가 외국인들이 만든 거라 할 수 없이 영어 자료를 봐야 하기 때문에 봤는데, 잘 읽어보면 도움 될 만한 내용들이 많이 있는 것 같다.

자동으로 다운받아지는 건 아니고 웹으로 볼 수 있고, 글자들을 드래그할 수 있어 번역기 돌리기도 편하다.

https://www.diva-portal.org/smash/get/diva2:1480111/FULLTEXT01.pdf