WebRTC란 무엇일까?

화상 회의 플랫폼을 제작하는 프로젝트를 진행한 적이 있다. 그 때, WebRTC 기술을 기반으로 사용하는 OpenVIdu를 사용했었는데 정확한 이론을 알고 한 게 아니여서 한 번 알아보는 시간을 가져보기로 했다.
비록 OpenVidu 썼지만...
 

WebRTC?

서버(중간자)를 최대한 거치지 않고 P2P(Peer-to-Peer Network)로 브라우저나 단말 간 데이터를 주고받는 웹 기술 표준.
=> 드라이버나 플러그인 설치 없이 웹 브라우저 간 P2P 연결을 통해 데이터 교환을 가능하게 하는 기술로 UDP 기반의 스트리밍 기술이다.

 
zoom, webex, 보이스 톡 등등.....
1:1, 1:N, N:N....
 
 

P2P 절차

 WebRTC는 P2P 방식의 커뮤니케이션이어서 각각의 웹 브라우저는 다음과 같은 절차를 밟아야 한다.
 
1. 각 브라우저가 P2P 커뮤니케이션에 동의
2. 서로의 주소를 공유 ?
3. 보안 사항 및 방화벽 우회 ?
4. 멀티미디어 데이터를 실시간 교환
 
 2번과 3번의 단계는 일반적인 웹 개발 접근 방법으론 해결하기 어렵다. 브라우저는 서버가 아니기 때문에 외부에서 접근 할 수 있는 주소가 없기 때문이다.
이를 해결하기 위해 P2P 기반이지만, 통신 설정 초기 단계에서는 중재자(서버)가 필요하다!
=> P2P 방식이지만 서버가 필요한..!
 

방화벽과 NAT 트래버셜

  일반적인 컴퓨터에는 공인 IP가 할당되어 있지 않다. 그 원인으로는 방화벽 (Firewall), 여러 대의 컴퓨터가 하나의 공인 IP를 공유하는 NAT, 유휴 상태의 IP를 일시적으로 임대받는 DHCP 때문이다. 이 때문에 단순히 공인 IP만 알아낸다 해서, 특정 사용자를 가리킬 수는 없다. 공인 IP뿐만 아니라 해당 네트워크에 연결된 사설 IP 주소까지 알아내야 사용자를 특정할 수 있다.
 
 일반적으로 라우터가 NAT 역할이다. 외부에서 접근하는 공인 IP와 포트 번호를 확인해 현재 네트워크 내 사설 IP들을 적절히 매핑시킨다. => 어떤 브라우저 두개가 서로 직접 통신하려면, 현재 연결된 라우터의 공인 IP 주소와 포트 먼저 알아야 한다.
 
 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽이 설정되어 있을 수도 있다. => 이걸 제한적 NAT이라 하는데, 오직 이전에 연결된 적 있었던 연결들만 허용한다. (Symmetric NAT)이다.
 
아무튼, 이처럼 라우터를 통과해 연결할 방법을 찾는 과정을 NAT 트래버셜이라 한다.
 
 
그리고 이러한 과정을 거쳐서 P2P 통신을 가능하게 하는 두 가지 방식의 서버가 존재한다.

STUN과 TURN

STUN(Session Traversal Utilities for NAT)은 NAT 트래버셜 작업을 한다. STUN은 단말이 자신의 공인 IP 주소와 포트를 확인하는 과정에 대한 프로토콜이다. 즉, STUN 서버는 인터넷의 복잡한 주소들 속 유일하게 자기 자신을 식별할 수 있는 정보를 반환해 준다!
 WebRTC의 연결을 시작하기 전에 STUN 서버로 요청을 보내면, STUN 서버가 NAT 뒤에 있는 피어들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아준다. => 중재자..!
 
 하지만, STUN 서버로 항상 자신의 정보를 알아낼 수 있는 것은 아니다. 위에서 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽이 설정되어 있을 수도 있다고 했다. 그 경우에는 사용 불가능한 웹 페이지가 말이 되나..
 
 그럴경우, P2P 통신은 아니지만 TURN(Traversal Using Relay NAT)서버를 대안으로 사용한다. TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 것이다. 즉, TURN 서버에 패킷을 보내고, 다시 전송한다.(서버를 통해서 데이터 전송)
 
 

ICE와 Candidate

 STUN, TURN 서버를 이용해 획득한 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소들을 후보(Candidate)라 한다.
 
 이렇게 후보들을 수집하면 일반적으로 3개의 주소를 얻게 되는데
 1) 자신의 사설 ip와 포트 번호
 2) 자신의 공인 ip와 포트 번호 (STUN, TURN에서 획득)
 3) TURN 서버의 IP와 포트 번호 ( TURN 서버로 부터 획득)
 
 이 모든 과정은 ICE(Internative Connectivity Establishment)라는 프레임워크 위에서 행해진다.
=> 즉, ice는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임 워크이다.
 

SDP

 
SDP(Session Description Protocol)는 WebRTC에서 스트리밍 미디어 해상도, 형식, 코덱 등 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜이다.
 
 미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 발행 구독 모델(Pub/Sub)와 유사한 제안 응답 모델(Offer/Answer)을 갖고 있다. 어떤 피어가 이러한 미디어 스트림을 교환할 것이라 제안하면, 상대방으로부터 응답이 오기를 기다린다는 것이다.
 
 응답을 받으면, 각자 피어가 수집한 ICE 후보 중 최적의 경로를 결정하고 협상하는 프로세스가 발생한다.수집한 ICE 후보들로 패킷을 보내 가장 지연 시간이 적고 안정적인 경로를 찾는 것이다. 이렇게 최적의 ICE 후보가 선택되면, 기본적으로 필요한 모든 메타 데이터와 IP 주소 및 포트, 미디어 정보가 피어 간 합의 완료된다.
 
 
Tricle ICE란 것도 있는데....
https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html
 
 
 

시그널링

위의 모든 과정을 일컬어 시그널링이라 부른다.
즉, RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정을 의미한다.
 
시그널링은 WebRTC 자체에서 지원하는 기능이 아닌, WebRTC 연결 전 미리 준비해야하는 과정이다. 어떤 방법으로든 개발자 본인에게 맞는 최적의 방법을 선택적으로 적용할 수 있다.
 
웹 소켓(Web Socket), 서버 전송 이벤트(SErver-sent Event) 방법을 적용할 수 있다고 한다. 시그널링 정보를 조회할 수 있는 api를 만든 후 브라우저 단에서 주기적으로 XHR을 요청하는 폴링 기법도 사용가능하다고 한다.
 
 
 
참고
[강추]
https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html

WebRTC는 어떻게 실시간으로 데이터를 교환할 수 있을까? - 재그지그의 개발 블로그

https://tech.kakaoenterprise.com/121

WebRTC 응용 서비스를 개발하는 2가지 방법

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

[WebRTC] WebRTC란?

 
[시그널링 서버 구현 방법]
https://github.com/muaz-khan/WebRTC-Experiment/blob/master/Signaling.md
[WebRTC 공식]
https://webrtc.org/

WebRTC

[WebRTC 모질라 문서 - API]
https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API

WebRTC API - Web API | MDN

[시그널링?]
https://webrtcforthecurious.com/docs/02-signaling/

Signaling

[백엔드에게 추천하는]
https://web.dev/articles/webrtc-infrastructure?hl=ko

WebRTC 앱에 필요한 백엔드 서비스 빌드  |  Articles  |  web.dev