서비스에서 1:1 화상통화가 필요한 기능이 있어서 WebRTC로 구현하려고 한다.
WebRTC가 뭔지, 왜 WebRTC인지는 이 글을 보면 좋다.
WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다. WebRTC를 구성하는 일련의 표준들은 플러그인이나 제 3자 소프트웨어 설치 없이 종단 간 데이터 공유와 화상 회의를 가능하게 합니다.
이를 위하여 WebRTC는 상호 연관된 API와 프로토콜로 구성되어 함께 작동합니다. 이 문서에서는 WebRTC의 기본을 이해하고, 설정하며, 데이터와 미디어 연결을 위해 사용할 수 있게 도와줄 것입니다.
mdn에서 정의된 WebRTC 이다.
웹에서의 P2P로 브라우저나 단말간에 실시간으로 미디어스트림은 주고받는 기술의 표준이다.
WebRTC는 프로젝트의 이름인데 통신사와 통신솔루션 기업이 독점하고 있던 핵심 통신 기술을 구글이 주도해서 오픈소스화 및 표준화를 진행한 프로젝트이다.
WebRTC 등장 이전에는 고가의 라이선스 구매 비용을 들여서 통화 기능, 화상회의 기능 등을 개발해야 했습니다. 하지만 2010년, IT 기술 중에서도 유독 라이선스 사용에 많은 비용이 드는 기술이었던 VoIP(Voice over Internet Protocol) 시장에 기존에는 상상하기 어려웠던 뉴스가 등장했습니다. 구글이 WebRTC의 근간이 되는 여러 독점 기술 기업들(On2, GIPS)을 인수해서 WebRTC 기술을 오픈소스로 풀어버린 겁니다. 이 기술들은 그전까지는 그야말로 세계 탑 수준의 미디어 엔진 및 코덱이었는데 이것을 오픈 한 뒤, 급기야 크롬 브라우저에 탑재시키고 표준화 단체까지 만듭니다. 그리고 이것을 2011년 말에 완료해버리는 놀라운 실행력을 보여줍니다. 기존 통신사와 거대 통신솔루션 기업들은 깜짝 놀라게 됩니다. 그리고 오늘날 WebRTC의 시대가 열렸습니다.
사실 오늘날의 WebRTC가 있기까지 구글의 기여는 이루 말할 수 없죠. 구글 덕분에 VoIP 서비스 이상의 다양한 혁신적인 서비스를 개발할 수 있는 세상이 열렸고 코로나19 바이러스로 인한 비대면 시대에 널리 쓰이는 기술 중 하나가 되었습니다. 구글이기에 가능했던 시도가 아니었을까 싶습니다.
2. WebRTC의 통신과정
WebRTC 통신과정
1. Signaling을 통해 통신할 peer간 정보를 교환한다. ex) 세션 제어 메세지, 네트워크 구성정보, 미디어 기능 등의 정보
2. WebRTC를 사용해 연결을 맺고, peer의 단말에서 미디어를 가져와 교환한다.
시그널링
WebRTC 는 P2P 연결을 통해 직접 통신하지만, 이를 중계해주는 과정이 필요하다. 이를 시그널링 이라 부른다. 그리고 이를 수행하는 서버를 시그널 서버라 칭한다. 시그널 서버는 채팅방과 같은 형태로 연결하고자 하는 Peer 들을 논리적으로 묶고 서로간에 SDP 와 Candidate 를 교환하여 준다.
시그널 서버는 개발하고자 하는 서비스의 성격에 맞게 SIP나 XMPP 등의 기존의 시그널링 프로토콜을 사용해도 되고 Ajax long polling이나 websocket 등의 적절한 쌍방향 통신 채널로 이를 구현하면 된다.
그렇지만 시그널링의 핵심은 비동기적으로 발생하는 Peer 들의 정보(SDP, Candidate)를 교환하는 일이다. 그러므로 전이중 통신을 지원하는 websocket 으로 이를 구현하는 것이 가장 적합하다.
시그널링의 역할
다음과 같은 세가지의 정보를 교환하게 한다.
- Session control messages : 통신의 초기화, 종료, 그리고 에러 메시지
- Network configuration : 외부에서 바라보는 IP와 포트 정보
- Candidate에 서로를 추가
- ICE 프레임워크를 사용하여 서로의 IP와 포트를 찾는 과정
- Media capabilities : 상호 두 단말의 브라우저에서 사용 가능한 코덱, 해상도
- offer 와 answer 로직으로 진행
- 형식은 SDP (Session Description Protocol)
3. 서버의 역할 (용어 총정리)
P2P로 클라이언트끼리 통신을 한다해도 서버가 필요한 이유는 다음과 같다.
- Signaling 사용자 탐색과 통신
- 방화벽과 NAT 트래버셜
- P2P 통신 중계서버
방화벽과 NAT 트래버셜
일반적인 컴퓨터에는 공인 IP가 할당되어 있지 않다. 그 원인으로는 방화벽(Firewall), 여러 대의 컴퓨터가 하나의 공인 IP를 공유하는 NAT, 유휴 상태의 IP를 일시적으로 임대받는 DHCP 때문이다. 이 때문에 단순히 공인 IP만을 알아낸다고 해서, 특정한 사용자를 가리킬 수는 없다. 따라서 공인 IP뿐만 아니라 해당 네트워크에 연결된 사설 IP 주소까지 알아내야 특정한 사용자를 지정할 수 있다.
일반적으로는 라우터가 NAT 역할을 한다. 외부에서 접근하는 "공인 IP와 포트 번호"를 확인하여 현재 네트워크 내의 사설 IP들을 적절히 매핑시켜준다. 따라서 어떤 브라우저 두 개가 서로 직접 통신을 하려면, 각자 현재 연결된 라우터의 "공인 IP 주소와 포트"를 먼저 알아내야 한다.
하지만 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어 있을 수도 있다. 이처럼 라우터를 통과해서 연결할 방법을 찾는 과정을 NAT 트래버셜(NAT traversal)이라고 한다.
STUN
NAT 트래버셜 작업은 STUN(Session Traversal Utilities for NAT) 서버에 의해 이루어진다. STUN 방식은 단말이 자신의 "공인 IP 주소와 포트"를 확인하는 과정에 대한 프로토콜이다. 클라이언트가 STUN 서버에 요청을 보내면 공인 IP주소 와 함께 통신에 필요한 정보들을 보내주는데, 클라이언트는 이를 이용해 다른 기기와 통신한다. 하지만 이러한 경우에도 통신이 되지 않는다면 TURN 서버로 넘기게 된다.
TURN
STUN 서버를 이용하더라도 항상 자신의 정보를 알아낼 수 있는 것은 아니다. 어떤 라우터들은 방화벽 정책을 달리 할 수도 있고, 이전에 연결된 적이 있는 네트워크만 연결할 수 있게 제한을 걸기도 한다(Symmetric NAT). 이 때문에 STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우, TURN(Traversal Using Relay NAT) 서버를 대안으로 이용하게 된다.
TURN(Traversal Using Relays around NAT)는 이러한 Symmetric NAT 제약조건을 우회하기 위해 만들어졌다. TURN 서버와 연결을 맺고, 이 서버에서 모든 교환 과정을 중계한다. 모든 기기는 TURN 서버로 패킷을 보내고, 서버가 이를 포워딩한다. 모든 작업을 한 서버에서 처리하는 만큼 오버헤드가 있다.
ICE와 Candidate
STUN, TURN 서버를 이용해서 획득했던 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소들을 후보(Candidate)라고 부른다. PeerConnection 객체를 생성하면 candidate 를 얻을 수 있다.
이렇게 후보들을 수집하면 일반적으로 3개의 주소를 얻게 된다.
- 자신의 사설 IP와 포트 넘버
- 자신의 공인 IP와 포트 넘버 (STUN, TURN 서버로부터 획득 가능)
- TURN 서버의 IP와 포트 넘버 (TURN 서버로부터 획득 가능)
한편, 이 모든 과정은 ICE(Interactive Connectivity Establishment)라는 프레임워크 위에서 이루어진다. ICE는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크이다. ICE 는 STUN 과 TURN 을 활용하여 여러 Candidate 를 검출하고 이들 중 하나를 선택하여 Peer 간 연결을 수행한다.
SDP
SDP(Session Description Protocol)는 WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜이다. 미디어에 대한 메타 데이터로 사용할 수 있는 코덱은 무엇들이 있으며, 어떤 프로토콜을 사용하고, 비트레이트는 얼마이며, 밴드위드스는 얼마이다 와 같은 데이터가 텍스트 형태로 명시되어 있다.
PeerConnection 객체를 생성하게 되면 PeerConnection 객체에서 offer SDP, answer sdp 를 얻을 있다. 이처럼 미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 발행 구독 모델(Pub/Sub)과 유사한 제안 응답 모델(Offer/Answer)을 갖고 있다.
시그널링
위에서 이야기한 모든 과정을 일컬어 시그널링(Signaling)이라고 부른다. 즉 RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정을 의미한다.
WebRTC의 세가지 구축 방식
2-1. Signaling 서버(P2P/Mesh)
특징
peer 간의 offer, answer라는 session 정보 signal만을 중계한다. 따라서 처음 WebRTC가 peer간의 정보를 중계할 때만 서버에 부하가 발생한다.
peer간의 연결이 완료된 후에는 서버에 별도의 부하가 없다.
1:1 연결에 적합하다.
장점
서버의 부하가 적기 때문에 서버 자원이 적게 든다.
peer간의 직접 연결로 데이터를 송수신하기 때문에 실시간성이 보장된다.
단점
1:N 혹은 N:M 연결에서 클라이언트의 과부하가 급격하게 증가한다.
2-2. SFU(Selective Forwarding Unit) 서버
특징
종단 간 미디어 트래픽을 중계하는 중앙 서버 방식이다.
클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결한다
1:1, 1:N, N:N 혹은 N:M 등 모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보내면 된다.(즉, Uplink가 1개다.)
하지만 1:N, N:N 혹은 N:M 형식이라면 상대방의 수만큼 데이터를 받는 peer를 유지해야한다.(Downlink는 P2P(Signaling서버)일 때와 동일하다.)
1:N 형식 또는 소규모 N:M 형식의 실시간 스트리밍에 적합하다.
장점
데이터가 서버를 거치고 Signaling 서버(P2P 방식)를 사용할 때 보다 느리긴하지만 비슷한 수준의 실시간성을 유지할 수 있다.
Signaling 서버를 사용하는 것보다 클라이언트가 받는 부하가 줄어든다.
단점
Signaling 서버보다 서버 비용이 증가한다.
대규모 N:M 구조에서는 여전히 클라이언트가 많은 부하를 감당한다.
2-3. MCU(Multi-point Control Unit) 서버
특징
다수의 송출 미디어를 중앙 서버에서 혼합(muxing) 또는 가공(transcoding)하여 수신측으로 전달하는 중앙 서버 방식이다.
예를 들어, 5인이 WebRTC 연결을 한다면 자신을 제외한 다른 4인의 video 데이터를 하나의 video 데이터로 편집하고, audio 데이터도 마찬가지로 편집하여 한 명에게 보낸다. 이 작업을 남은 4명에게도 동일하게 적용한다.
클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결한다.
모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보내면 된다.(즉, Uplink가 1개다.)
모든 연결 형식에서 클라이언트는 연결된 사용자의 수와 상관없이 서버에게서 하나의 peer로 데이터를 받으면 된다.(즉, Downlink가 1개다.)
중앙 서버의 높은 컴퓨팅 파워가 요구된다.
장점
클라이언트의 부하가 현저히 줄어든다.(항상 Uplink 1개, Downlink 1개로 총 2개)
N:M 구조에 사용 가능하다
단점
WebRTC의 최대 장점인 실시간성이 저해된다.
video, audio를 결합하는 과정에서 비용이 많이 든다.
왜 WebRTC인가
1. Latency가 미디어 스트리밍에 관련된 어떠한 기술보다 적다.
그렇기 때문에 실시간 화상통화에 굉장히 적합하다.
https://www.wowza.com/blog/streaming-protocols
위 사진은 와우자에서 가져왔는데, Latency는 영상, 음성이 상대방에게 도착할 때까지의 지연시간을 뜻한다.
WebRTC를 보면 1초 이내의 지연시간을 가지고 있다.
2. 별다른 소프트웨어가 필요하지 않다.
JavaScript API로 사용할 수 있으며 다른 기술들은 소프트웨어가 필요한 기술들이 많지만 WebRTC는 웹, 앱 모두 API로 구현이 가능하다.
3. 오픈소스이기때문에 무료이다.
4. 피어간의 실시간 통신의 표준이다.
이러한 이유들로 우리 서비스의 1:1 화상통화 기술을 WebRTC로 선정했다.
(연결방식은 Signaling Server를 둔 Mesh 사용할 예정)
다음 글은 실제로 서비스에 적용!
https://surprisecomputer.tistory.com/8
https://velog.io/@heejinkim0812/WebRTC%EB%9E%80
https://www.wowza.com/blog/streaming-protocols
'Server' 카테고리의 다른 글
| VScode - Password 계속 입력하라고 하는 오류 (0) | 2022.08.11 |
|---|---|
| S3 client SDK - Delete 403 access denied error (0) | 2022.08.10 |
| 웹서버, WAS 선정기준 (0) | 2022.08.09 |
| Docker - EFK 환경구축 과정 (0) | 2022.08.04 |
| 시스템 로그 수집 툴 - Fluented vs LogStash (0) | 2022.08.03 |
댓글