짧은 IDE 제작 프로젝트를 진행하게 되었다.
프로젝트의 주요 기능중 하나인 WebRTC(Web Real-Time Communications)로 그룹 음성 채팅을 구현하는 과정을 기록하려고 한다.
WebRTC란?
웹 어플리케이션 및 사이트들이 별도의 소프트웨어 없이 음성, 영상 미디어 혹은 텍스트, 파일 같은 데이터를 브라우저끼리 주고 받을 수 있게 만든 기술이다. WebRTC로 구성된 프로그램들은 별도의 플러그인이나 소프트웨어 없이 P2P 화상회의 및 데이터 공유가 가능하다.
한마디로 웹 브라우저 상에서는 어떠한 플러그인도 필요 없이 음성 채팅과 화상 채팅, 데이터 교환까지도 가능하게 하는 기술이다.
WebRTC의 장점
1. Laytency가 짧다.
흔히 라이브러리를 이용하는 인스타라이브, 유투브라이브, 아프리카, 트위치 등은 RTMP(Real-Time Messageing Protocol)을 사용한다. WebRTC는 RTMP에 비해 비교적 최근에 나온 기술로서 RTMP보다 Laytency가 낮아 지연시간이 없는 Real-Time과 비슷한 스트리밍이 가능하다.
2. 별다른 소프트웨어 없이 실시간 커뮤니티가 가능하다.
웹/앱으로 방송을 키고 싶을 때, 별도의 플러그인이나 미디어 송출 관련 소프트웨어 설치없이 가능하게 한다.
WebRTC의 단점
1. 크로스 브라우징 이슈
현재 Chrome, FireFox, Opera등 많은 브라우저가 지원을 하지만 IE에서는 지원하지 않고 있다. 이런 크로스 브라우징 이슈를 해결하기 위해서는 adapter.js 라이브러리를 함께 사용하는 것이 필수적이다. 이 라이브러리는 shim 패턴 및 폴리필을 이용해 다양한 브라우저에서 발생할 수 있는 크로스 브라우징 이슈를 사전에 처리해준다.
2. STUN/TURN 서버가 꼭 필요하다.
P2P통신을 하기 위해서는 사용자의 IP주소를 알아야한다. 하지만 대부분의 사용자는 방화벽을 사용하고 다른 네트워크 상에서 연결을 일으키기 위해서 STUN/TURN 서버가 필요하다.
WebRTC 통신 원리
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
NAT 트래버셜 작업은 STUN(Session Traversal Utilities for NAT)서버에 의해 이루어진다. STUN 방식은 단말이 아닌 자신의 Public IP 주소와 포트를 확인하는 과정에 대한 프로토콜이다.
즉, STUN 서버는 인터넷의 복잡한 주소들 속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환해준다. WebRTC 연결을 시작하기 전에 STUN 서버를 향해 요청을 보내면, STUN 서버는 NAT 뒤에 있는 피어들이 서로 연결할 수 있도록 Public IP와 포트를 찾아준다.
하지만 STUN은 항상 효과적이지는 않다. 두 기기가 같은 NAT 환경에 있을 경우 또는 NAT의 방화벽 정책을 달리 할 수도 있고, 이전에 연결된 적이 있는 네크워크만 연결할 수 있게 제한을 걸기도 한다. 이 때문에 STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우, TRUN(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를 기반으로 하며 데이터 보장과 함께 주어진 순서와 순서로 데이터를 전송할 수 있다. 더 안정적인 네트워크 연결을 사용하더라도 대기 시간은 네트워크 설정에 따라 0.5초 이상이다. 반면 WebRTC는 UDP를 기반으로 하며 0.1초 미만의 실시간에 가까운 레이턴시를 제공하지만 데이터를 보장하지 않는다. 따라서 WebRTC는 양방향 회의 또는 실시간 장치 제어에 더 적합하다.
