WebRTC - 웹 브라우저 간 실시간 미디어 통신 기술

WebRTC: Web Real-Time Communication 웹 브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계된 API

 

2020년 이후 COVID-19로 인한 비대면 수업, 화상 회의, 재택 근무가 증가하면서 스트리밍 서비스에 대한 관심과 수요는 폭발적으로 증가했다.

나도 대학교 마지막 학년에는 zoom을, 싸피에 들어와서는 webex를 통해 수업을 수강하고 프로젝트 회의를 하기 때문에 에 플랫폼의 변화 흐름을 직접 느끼고 있다.

 

카카오엔터테인먼트는 2020년 스트리밍 솔루션 스타트업인 리모트몬스터를 인수한 뒤 카카오 i 커넥트 라이브를 통해 관련 서비스를 적극적으로 지원하고 있다(https://connectlive.kakaoi.ai/)

이러한 스트리밍 서비스의 관심도 증가와 함께, 해당 서비스의 지원을 가능하게 하는 WebRTC 기술에 대한 관심 또한 증가하고 있으며

리모트몬스터가 통화, 방송, 다자간 통화 등의 개발자 SDK를 지원하기 위해 선택한 API가 바로 WebRTC이다.

 

WebRTC란?

https://webrtc.org/?hl=en

WebRTC는 구글이 오픈소스화한 프로젝트에서 기원하여 IETF에 의해 프로토콜 표준화 작업, W3C에 의해 API 정의되었다.

MDN Web Docs에 의하면 웹 어플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술이라고 한다.

WebRTC의 구현은 아직 완료되지 않았고 계속해서 진화하는 기술이기 때문에 아직 모든 브라우저에서의 동작을 완전히 지원하는 것은 아니다. 현재는 크롬과 파이어폭스에서 높은 호환성을 보이고 있다.

 

WebRTC가 통신하는 법

WebRTC는 브라우저 - 브라우저 간의 P2P 통신을 위한 커넥션 구축을 위해 ICE(Interactive Connectivity Establishment) framework를 사용한다.

일반적으로 Peer A - Peer B 간의 직접적인 연결이 어려울 수 있는데, 이를 막는 방화벽을 우회하고 공용 IP 주소가 없는 경우 고유한 주소를 제공하고 라우터가 직접 연결을 허용하지 않을 경우 서버를 통해 연결해야 한다.

ICE는 STUN/TURN 서버를 사용하여 이를 수행한다.

 

STUN - Session Traversal Utilities for NAT

: 실시간 음성, 비디오, 메시징 어플리케이션, 기타 상호작용 통신 부문에서 NAT 게이트웨이의 traversal을 위한 네트워크 프로토콜을 포함하는 메소드들의 표준

 

디바이스에 공용 IP 주소를 제공하는 데에는 NAT(Network Address Translation)가 사용된다. 라우터에는 공용 IP 주소가 존재하고, 라우터는 연결된 모든 디바이스에 사설 IP 주소를 제공한다. 요청은 디바이스의 개인 IP에서 고유한 포트가 있는 라우터의 공용 IP로 변환된다.

클라이언트는 STUN 서버로 자신의 공용 IP 주소와 라우터의 NAT로 접근 가능한지 여부에 대해 요청한다.

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols/webrtc-stun.png

하지만 STUN 방식을 통해 반드시 연결할 수 있는 것은 아니다. 라우터가 디바이스에 연결할 수 있는 사용 제한을 걸거나, 방화벽 정책이 있을 수 있기 때문에 공용 IP 주소를 가지고 있더라도 아무나 연결할 수는 없다.

따라서 그러한 상황에서는 TURN 방식으로 전환한다.

 

TURN - Traversal Using Relays around NAT (TURN)

: 네트워크 미디어 중개 서버를 이용하여 모든 데이터를 릴레이하여 공용 IP 주소와 포트를 제공하는 프로토콜

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols/webrtc-turn.png

중개 서버를 거치는 것은 분명한 오버헤드를 수반하기 때문에 가능하다면 STUN 방식이 선호된다. 우리가 사용할 수 있는 대표적인 미디어 서버로는 Kurento가 존재한다.

 

ICE는 STUN/TURN 서버를 이용하여 획득한 IP주소, 프로토콜, 포트 조합으로 구성된 연결 가능한 네트워크 주소들을 수집한다. 이를 Candidate라고 한다.

 

SDP - Session Description Protocol

: 데이터 전송 시 두 Peer의 협의를 위해 미디어 타입, 포맷, 코덱, 암호화 등의 멀티미디어 콘텐츠에 대해 기술하는 프로토콜

미디어에 대한 정보를 기술하는 SDP는 Offer/Answer 방식에 의해 대해 최적의 연결을 수립할 수 있는 네트워크 커넥션을 찾는다. 이상적으로는 속도가 빠르고 interruption에도 쉽게 복구가 가능한 UDP가 candidate로 선호된다.

(아직 커넥션 수립에 대해서는 완벽히 이해하지 못했기 때문에 자세히 기술된 아래의 링크를 참고하자)

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity

WebRTC connectivity - Web APIs | MDN

 

이러한 모든 과정을 Signaling 이라고 한다.

즉, RTCPeerConnection에 사용되는 프로토콜, 포맷, 코덱, 미디어 타입, 네트워크 수립 과정 등을 모두 포함하는 과정을 의미한다.

하지만 이러한 과정을 WebRTC에서 직접 지원하는 것은 아니고 개발자가 직접 구축해야 하는데, Amazon Kinesis Video Streams WebRTC SDK for JavaScript 혹은 AppRTC Demo Code가 시그널링 서버를 지원한다고 한다.

 

마치며

아직 WebRTC를 직접 사용해보지 않았기 때문에 WebRTC가 어떤 기술인지 알아보고자 구글링을 하며 포스팅을 정리하게 되었다.

카카오엔터프라이즈에서 서비스하고 있는 카카오 i 커넥트 라이브에서의 WebRTC셀에서 미디어 콘텐츠 보안을 위해 E2EE 기술을 적용하고 있다고 한다.

https://tech.kakaoenterprise.com/101

화상회의 보안성 향상을 위한 E2EE 기술 연구 #WebRTC #Insertable Stream

보안성 요구사항을 위한 꽤 흥미로운 글 같으니 후에 참고해도 좋을 것 같다 !!

 

참고 자료

• https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API
• https://tech.kakaoenterprise.com/101
• https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html
• https://webrtc.org/
• https://blog.sessionstack.com/how-javascript-works-webrtc-and-the-mechanics-of-peer-to-peer-connectivity-87cc56c1d0ab
• https://doc-kurento.readthedocs.io/en/latest/user/intro.html