여러분이 꼭 알아야만 하는 WebRTC Signaling 서버

WebRTC는 P2P방식의 프로토콜이라고 들었을 것입니다. 언뜻 보기에 분명하지 않지만 WebRTC를 동작시키기 위해 서버가 필요하지 않다는 것을 의미합니다. 가장 기본적인 서버는 WebRTC Signaling Server입니다. 이 서버는 장치(Device)가 통신하려는 다른 장치에 연결될 수 있도록 합니다. 이와 같이 “사용자(User)”가 아닌 “기기(Device)”라는 용어를 사용하는 이유는 두 가지 주요 이유 때문입니다.
상대방을 연결하지 않고 컴퓨터나 비디오 스트리밍(감시 카메라의 소스 또는 비디오 레코더 싱크)에 연결했을 수 있습니다. 사용자는 여러 장치를 가질 수 있으며 또한 사용자에게 연결하려는 동안 WebRTC는 장치를 이해해야만 합니다.
시작하기 전에 WebRTC를 처음 사용하는 경우 아래 기술하는 내용을 읽고 용어에 익숙해지기를 바랍니다.

WebRTC 신호는 어떻게 작동할까요?

WebRTC 신호 서버의 기능 이해를 돕기 위하여 아래 다이어그램으로 시작할 예정입니다.

WebRTC 호출이 WebRTC에서 연결되는 방법을 설명하기 위해 과정을 그림을 통해 사용하였습니다.
맨 위에 있는 서버는 두 사용자가 서로를 찾는 방법입니다. 둘 다 WebRTC의 범위를 벗어난 서버에 연결되어 있습니다. 예를 들어 소셜 네트워크에 등록된 두 사람, 의사 및 환자가 예정된 방문에 로그인하고 웹사이트를 탐색하고 사이트 소유자를 “호출”하려는 사람 등이 될 수 있습니다.
①에서 ④까지 표시된 상호작용은 WebRTC의 일부인 제안. 응답에 대한 메커니즘입니다. 이 메시지는 WebRTC 메시지가 아니라 SDP가 포함된 독점적인 메시지입니다. 여기서 일어나는 일은 WebRTC가 SDP Blob을 생성한다는 것입니다. 이들은 세션을 연결하기 위해 응용 프로그램이 다른 장치에 신호를 보내야 하는 메시지 조각입니다. 자체 시그널링 프로토콜과 WebRTC 시그널링 서버를 사용하여 이를 수행합니다.
그림의 다섯 째 줄(⑤)은 실제 미디어를 나타내며 장치 간에 직접 전송됩니다. 거기에 도달하려면 장치가 먼저 신호 서버를 통해 통신해야만 합니다.

그렇다면 시그널링 서버(Signaling Server)는 무엇일까요?

WebRTC 신호 서버(WebRTC Signaling Server)는 장치 간의 연결을 관리하는 서비입니다. 미디어 트래픽 자체를 다르지 않고 신호만을 처리합니다. 여기에는 한 사용자가 네트워크에서 다른 사용자를 찾을 수 있게 하고 연결 자체를 협상하고 필요한 경우 연결을 재설정하고 종료하는 것이 포함됩니다.
흥미로운 점은 WebRTC 신호 서버가 WebRTC에 특정한 작업을 수행하지 않는다는 것입니다. 응용 프로그램에서 지시한 논리에 따라 메시지를 전달하는 데 도움이 됩니다.
시그널링을 위해 SIP over WebSocket, XMPP 또는 MQTT와 같은 표준 프로토콜을 선택할 수 있습니다. 그러나 대부분의 개발자는 자신의 응용 프로그램에 맞는 독점적인 신호 프로토콜을 사용합니다. 왜냐하면 어쨌든 사용자 간의 통신 메커니즘이 필요하며 이는 WebRTC 또는 순수한 음성 또는 비디오 통신에 필요한 것보다 광범위합니다. 데이터 응용 프로그램을 생각해 보기 바랍니다. 응용 프로그램에는 이미 사람들을 연결하는 일종의 “신호”가 있으므로 동일한 신호 프로토콜을 통해 화상 통화를 추가하면 다른 대안을 추가하는 것보다 의미가 있습니다.

NAT 통과 및 ICE 후보(예상자) 교환

수행해야 할 작업 중 일부는 방화벽과 NAT 장치를 통과하는 것입니다. 이는 ICE라는 프로토콜을 사용하여 수행되며 이 프로토콜은 ICE 후보(예상자)를 사용하여 세션을 수집, 교환 및 연결을 시도합니다.
ICE 후보는 디바이스가 서로 서로 연결할 수 있는 잠재적인 주고 쌍입니다. 즉 이 경우는 다음과 같은 두 가지 경우 일 것입니다.
① STUN 서버를 통해 얻은 개인 또는 공용 IP 주소를 사용하여 직접 연결
② TURN 서버를 통해 간접적으로 장치를 서로 연결
위의 그림은 교환 중인 ICE 후보를 보유하는 신호 메시지를 보여줍니다. 이들은 다른 유형의 IP 주소를 보유한 다음 연결 확인에 사용됩니다.
초기 제안. 답변 SDP 메시지와 마찬가지로 이 ICE 후보는 신호 메시지로 래핑 하여 도움말(Help) WebRTC 신호 서버와 함께 전송됩니다.
대부분의 리소스에서 여기서는 ICE 협상에 사용되는 STUN 및 TURN 서버에 중점을 두는 경향이 있으며 신호 자체가 협상 자체를 촉진한다는 사실에 대해서는 덜 중점을 둡니다.

다른 WebRTC 서버

지금까지 우리는 두 가지 유형의 서버를 보았습니다. 그러나 WebRTC가 작동하려면 종종 4가지 유형의 WebRTC 서버가 필요합니다. 다른 두 가지 유형은 응용프로그램을 개발하는 데 사용되는 일반적인 웹서버인 응용 프로그램 서버와 미디어 서비입니다.
4가지 유형의 서버
① WebRTC Application Server: 기본적으로 서버스를 호스팅 하는 웹사이트
② WebRTC Signaling Server: 클라이언트가 서로를 찾고 서로 연결하는 방법을 제공하는 서버
③ NAT traveral servers for WebRTC: NAT 및 방화벽을 통한 연결을 지원하는 데 사용되는 서버
④ WebRTC media servers: 그룹 통화, 녹화, 방송 및 기타 복잡한 기능을 위한 미디어 처리 서버
미디어 서버는 모든 WebRTC 배포에 반드시 필요한 것은 아니지만 많은 배포에서 일반적으로 필요합니다. 이들은 일대다 방송뿐만 아니라 그룹 세션에서 중요한 역할을 합니다.
여기에서 방송 서버에서 미디어 서버가 어디에 적합한 지 살펴보겠습니다.

일대다 WebRTC 브로드 캐스팅에 미디어 서버가 필요한 이유

WebRTC 미디어를 대규모 장치 그룹으로 스트리밍 할 때는 미디어 서버를 사용해야만 합니다.
여러분이 WebRTC를 사용하여 1Mbps 비디오 스트리밍을 생성하여 100명의 시청자에게 실시간으로 방송을 한다고 가정해 보겠습니다.
만일 미디어 서버가 없으면 사용하는 장치가 100Mbps 업링크 연결을 사용해야 합니다. 이 연결은 일반적이지 않고 여러 가지 방법으로 리소스를 낭비합니다. 또한 장치가 많은 수의 열린 연결로 이러한 부하를 견뎌야 한다는 과제를 추가하면 이것은 어떻게 실현 가능한 대안이 아닌지 알 수 있습니다.
이러한 경우, 솔루션은 스트리밍 미디어 서버를 사용하는 것입니다. 브로드캐스트 장치는 미디어 스트리밍을 미디어 서버로 전송하여 해당 콘텐츠를 시청자에게 스트리밍 합니다. 이 접근 방식의 좋은 점은 미디어 서버가 트랜스 코딩을 처리하고 WebRTC 스트리밍을 다른 프로토콜로 다시 패키지 할 수도 있다는 것입니다. 이 경우 미디어 서버는 신호 서버 역할을 할 수도 있습니다.
위와 같은 방식을 위해서 와우자 스트리밍 엔진 또는 와우자 클라우드를 이용하기 바랍니다. 이들 두 제품은 모두 현재 WebRTC를 지원하며 일대다 WebRTC 브로드캐스트 사용 사례를 쉽게 관리하고 확장할 수 있습니다.
WebRTC를 이용한 서비스 개발 문의는 아래를 정보를 이용하시기 바랍니다