MDN의 WebRTC 문서에서는 WebRTC를 다음과 같이 정의하고 있다.
WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저간에 오디오나 영상 미디어를 포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술이다.
한마디로 요약하면 드라이버나 플러그인 설치 없이 웹 브라우저간 P2P 연결을 통해 데이터 교환을 가능하게 하는 기술이다. 이 WebRTC의 등장과 발전은 개인화된 웹을 상징하는 웹 3.0과 같은 길을 걷고 있다.
월드 와이드 웹(World Wide Web)이 1990년대 처음 등장했을 때, 웹은 단순히 하이퍼링크로 연결된 정적인 문서 기반의 모델이었다. 그러다가 2000년대 중반에 이르러서는 XHR(XMLHttpRequest) 방식을 통해 페이지 전환 없이 동적으로 데이터를 받아올 수 있게 되면서, 웹은 동적인 애플리케이션을 제작할 수 있는 플랫폼이 되었다. 이 때 등장한 웹 애플리케이션들이 바로 지메일이나 페이스북, 트위터 같은 것들이 있다.
WebRTC는 기존의 웹 2.0에서 한층 더 나아가, 서버와 같은 중간자를 거치지 않고 브라우저 간을 P2P로 연결하는 기술이다. 사실 우리에게 낯설지 않은 기술들인 화상 통화와 실시간 스트리밍, 파일 공유, 스크린 공유 등이 WebRTC를 기반으로 하고 있다. P2P 연결은 중개 서버를 거치지 않기 때문에 빠른 속도가 보장되며, HTTPS가 강제되기 때문에 중간자 공격에 대한 보안이 보장된다. 그리고 실시간으로 상호작용 할 수 있다는 특성을 바탕으로 더욱 개인화되고 참여 유도적인 웹 애플리케이션을 제작할 기회가 되기도 한다.
P2P 연결에서는 속도와 보안, 효율성을 고려해야겠지만, WebRTC가 범용적으로 사용되기 위해서는 다양한 플랫폼과 브라우저에서 접속하는 사용자들에게 동일한 사용자 경험을 제공하는 일이 첫 번째일 것이다. 때문에 WebRTC에서 브라우저와 플랫폼 간 호환성은 가장 큰 숙제일 수밖에 없다.
WebRTC는 구글이 주도한 오픈소스 프로젝트를 기반으로 하는 웹 표준이기 때문에, 특히 크롬(Chrome)에서 호환성이 높다. 그리고 파이어폭스(Firefox)와 오페라(Opera) 등이 WebRTC 표준을 적극적으로 후원하고 있다. 한편 사파리(Safari) 역시 WebKit 기반 브라우저이기 때문에 WebRTC가 지원되기는 하지만, 애플의 정책이 늘 그렇듯 다른 브라우저에 비해 호환성도 가장 떨어지고 기본으로 지원해주는 설정들이 적은 편이다.
즉 WebRTC는 아직까지 다양한 플랫폼에서 표준화가 완전히 구현되지는 않은 기술이다. 정확히 이야기하자면 WebRTC 자체는 1.0 버전의 표준이 있지만, 이 규격을 모두 준수하는 플랫폼들이 아직까지 많지는 않다. 그러니깐 브라우저와 운영체제 별도로 호환성과 상호 운용성이 상이하다는 이야기이다. 그래서 각 브라우저의 WebRTC API에는 moz, webkit 같은 벤더 프리픽스(vendor prefix)가 붙어있다.
이런 크로우 브라우징 이슈를 해결하기 위해서는 adaptor.js 라이브러리를 함께 사용하는 것이 필수적이다. 이 라이브러리는 shim 패턴 및 폴리필을 이용해서 다양한 브라우저에서 발생할 수 있는 크로스 브라우징 이슈를 사전에 처리해준다. 또한, 벤더 프리픽스를 신경 쓸 필요없이 동일한 API를 호출할 수 있게 만들어주기 때문에 코드 컨벤션 유지와 개발 생산성 향상에서도 큰 도움을 준다.
결론적으로 WebRTC는 단일 브라우저 벤더에서 제공하는 API가 아니며, 브라우저와 운영체제별로 개발되는 속도와 지원되는 버전이 다르므로 호환성과 상호 운용성을 항상 체크해야 한다.
WebRTC는 P2P 방식의 커뮤니케이션이기 때문에 각각의 웹 브라우저는 다음과 같은 절차를 밟아야 한다.
- 각 브라우저가 P2P 커뮤니케이션에 동의
- 서로의 주소를 공유
- 보안 사항 및 방화벽 우회
- 멀티미디어 데이터를 실시간으로 교환
여기에서 우리는 2번과 3번 단계가 일반적인 웹 개발의 접근 방법으로는 해결하기 어렵다는 것을 확인할 수 있다. 왜냐하면 브라우저는 웹 서버가 아니기 때문에, 외부에서 접근할 수 있는 주소가 없기 때문이다. 때문에 WebRTC가 P2P 기반이긴 하지만 통신 설정 초기 단계에서는 중재자의 역할이 필요하다.
일반적인 컴퓨터에는 공인 IP가 할당되어 있지 않다. 그 원인으로는 방화벽(Firewall), 여러 대의 컴퓨터가 하나의 공인 IP를 공유하는 NAT, 유휴 상태의 IP를 일시적으로 임대받는 DHCP 때문이다. 이 때문에 단순히 공인 IP만을 알아낸다고 해서, 특정한 사용자를 가리킬 수는 없다. 공인 IP 뿐만 아니라 해당 네트워크에 연결된 사설 IP 주소까지 알아내야 특정한 사용자를 지정할 수 있게된다.
일반적으로 라우터가 NAT 역할을 한다. 외부에서 접근하는 공인 IP와 포트 번호를 확인하여 현재 네트워크 내의 사설 IP들을 적절히 매핑시켜준다. 그러니깐 어떤 브라우저 두 개가 서로 직접 통신을 하려면, 각자 현재 연결된 라우터의 공인 IP 주소와 포트를 먼저 알아내야 한다.
하지만 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어 있을수도 있다. 이처럼 라우터를 통과해서 연결할 방법을 찾는 과정을 NAT 트래버셜(NAT traversal)이라고 한다.
이 NAT 트래버셜 작업은 STUN(Session Traversal Utilities for NAT) 서버에 의해서 이루어진다. STUN 방식은 단말이 자신의 공인 IP 주소와 포트를 확인하는 과정에 대한 프로토콜이다. 즉, STUN 서버는 인터넷의 복잡한 주소들속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환해준다. 즉, WebRTC 연결을 시작하기 전에 STUN 서버를 향해 요청을 보내면, STUN 서버는 NAT 뒤에 있는 피어(Peer)들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아준다.
쉽게 말해서 다른 사람이 우리 집에 쉽게 찾아올 수 있도록 사전에 우리 집 주소를 조회해서 알아내는 것과 같다. 만약 두 개의 장치가 성공적으로 STUN 서버에서 자기 자신의 주소를 알아냈을 경우에는 P2P 연결을 시도할 두 개의 고유한 주소가 생긴 셈이다.
하지만 STUN 서버를 이용하더라도 항상 자신의 정보를 알아낼 수 있는 것은 아니다. 어떤 라우터들은 방화벽 정책을 달리 할 수도 있고, 이전에 연결된 적이 있는 네트워크만 연결할 수 있게 제한을 걸기도 한다(Symmetric NAT). 이 때문에 STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우, TURN(Traversal Using Relay NAT) 서버를 대안으로 이용하게 된다.
TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 것이다. TURN 방식은 중간에 서버를 한 번 거치기 때문에, 엄밀히 이야기 하자면 P2P 통신이 아니게 되며 그 구조상 지연이 필연적으로 발생하게 된다. 하지만 보안 정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이기 때문에, TURN 방식은 최후의 수단으로 선택되어야 한다.
여태껏 이야기한 STUN, TURN 서버를 이용해서 획득했던 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소들을 후보(Candidate)라고 부른다. 그리고 이 과정을 후보 찾기(Finding Candidate)라고 부른다.
이렇게 후보들을 수집하면 일반적으로 3개의 주소를 얻게 된다.
- 자신의 사설 IP와 포트 넘버
- 자신의 공인 IP와 포트 넘버(STUN, TURN 서버로부터 획득 가능)
- TURN 서버의 IP와 포트 넘버(TURN 서버로부터 획득 가능)
한편 이 모든 과정은 ICE(Interactive Connectivity Establishment)라는 프레임워크 위에서 이루어진다. ICE는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크이다.
지금까지의 내용을 요약하자면, ICE 프레임워크가 STUN, 또는 TURN 서버를 이용해 상대방과 연결 가능한 후보들을 갖고 있다는 것이다. 그러니깐 두 브라우저가 P2P 통신을 위해서 통신할 수 있는 주소만큼은 확실하게 알아낸 셈이다. 따라서 마지막으로 남은 것은 이제 미디어와 관련된 정보를 교환하는 것이다.
SDP(Session Description Protocol)는 WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜이다. 화상 통화 애플리케이션을 예시로 들어보자면 웹캠 비디오의 해상도를 보낼 수 있고, 오디오 전송 또는 수신 여부를 보낼 수도 있다.
이처럼 미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 발행 구독 모델(Pub/Sub)과 유사한 제안 응답 모델(Offer/Answer)을 갖고 있다. 그러니깐 어떤 피어가 이러한 미디어 스트림을 교환할 것이라고 제안을 하면, 상대방으로부터 응답이 오기를 기다린다는 의미이다.
그렇게 응답을 받게 되면 각자의 피어가 수집한 ICE 후보 중에서 최적의 경로를 결정하고 협상하는 프로세스가 발생한다. 수집한 ICE 후보들로 패킷을 보내 가장 지연 시간이 적고 안정적인 경로를 찾는 것이다. 이렇게 최적의 ICE 후보가 선택되면 기본적으로 필요한 모든 메타 데이터와 IP 주소 및 포트, 미디어 정보가 피어 간 합의가 완료된다.
이 과정을 통해서 피어 간의 P2P 연결이 완전히 설정되고 활성화된다. 그 후 각 피어에 의해 로컬 데이터 스트림의 엔드 포인트가 생성되며, 이 데이터를 양방향 통신 기술을 사용하여 최종적으로 양방향으로 전송된다.
이 과정에서 NAT의 보안 이슈 등으로 최선의 ICE 후보를 찾지 못할 수도 있기 때문에, 이때에는 폴백으로 세팅한 TURN 서버를 P2P 대용으로 설정한다.
통신에 TURN 폴백을 사용할 때 각 피어는 굳이 귀찮게 P2P로 데이터를 연결하고 전송하는 방법을 알 필요가 없다. 대신, 통신 세션 중에 실시간 멀티미디어 데이터를 중개하는 공용 TURN 서버를 알고 있어야 한다.
ICE 프레임워크를 설정하다보면 Trickle ICE 라는 옵션을 심심치않게 만나볼 수 있다.
일반적으로 각 피어는 ICE 후보들을 수집해서 그 목록을 완성한 후 한꺼번에 교환하게 된다. 하지만 이러한 방식은 SDP의 제안 응답 모델과 맞물리면서 단점으로 작용한다.
후보를 모으는 데에도 시간이 오래걸리고, 그 과정에서 네트워크 환경에 따라 지연이 걸릴 수 있다. 또한 한 쪽 피어의 ICE 후보 수집 작업이 완료되어야만 다른 피어가 ICE 후보를 모을 수 있기 때문에 비효율적이다.
이러한 비효율적인 후보 교환 작업을 병렬 프로세스로 수행할 수 있게 만드는 것이 바로 Trickle ICE 이다. 두 개의 피어가 ICE 후보를 수집하고 교환하는 과정을 동기적 프로세스에서 비동기적 프로세스로 만드는 기술이라고 할 수 있다.
즉, Trickle 옵션이 활성화된 ICE 프레임워크는 각 피어에서 ICE 후보를 찾아내는 그 즉시 교환을 시작한다. 그래서 상호 간 연결 가능한 ICE를 보다 빨리 찾아낼 수 있다. 이러한 옵션 덕분에 ICE 프레임워크는 피어 간의 연결 상태를 체크함과 동시에 연결에 걸리는 시간을 최적화할 수 있다. 결론적으로 Trickle 옵션은 가능하다면 활성화하는 게 좋다.
위에서 이야기한 모든 과정을 일컬어 시그널링(Signaling)이라고 부른다. 즉 RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정을 의미한다.
위의 과정을 보면 알 수 있듯이 시그널링은 WebRTC 자체에서 지원하는 기능이 아니다. WebRTC 연결 전에 미리 준비해야 하는 과정이다. WebRTC 자체의 스펙도 아니기 때문에, 한 가지로 딱 정해진 방법이 없다. 정해진 방법이 없는 이유는 알 수 없는 두 장치가 언제 어떤 방식으로 연결될 수 있는지의 모든 경우를 예측하는 것이 불가능하기 때문이다. 그래서 개발자는 자신에게 맞는 최적의 방법을 선택적으로 적용할 수 있다.
이 때문에 일반적으로 두 개의 장치를 연결할 수 있는 시그널링 서버를 직접 구축하거나, 시그널링 서버를 제공해주는 외부 솔루션을 적용할 수 있다.
만약 시그널링 서버를 직접 구축한다면 웹 소켓(Web Socket)이나 서버 전송 이벤트(Server-sent Event) 방법을 적용할 수 있다. 시그널링 정보를 조회할 수 있는 API를 만든 후 브라우저 단에서 주기적으로 XHR을 요청하는 폴링(polling) 기법을 쓸 수도 있다. 이 외 시그널링 서버의 구현 방법은 다양하다.
한편 WebRTC를 처음 접하는 개발자에게는 오히려 표준이 없다는 것이 혼란을 일으키곤 한다. 서버를 직접 구축하는 것도 일이 된다. 때문에 시그널링 서버를 제공해주는 솔루션을 쓰는 것도 방법이 될 수 있다. 아마존의 Kinesis Video Stream 이 대표적인 예시이고, 구글의 AppRTC에서는 Google App Engine으로 구현된 시그널링 서버를 확인할 수 있다.
그렇다고 해서 WebRTC의 현실이 밝은 것만은 아니다.
첫 번째는 역시 브라우저 간 호환성이다. 아직 adaptor.js 같은 라이브러리 없이는 다양한 브라우저의 호환성을 장담할 수 없다. 특히 사파리와 IE, 엣지가 그렇다.
다음으로는 시그널링 서버에 대한 명시적인 표준이 없다. 개발자의 능력과 자율성에 맡겨둔 부분이 오히려 처음 WebRTC를 입문하는 사람들에게 혼란을 일으키기도 한다.
마지막으로는 WebRTC는 기본적으로 실시간성이 매우 중요하기 때문에 UDP 위에서 동작한다. 즉 데이터를 빠르게 전송할 수는 있지만, 이 과정에서 발생한 데이터 손실이 발생할 수도 있다. 비디오 라던가 오디오에 있어서 몇 프레임 정도가 끊기는 것은 큰 문제가 되지는 않지만, 중요한 파일들을 전송할 때에는 이 데이터 손실이 문제를 일으킬 수도 있다. 작은 몇 바이트의 데이터 손실 때문에 전체 파일이 동작하지 않는 문제가 생길수도 있다.(TCP 방식을 사용할 수도 있지만 UDP를 사용할 수 없거나 미디어 스트리밍에 적합하지 않은 방식으로 제한되는 경우에만 사용되고, 모든 브라우저가 TCP 방식을 지원하는 것도 아니다.)
Signaling Server는 WebRTC에서 가장 기본이 되는 서버라고 할 수 있다. 서로 다른 네트워크에 있는 peer들을 연결시키기 위해서는 Session Control Messages, Error, Messages, Codec, BandWidth 등 다양한 정보가 필요하다.
결국 WebRTC 기술을 활용해서 Peer끼리 연결하기 위해서는 먼저 각각의 Peer들에게 전달돼야 한다는 것이며 이 프로세스를 Signaling이라고 한다.
이러한 정보들을 중계해주는 역할을 하는 서버가 바로 Signaling Server이다. 또한 위의 정보들을 SDP(Session Description Protocol)을 사용한다.
WebRTC와는 별개로 Signaling Server는 직접 구축해야하며, 많은 가이드에서 일반적으로 클라이언트 사이드와 WebSocket을 사용하여 통신한다.
Signaling Server를 중심으로 WebRTC의 동작 과정을 설명해보자면 다음과 같다.
Client와 Server 사이 통신은 WebSocket을 사용한다.
- Client Side의 A Client(Peer)에서
Signaling Server로 연결에 필요한 A Client의 데이터를 보낸다. ->Signaling Offer- Server Side에서,
Signaling Server에 연결된 모든 세션들에게 A Client의 데이터를 전달한다.- Client Side의 B Client(Peer)에서 A Client의 데이터를 활용해서 연결에 필요한 일련의 작업을 한 후, B Client의 데이터를 Signaling Server로 보낸다. ->
Signaling Answer- Server Side에서, A Client의 세션에게 B Client의 데이터를 전달한다.
- 각각의 데이터를 활용하여 WebRTC가 A Client와 B Client가 연결한다.
위의 Signaling Server을 이용해서 우리는 Peer간의 통신이 가능하다. 하지만 통신 중간에 방화벽, NAT 환경에 놓여있는 Peer에 대해서는 직접적인 Signaling이 불가능하다. 이 때 이어 설명할 STUN Server와 TURN Server가 필요하다.
STUN Server는 클라이언트 자신의 공인 IP(Public Address)를 알려주는 서버이다. Client에서 STUN Server로 요청을 보내서 자신의 공인 IP를 확인한 후 해당 IP를 활용하여 Signaling 하게된다.
이러한 STUN Server는 직접 구현할 필요가 없다. 이미 오픈소스, Google에서 운영하는 STUN Server를 사용하면 된다.
STUN Server 같은 경우는 단순히 정보 제공을 위한 서버라 트래픽 발생이 현저히 낮기 때문에 웬만하면 무료 STUN Server를 사용해도 문제가 크게 없다고 한다.
앞서 말한 STUN Server를 활용하면 대략 80% 정도는 Signaling을 통한 연결이 가능하다고 한다. 하지만, 그렇지 못한 20%의 경우가 존재하는데, 보호정책이 강한 NAT나 라우터, 보통 Symmetric NAT 환경에서 나타난다고 한다.
TURN Server는 Symmetric NAT 제한을 우회할 수 있게끔 해주는 기능을 수행한다. 결국 TURN Server가 Peer간의 통신 채널을 중계해주는 역할을 하며, WebRTC의 가장 큰 특징인 P2P 방식에서 벗어나게 된다.
때문에 Peer간 모든 트래픽을 중계해주기 때문에 상당한 부하를 감당해야하며, 비용 또한 크게 발생할 것이다.
즉, Local IP와 Public IP 둘다로도 연결할 수 없는 경우 TURN Server을 최후의 수단으로 사용하게 된다.
STUN Server 처럼 구글에서 무료 제공하는 TURN Server가 있다고는 하지만 앞서 말한 단점 때문에 현재는 사용을 못한하고 하고, 안정적인 서비스를 위해서는 TURN 서버를 직접 운영하는 것이 필요할 것이다.
현재는 COTURN이라는 오픈소스를 활용해 TURN 서버를 구축하는 것을 강력 추천한다고 한다.
WebRTC의 구현 방식에는 크게 3가지로 Mesh, SFU, MCU 방식이 존재한다. 사실 지금까지 위에서 말한 방식은 Mesh 방식으로 서버의 자원이 적게 들지만 Peer 수가 늘어날수록 Client 사이드의 과부하가 급격하게 증가하는 방식이다. 때문에 소규모 연결에 적합할 것이다.
Mesh 방식에서는 Media Server가 필요하지 않다. Media Server는 SFU, MCU 방식의 WebRTC에서 필요한 서버로, 각각의 Peer들은 Media Server에게 미디어 스트림들을 쏴주고 Media Server에서 미디어 트래픽을 관리하여 각각의 Peer에게 다시 배포해주는 멀티미디어 미들웨어이다.
즉, WebRTC의 특징은 P2P 통신이 아닌게 되는 것은 TURN Server와 유사하다고 할 수 있고, 클라이언트에 부하가 현저히 줄어드는 대신 서버의 부하가 커지며 구현의 난도가 상당히 높다.
Media Server가 언제, 왜 필요할지에 대해서 제대로 이해하기 위해서 아래 WebRTC 구현 방식에 대해서 살펴보자.
위에서 말했듯이 WebRTC의 구현 방식에는 크게 3가지로 Mesh, SFU, MCU 방식이 있다. 구현 방식에 있어서 당연히 장점과 단점이 존재한다. 어떤 방식을 택할지에 대한 정답은 없다.
-
특징
- 앞서 설명한
Signaling Server,STUN Server,TURN Server를 사용하는 전형적인 P2PWebRTC구현 방식이다. - 1:1 연결 혹은 소규모 연결에 적합하다.
- 앞서 설명한
-
장점
- Peer간의
Signaling과정만 서버가 중계하기 때문에 서버의 부하가 적다. - 직접적으로 Peer간 연결이 되기 때문에 실시간성이 보장된다.
- Peer간의
-
단점
- 연결된 Client수가 늘어날수록 Client의 과부하가 급격하게 증가한다.
- 간단하게 생각해봐도 N명이 접속한 화상회의라면, 클라이언트 각각에서 N-1개의 연결을 유지해야하기 때문이다.
-
특징
- 다수의 송출 미디어 데이터를
Media Server에서 혼합(muxing) 또는 가공(transcoding)하여 수신측으로 전달하는 방식이다. - P2P 방식 X, Server와 Client간의 Peer를 연결한다.
Media Server의 매우 높은 컴퓨팅 파워가 요구된다.
- 다수의 송출 미디어 데이터를
-
장점
- Client의 부하가 크게 줄어든다.
- N:M 구조에서 사용 가능하다.
-
단점
- 실시간성이 저해된다.
- 구현 난이도가 상당히 어려우며 비디오와 오디오를 혼합 및 가공하는 과정에서 고난도 기술과 서버의 큰 자원이 필요하다.
-
특징
- 각각의 Client간 미디어 트래픽을 중계하는
Media Server를 두는 방식이다. - P2P 방식이 아닌, Server와 Client간의 Peer를 연결한다.
- Server에게 자신의 영상 데이터를 보내고, 상대방의 수만큼 데이터를 받는 형식이다.
- 1:N 혹은 소규모 N:M 형식의 실시간 스트리밍에 적합하다.
- 각각의 Client간 미디어 트래픽을 중계하는
-
장점
Mesh방식보다는 느린 것은 어쩔 수 없다. 하지만 비슷한 수준의 실시간성을 유지할 수 있다.Mesh방식보다는 Client의 부하가 줄어든다.
-
단점
Mesh방식보다는 서버의 부하가 늘어난다.- 대규모 N:M 구조에서는 여전히 Client의 부하가 크다.
[참고자료]