WebRTC (Web Real-Time Communication)

WebRTC

WebRTC는 웹 환경에서 실시간으로 미디어 데이터들을 활용하여 커뮤니케이션할 수 있도록 도와주는 기술이다.

WebRTC를 사용하면 실시간 통신 기능을 어플리케이션에 추가하여 동영상, 음성, 일반 데이터를 어플리케이션 간에 전송할 수 있어 개발자가 강력한 음성 및 영상 통신 솔루션을 구축할 수 있다.

또한, 모든 최신 브라우저 뿐만 아니라 모든 주요 플랫폼의 기본 클라이언트에서 사용할 수 있다는 장점이 있다.

오픈 소스 기반이기 때문에 누구나 쉽게 접근하여 구현할 수 있다는 점 또한 장점이다.

 

따라서 WebRTC는 웹 브라우저 상에서 어떠한 플러그인이나 별도의 소프트웨어 필요없이 음성 채팅, 화상 채팅, 데이터 교환까지 가능하게 하는 기술이다.

 

 

# Peer to Peer (P2P) 기반의 WebRTC

 

 

WebRTC 특징

(1) 서버와 같은 중간자를 거치지 않고 브러우저 간 P2P로 연결하는 기술.

(2) 별도의 플러그인, 소프트웨어 필요없이 화상 채팅과 같은 미디어 자원 커뮤니케이션 가능.

(3) 서버와 같은 중간자를 필요로 하지 않기 때문에 빠른 속도를 자랑.

(4) HTTPS 가 강제되기 때문에 보안성이 좋음.

(5) 실시간으로 상호작용(커뮤니케이션) 할 수 있기 때문에 개인화되고 참여 유도적인 웹 어플리케이션 제작 가능

 

 

 

WebRTC 브라우저 호환성

WebRTC는 구글이 주도한 오픈소스 프로젝트를 기반으로 하는 웹 표준이어서 크롬환경에서 호환성이 높다.

WebRTC는 아직까지 다양한 플랫폼에서 표준화가 완전히 구현되지는 않았다.

WebRTC 자체에는 1.0 버전의 표준이 있지만, 이 규격을 모두 준수하는 플랫폼들이 아직은 많지 않다.

 

이러한 플랫폼, 브라우저들의 호한성에 따른 크로스 브라우징 이슈를 해결하기 위해서는 adapter.js 라이브러리를 함께 사용하는 것이 필수이다.

adapter.js는 shim 패턴 및 폴리필을 이용해 다양한 브라우저에서 발생할 수 있는 크로스 브라우징 이슈를 사전에 처리해준다고 한다.

 

따라서, WebRTC는 단ㅇ닐 브라우저 벤더에서 제공하는 API가 아니며, 브라우저와 운영체제별로 개발되는 속도와 지원되는 버전이 다르므로 호환성과 상호 운용성을 항상 체크해야 한다.

 

 

 

WebRTC P2P 절차

(1) 연결하고자 하는 각 브라우저가 P2P 커뮤니케이션에 대해 동의

(2) 서로의 주소를 확인 및 공유

(3) 보안 사항 및 방화벽 우회

(4) 멀티미디어 데이터를 실시간으로 교환

 

 

 

방화벽 / NAT 트래버설

WebRTC 를 사용하려면 이후에 설명할 STUN / TURN 서버가 필요한데, 해당 서버들을 통해 각 단말(Peer) 간의 IP를 확인하고 연결하고자 하는 단말끼리 공유를 하고 연결을 해야하나 이 과정이 간단하지 않다.

왜냐하면 각 단말 간의 보안 환경 혹은 방화벽의 유무와 같은 보안 설정이 다 다를 것이기 때문에 이에 대한 접근을 허용하고 접근하는 것은 매우 까다로운 일이다.

따라서, 방화벽과 같은 보안 기능을 우회하여 접근하는 것이 필요하다.

 

우회하기 이전에 서로의 IP를 확인하고 공유하는 것이 필요하다고 했다.

하지만 일반적인 컴퓨터에는 공인 IP가 각각 따로 할당되어 있지 않다.

왜냐하면 앞서 말한 방화벽, 여러 대의 컴퓨터가 하나의 공인 IP 를 공유하는 NAT, 유휴 상태의 IP를 일시적으로 임대받는 DHCP 때문이다.

이 떄문에 단순히 공안 IP를 알아냈다고 해서 특정 사용자 즉, 연결하고자 하는 단말 사용자를 가리킬 수는 없으며 이러한 이유 때문에 공인 IP 뿐만 아니라 해당 네트워크에 연결된 사설 IP 주소까지 알아내야 특정 사용자를 지정할 수 있게 되는 것이다.

 

일반적으로 라우터가 NAT 역할을 한다.

외부에서 접근하는 공인 IP와 포트 번호를 확인하여 현재 네트워크 내의 사설 IP들을 적절히 매핑시켜준다.

따라서, 어떠한 두 개의 브라우저가 서로 직접적으로 통신을 하려면 각자 현재 연결된 라우터의 공인 IP 주소와 포트를 먼저 알아내야 한다.

 

하지만 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어있을 수도 있기 때문에 위에서 말한 것처럼 라우터를 통과해서 연결할 방법을 찾아야 한다.

이 과정을 NAT 트래버설 이라고 한다.

 

 

 

STUN / TURN 서버

NAT 트래버설은 STUN 서버에 의해 이루어진다.

STUN 방식은 단말이 자신의 공인 IP 주소와 포트를 확인하는 과정에 대한 프로토콜이다.

즉, STUN 서버는 인터넷의 복잡한 주소들 속에서 유일한 자신의 정보(IP, 포트번호 등)를 반환해준다.

WebRTC를 연결하고 시작하기 이전에 STUN 서버에 요청을 보내면, STUN 서버는 NAT 뒤에 있는 단말(Peer) 들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아준다.

 

하지만 STUN 서버를 이용하더라도 항상 자신의 정보를 알아낼 수 있는 것은 아니다.

라우터들마다 방화벽 정책이 다를 수도 있고, 이전에 연결된 적이 있는 네트워크만 연결할 수 있게 제한을 걸기도 하기 때문에 STUN 서버를 통해 자신의 주소를 찾아내지 못했을 경우에 대비책으로 TURN 서버를 대안으로 이용한다.

 

TURN 서버는 네트워크 미디어를 중개하는 서버를 이용하는 것이다. (미디어 서버)

TURN 서버는 중간에 서버를 한 번 거치기 때문에 직접 단말간의 연결하는 P2P 방식 통신으로 볼 수 없고 또한 서버를 거치는 구조상 지연이 필연적으로 발생하게 된다.

TURN 서버를 이용하는 것은 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이기 때문에 최후의 수단으로 사용된다.

 

 

 

ICE / Candidate

STUN / TURN 서버를 이용해서 획득했던 IP 주소, 프로토콜, 포트로 구성된 연결가능한 네트워크 주소들을 후보(Candidate)라고 부른다.

이 주소들을 알아내는 과정을 후보 찾기라고 한다.

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

 

1. 자신의 사설 IP 주소와 포트 번호
2. 자신의 공인 IP 주소와 포트 번호 (STUN, TURN 서버를 통해 획득 가능)
3. TURN 서버 IP 주소와 포트 번호 (TURN 서버를 통해 획득 가능)

이러한 주소들을 STUN / TURN 서버를 통해 IP주소, 포트 번호들을 알아낸 뒤에 각 단말끼리 P2P 연결을 가능하게 하도록 최적의 경로를 찾아내주는 프레임워크가 ICE이다.

즉,  STUN 과 TURN 서버는 ICE 프레임워크 위에서 동작되는 것이다.

 

내용을 요약하자면, ICE 프레임워크가 STUN, 또는 TURN 서버를 이용해 상대방과 연결 가능한 후보들을 갖고 있다는 것이다.

그러니까 두 브라우저가 P2P 통신을 위해 통신할 수 있는 주소만큼은 확실하게 알아낸 셈이다.

따라서 마지막으로 남은 것은 이제 미디어와 관련된 정보를 교환하는 것이다.

 

 

 

SDP (Session Description Protocol)

WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위한 프로토콜이다.

미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 pub / sub 구조와 유사한 제안 응답 모델을 갖고있다. (stomp 와 유사)

아따힌 단말(peer)가 이러한 미디어 스트림을 교환할 것이라고 제안하면, 상대방으로부터 응답이 오기를 기다린다는 뜻이다.

 

응답을 받게 되면, 각 단말이 수집한 ICE 후보 중에서 최적의 경로를 결정하고 협상하는 프로세스가 발생된다.

수집한 ICE 후보들로 패킷을 보내 가장 지연 시간이 적고 안정적인 경로를 찾는 것이다.

이렇게 최적의 ICE 후보를 선정하면, 기본적으로 필요한 모든 메타 데이터와 IP 주소 / 포트, 미디어 정보가 단말간에 합의가 완료된다.

이 과정을 통해 단말 간의 P2P 연결이 완전히 설정되고 활성화된다.

그 후 각 단말에 의해 로컬 데이터 스트림의 엔드포인트가 생성되며, 이 데이터는 양방향 통신 기술을 사용하여 최종적으로 양방향으로 전송된다.

 

이 때 NAT의 보안 이슈 등으로 인해 최적의 ICE 경로를 찾지 못할 수도 있기 때문에, 이때에는 Fall back(폴백)으로 세팅한 TURN 서버를 P2P 대용으로 설정한다.

통신에 TURN 폴백을 사용할 때 각 단말은 굳이 P2P로 데이터를 연결하고 전송하는 방법을 알 필요가 없다.

중간 미디어 서버를 이용하기 때문에 해당 미디어 서버(TURN 서버)를 알고 있어야 한다.

 

 

 

Trickle ICE

각 단말들이 ICE 후보들을 수집하여 최적의 ICE를 선별한 후 교환하는 작업을 병렬 프로세스로 수행할 수 있게 만드는 것이 Trickle ICE 이다.

즉, 두 단말이 ICE 후보를 수집하고 교환하는 과정을 동기 방식에서 비동기 방식으로 만드는 기술이다.

따라서 Trickle ICE 옵션이 활성화된 ICE 프레임워크는 각 단말에서 ICE 후보를 찾아내는 즉시 교환을 시작한다.

그래서 상호 간 연결이 가능한 ICE를 보다 빠르게 찾아낼 수 있으며,동시에 단말 간의 연결 상태를 체크함과 동시에 연결에 걸리는 시간을 최적화할 수 있다.

 

 

 

Signalling (시그널링)

위에서 말했던 과정들을 하나로 묶어 시그널링 이라고 부른다.

RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식 - (SDP), 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정을 의미한다.

 

이러한 일련의 시그널링 과정은 WebRTC 자체에서 제공하는 것이 아니라 WebRTC를 연결하기 이전에 미리 준비해야 하는 과정이다.

WebRTC 자체 제공 기능이 아니기 때문에 한가지로 정의되는 것이 아니라 여러 방법으로 구성할 수 있는 과정이다.

대표적으로 연결하고자 하는 두 단말간의 환경이 다 틀려서 모든 경우를 예측하는 것이 불가능하기 때문이다. (예 : 방화벽 유무)

 

따라서 두 개의 장치를 연결할 수 있는 시그널링 서버를 직접 구축하거나, 시그널링 서버를 제공해주는 외부솔루션을 적용할 수 있다.

 

시그널링 서버를 직접 구축한다면, 웹 소켓이나 서버 전송 이벤트를 활용하는 방법을 적용할 수 있을 것이다.

시그널링 정보를 조회할 수 있는 API를 만든 다음 브라우저 단에서 주기적으로 XHR(XMLHttpRequest)를 요청하는 폴링(Polling) 방법을 쓸 수도 있을 것이다.

하지만 폴링 방식은 주기적인 시점마다 요청을 보내기 때문에 쓸데없는 커넥션을 계속해서 만들기 때문에 부하를 주의해야하고 메모리 관리도 해주어야 할 것이다.

(시그널링 서버 구현 방법 참고 방법 : https://github.com/muaz-khan/WebRTC-Experiment/blob/master/Signaling.md)

 

# 나는 이전에 게임프로젝트를 진행하면서 시그널링 서버를 직접 구축하는 것이 아닌 외부에서 제공해주는 Openvidu라이브러리를 사용하였다.

여러 사람이 한번에 게임방에 입장하여 카메라 및 마이크를 사용해야 했기에 단순 P2P 기반으로 운영되는 기본적인 WebRTC만으로는 벅차다고 생각했고, Openvidu는 N대N 연결을 가능하게 해주는 라이브러리 이기에 적합하다고 생각하여 적용하였다. 

 

 

 

WebRTC 한계점

(1) 브라우저 간 호환성

- 아직 adapter.js 와 같은 라이브러리 없이는 다양한 브라우저의 호환성을 장담할 수 없다.

   사파리, Internet Explore, 마이크로 엣지같은 브라우저들이 그러하다.

 

(2) 시그널링 서버에 대한 명확한 표준이 없다.

- 외부솔루션을 활용하는 것이 아닌 직접 시그널링 서버를 구현하게 되면 개발자가 자율적으로 구성하고 구현해야 하는데, 명확한 표준이 없기 때문에 처음 WebRTC를 접하고 구현하려는 개발자들에게 혼란이나 어려움을 줄 수 있다.

 

(3) 프로토콜 환경

- WebRTC는 이름에서도 알 수 있듯이 실시간으로 커뮤니케이션 하는 것에 주요 목적이 있는 기술이다.

따라서 UDP 환경에서 주로 동작하는데, UDP의 특성상 데이터를 빠르게 전달할 수는 있지만, 이 과정에서 신뢰성을 보장하지 않기 때문에 데이터 유실이 발생할 수 있다.

중요한 파일들을 전송할 때 약간의 데이터 유실이 발생하여 아예 해당 파일들을 사용할 수 없게 될 수도 있을 것이다.

 

 

 

 

[도움받은 출처 글들]

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

WebRTC 프로토콜 소개 - Web API | MDN

https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html

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

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

WebRTC