Web RTC?

WeRTC Logo

WebRTC(Web Real-Time Communications)란, 웹 어플리케이션(최근에는 Android 및 IOS도 지원) 및 사이트들이 별도의 소프트웨어 없이 음성, 영상 미디어 혹은 텍스트, 파일 같은 데이터를 브라우져끼리 주고 받을 수 있게 만든 기술입니다. WebRTC로 구성된 프로그램들은 별도의 플러그인이나 소프트웨어 없이 P2P 화상회의 및 데이터 공유를 합니다.

한마디로 웹 브라우저 상에서는 어떠한 플러그인도 필요 없이 음성 채팅과 화상채팅, 데이터 교환까지도 가능하게 하는 기술 입니다.

웹 RTC 의 장점

1. Laytency가 짧다

흔히 라이브서비스를 이용하는 인스타라이브, 유튜브라이브, 아프리카, 트위치등은 RTMP(Real-Time Messageing Protocol)을 사용합니다. Web RTC는 RTMP에 비해 비교적 최근에 나온 기술로서 RTMP보다 Laytency가 낮아 보다 지연시간이 없는 Real-Time과 비슷한 스트리밍이 가능합니다.

2. 별다른 소프트웨어 없이 실시간 커뮤니티가 가능하다

웹/앱으로 방송을 키고 싶을 때, 별도의 플로그인이나 미디어 송출 관련 소프트웨어 설치없이 가능하게 합니다. 

웹 RTC 의 단점

1. 크로스 브라우징 이슈 

현재 Chrome, FireFox, Opera등 많은 브라우저가 지원을 하지만 IE에서는 지원하지 않고 있습니다. 이런 크로스 브라우징 이슈를 해결하기 위해서는 adapter.js 라이브러리를 함께 사용하는 것이 필수적입니다. 이 라이브러리는 shim 패턴 및 폴리필을 이용해 다양한 브라우저에서 발생할 수 있는 크로스 브라우징 이슈를 사전에 처리해줍니다.

2020 WebRTC browser support on Desktop

2. STUN/TURN 서버가 꼭 필요하다

P2P통신을 하기 위해서는 사용자의 IP주소를 알아야 합니다. 하지만 대부분의 사용자는 방화벽을 사용하고 다른 네트워크 상에서 연결을 일우기 위해서는 STUN/TURN 서버가 필요합니다. 

Web RTC 통신 원리

P2P

webRTC는 P2P 방식의 커뮤니케이션이기 때문에 각각의 웹 브라우저는 다음과 같은 절차를 밟아야 합니다.

1. 각 브라우저가 P2P 커뮤니케이션에 동의
2. 서로의 주소를 공유
3. 보안 사항 및 방화벽 우회
4. 멀티미디어 데이터를 실시간으로 교환

여기에서 우리는 2번과 3번 단계가 일반적인 웹 개발의 접근 방법으로는 해결하기 어렵다는것을 알 수 있습니다. 왜냐하면 브라우저는 웹 서버가 아니기 때문에, 외부에서 접근할 수 잇는 주소가 없기 때문입니다. 때문에 webRTC가 P2P기반이긴 하지만 통신 설정 초기 단계에서는 중재자의 역할이 필요합니다.

방화벽과 NAT 트래버셜

누구인지 판단할 수 있는 이름이 각 기기에도 있습니다. 그것이 바로 IP입니다. IP는 고정, 유동으로 나뉘어서 실제 고유 값일 수도 있고 아닐 수도 있습니다. 더 나아가서는 회사망/내부망은 Privite IP이기 때문에 다른 네트워크에서는 통용되지 않습니다. 그렇기 때문에 우리가 통상적인 네트워크에서 데이터를 주고 받기 위해서는 Public IP가 필요합니다.

일반적인 컴퓨터에는 Public IP가 할당되어 있지 않습니다. 그 원인으로는 방화벽, 여러대의 컴퓨터가 하나의 공인 IP를 공유하는 NAT, 유휴 상태의 IP를 일시적으로 임대받는 DHCP 때문입니다. 이 때문에 단순히 공인 IP만을 알아낸다고 해서, 특정한 사용자를 가리킬 수는 없습니다. 공인 IP 뿐만아니라 해당 네트워크에 연결된 사설 IP 주소까지 알아내야 특정한 사용자를 지정할 수 있게 됩니다.

일반적으로는 라우터가 NAT 역할을 합니다. 외부에서 접근하는 공인 IP와 포트 번호를 확인하여 현재 네트워크 내의 사설 IP들을 적절히 매핑시켜주죠. 그러니까 어떤 브라우저 두 개가 서로 직접 통신을 하려면, 각자 현재 연결된 라우터의 공인 IP 주소와 포트를 먼저 알아내야 합니다.

하지만 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어 있을 수도 있습니다. 이처럼 라우터를 통과해서 연결할 방법을 찾는 과정을 NAT 트래버셜이라고 합니다.

STUN / TURN

좌 STUN 우 TURN

NAT 트래버셜 작업은 STUN(Session Traversal Utilities for NAT)서버에 의해 이루어집니다. STUN 방식은 단말이 아닌 자신의 Public IP 주소와 포트를 확인하는 과정에 대한 프로토콜입니다. 즉, STUN 서버는 인터넷의 복잡한 주소들 속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환해 줍니다. WebRTC 연결을 시작하기 전에 STUN서버를 향해 요청을 보내면, STUN 서버는 NAT 뒤에 있는 피어들이 서로 연결할 수 있도록 Public IP와 포트를 찾아줍니다.

하지만 STUN은 항상 효과적이지는 않습니다. 두 기기가 같은 NAT환경에 있을경우 또는 NAT의 방화벽 정책을 달리 할 수도 있고, 이전에 연결된 적이 있는 네트워크만 연결할 수 있게 제한을 걸기도 합니다. 이 때문에 STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우, TURN(Traversal Using Relay NAT) 서버를 대안으로 이용하게 됩니다.

TURN은 STUN의 확장으로 NAT환경에서 릴레이하여 통신을 하게 됩니다. NAT 보안정책이 너무 엄격하거나 NAT 순회를 하기 위해 필요한 NAT 바인딩을 성공적으로 생성할 수 없는 경우에 TURN을 사용하게 됩니다. TURN 서버는 인터넷 망에 위치하고 각 피어들이 사설망 안에서 통신합니다. 각 피어들이 직접 통신하는 것이 아니라 릴레이 역할을 하는 TURN 서버를 사용하여 경유합니다.  중간에 서버를 한 번 거치기 때문에, 엄밀히 이야기하자면 P2P 통신이 아니게 되며 그 구조상 지연이 필연적으로 발생하게 됩니다. 하지만 보안 정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이기 때문에, TURN 방식은 최후의 수단으로 선택되어야 합니다.

ICE, Candidate

STUN, TURN 서버를 이용해서 획득했던 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소들을 후보(Candidate) 라고 부릅니다. 그리고 이 과정을 후보 찾기(Finding Candidate)라고 부릅니다.

이렇게 후보들을 수집하면 일반적으로 3개의 주소를 얻게 됩니다.

• 자신의 사설 IP와 포트 넘버
• 자신의 공인 IP와 포트 넘버(STUN, TURN 서버로부터 획득 가능)
• TURN 서버의 IP와 포트 넘버 (TURN 서버로부터 획득 가능)

한편, 이 모든 과정은 ICE(Interactive Connectivity Establishment) 라는 프레임워크 위에서 이루어 집니다. ICE는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크입니다.

이제는 두 브라우저가 P2P 통신을 위해 통신할 수 있는 주소만큼은 확실하게 알아낸 셈입니다. 따라서 마지막으로 남은 것은 이제 미디어와 관련된 정보를 교환하는 것입니다.

SDP

SDP(Session Description Protocol)는 WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜입니다. 

미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 발행 구독 모델과 유사한 제안 응답 모델을 갖고 있습니다. 특정 피어가 아니한 미디어 스트림을 교환할 것이라고 제안을 하면, 상대방으로부터 응답이 오기를 기다린 다는 의미입니다.

그렇게 응답을 받게 되면, 각자의 피어가 수집한 ICE 후보 중에서 최적의 경로를 결정하고 협상하는 프로세스가 발생합니다. 수집한 후모들로 패킷을 보내 가장 지연시간이 적고 안정적인 경로를 찾습니다. 이렇게 최적의 후보가 선태고디면, 기본적으로 필요한 모든 메타 데이터와 IP 주소 및 포트, 미디어 정보가 피어 간 합의가 완료 됩니다.

이 과정을 통해 피어 간의 P2P 연결이 완전히 설정되고 활성화 됩니다. 그 후 각 피어에 의해 로컬 데이터 스트림의 엔드포인트가 생성되며, 이 데이터는 양방향 통신 기술을 사용하여 최종적으로 양방향으로 전송됩니다.

이 과정에서 NAT의 보안 이슈 등으로 최선의 ICE 후보를 찾지 못할 수도 있기 대문에 이때는 폴백으로 세팅한 TURN 서버를 P2P 대용으로 설정합니다. 

Trickle ICE

일반적으로 각 피어는 ICE 후모들을 수집해서 그 목록을 완성한 후 한꺼번에 교환하게 됩니다. 하지만 이러한 방식은 SDP의 제안 응답 모델과 맞물리면서 단점으로 작용합니다.

후보를 모으는 데에도 시간이 오래 걸리고, 그 과정에서 네트워크 환경에 따라 지연이 걸릴 수 있습니다. 도한 한 족 피어의 후보수집 작업이 완료되어야만 다른 피어가 후보를 모을 수 있기 때문에 비효율적입니다.

이러한 비효율적인 후보 교환 작업을 병렬 프로세스로 수행할 수 있게 만드는 것이 바로 Trickle ICE 입니다. 두 개의 피어가 ICE 후보를 수집하고 교환하는 과정을, 동기적 프로세스 에서 비동기적 프로세스 로 만드는 기술 입니다. Trickle 옵션이 활성화된 ICE 프레임워크는 각 피어에서 ICE 후보를 찾아내는 그 즉시 교환을 시작합니다. 그래서 상호 간 연결 가능한 ICE를 보다 빨리 찾아낼 수 있습니다. 이러한 옵션 덕분에 ICE 프레임워크는 피어 간의 연결 상태를 체크함과 동시에 연결에 걸리는 시간을 최적화할 수 있습니다.

시그널링

앞에서 이야기한 모든 과정을 일컬어 시그널링이라고 부릅니다. RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정을 의미합니다.

위의 과정을 보면 알 수 있듯이 시그널링은 WebRTC 자체에서 지원하는 기능이 아닙니다. WebRTC 연결 전 미리 준비해야 하는 과정입니다. WebRTC 자체의 스펙도 아니기 때문에, 한 가지로 딱 정해진 방법이 없습니다. 정해진 방법이 없는 이유는 알 수 없는 두 장치가 언제 어떤 방식으로 연결될 수 있는지의 모든 경우를 예측하는 것이 불가능하기 때문입니다.

만약 시그널링 서버를 직접 구축한다면 웹 소켓이나 서버 전송 이벤트 방법을 적용할 수 있습니다. 그 외에도 폴링 기법이 있습니다.

RTMP vs WebRTC

RTMP는 처음에는 Flash 플레이어 클라이언트와 미디어 파일을 호스팅하는 스트리밍 서버 간에 오디오 및 비디오 데이터를 전송하는 데 사용되었습니다. 20년 이상 된 이 기술은 널리 채택되어 많은 인기 소프트웨어( OBS ) 및 웹사이트(YouTube)에서 사용되었습니다.

RTMP 와 WebRTC 중 하나를 선택하는 것이 쉽지는 않습니다. 두 기술 모두 확실한 장점과 한계가 있기 때문입니다.

지연시간

RTMP는 TCP(Transmission Control Protocol)를 기반으로 하며 데이터 보장과 함께 주어진 순서와 순서로 데이터를 전송할 수 있습니다. 더 안정적인 네트워크 연결을 사용하더라도 대기 시간은 네트워크 설정에 따라 0.5초 이상입니다. 반면 WebRTC는 UDP를 기반으로 하며 0.1초 미만의 실시간에 가까운 레이턴시를 제공하지만 데이터 보장을 하지 않습니다. 따라서 WebRTC는 양방향 회의 또는 실시간 장치 제어에 더 적합합니다.

확장성

확장성 측면에서 RTMP는 수천 또는 수백만 명의 청중에게 라이브 스트리밍을 제공하도록 확장될 수 있습니다. 대조적으로 WebRTC는 일반적으로 천 한도 내에서 더 적은 수의 청중에게 라이브 스트리밍을 제공하는 데 자주 사용됩니다. 확장에 관해서는 RTMP가 확실히 선두를 달리고 있습니다. 수천 명의 시청자에게 라이브 스트리밍이 필요한 사용 사례의 경우 RTMP가 더 나은 선택입니다.

인코더/플레이어 및 브라우저

RTMP의 광범위한 채택으로 인해 대부분의 인코더 소프트웨어 및 비디오 플레이어에서 지원됩니다. 그러나 Flash Player의 라이브 종료로 인해 최신 브라우저에서 지원을 잃기 시작했습니다. 반면 WebRTC는 HTML5에 내장된 API 지원으로 최신 브라우저에서 더 잘 지원되며 소프트웨어나 플러그인을 설치하지 않고도 대부분의 최신 브라우저에서 재생할 수 있습니다. 인코더 또는 비디오 플레이어 지원과 관련하여 많은 소프트웨어 공급업체가 WebRTC의 인기를 인식하고 지원 목록에 WebRTC를 추가하기 시작했습니다.

요약하면 RTMP와 WebRTC는 모두 자체 비디오 스트리밍 솔루션을 구축하는 데 사용할 수 있는 인기 있는 기술입니다. RTMP는 비디오 플레이어 및 클라우드 공급업체 통합 측면에서 더 나은 지원을 제공합니다. 반면 WebRTC는 실시간에 가까운 대기 시간으로 더 빠른 스트리밍 경험을 제공하며 대부분의 최신 브라우저에서 기본적으로 지원하므로 Javascript와 같은 웹 개발 기술을 가진 사람들이 작업하기가 더 쉽습니다.

구현은 아래의 글을 참고해주세요 

https://kbs77.tistory.com/102

[webRTC, React, TypeScript] 간단하게 1:1 화상 통화를 만들어보자

 

---

참고

- https://ky266966.medium.com/rtmp-vs-webrtc-select-your-live-streaming-tech-bc0fa13346dc#:~:text=RTMP%20has%20better%20support%20in,development%20skills%20such%20as%20Javascript.

- https://gh402.tistory.com/38