중간자 없이 브라우저간 통신을 할 수 있게 해주는 WebRTC기술과 이 기술을 제공하는 Agora사의 rtc, rtm API의 사용법에 대해서 알아보도록 하겠다.
WebRTC(web real-time communication)
웹을 위한 실시간 커뮤니케이션
영상 통화, 채팅, 환율, 현재 주식 거래가격 등 우리의 일상 속에서 실시간으로 정보가 오가는 경우는 흔하다.
특히 요즘같이 코로나 시대에는 다들 줌과 같은 화상 채팅 앱을 이용해 다른 사람과 영상통화를 해본 적이 있을 것이다. 아니면 좋아하는 유튜버의 실시간 방송을 보며 댓글을 달고 후원을 해본 적도 있을 것이다.
이러한 일을 가능하게 하는 기술이 바로 WebRTC 이다.
사실 WebRTC가 아니더라도 실시간 채팅이나 통화같은 기능은 구현될 수 있다. Websocket과 같은 기술이 바로 그것이다.
Websocket
Websocket 탄생 배경
우리가 하이퍼문서 전송을 위한 프로토콜로 사용하는 HTTP에는 한계가 있다. HTTP는 기본적으로 클라이언트와 서버간의 요청과 응답으로 데이더가 전송된다.
즉 클라이언트로부터의 요청이 없는한 서버에서 응답을 할일은 없다는 것이다. 그리고 요청이 와서 응답을 하면 그 연결은 끊기게 된다.
HTTP에서 실시간 문자전송을 만드려면 지속적으로 요청을 보내 응답을 받는 기능을 만들어야하는데
- 데이터가 오지도 않았는데 요청을 해야한다는 문제와
- 그때마다 요청에 대해 연결이 됐다 끊켰다를 반복하게 해야한다는
문제가 있다.
이러한 문제를 해결하기 위해 나온것이 웹 소켓이다.
Websocket 연결
Websocket은 사용자들이 Websocket 서버에 연결되고 한번 연결이 되면 계속해서 연결을 해 HTTP의 한계를 이겨내고자 했다.
요청과 응답으로 데이터를 전송하는 것이 아닌
연결을 open과 close로 open상태면 close가 되기 전에는 지속적으로 데이터를 통신하겠다는 것
이로서 HTTP가 가진 한계를 해결하고 많은 웹이나 앱에서 Websocket을 이용하여 채팅과 화상 통화같은 기능을 만든 것을 볼 수 있다.
Websocket 단점
위와같이 실제 실시간 데이터 전송기능을 만들 수 있음에도 단점은 존재한다.
서버를 거쳐서 데이터가 전송되기에 서버 메모리의 역량이 중요하다.
websocket을 사용하는 유저들은 websocket의 서버와 연결되어 있는 것이기 때문에 유저들의 영상, 음성, 문자 등의 데이터를 실시간인 것처럼 빠르게 이동시켜줘야한다.
몇십명의 연결은 빠르게 처리를 할 수 있다고 해도 만약 연결된 유저가 몇 천명이 넘어간다면?
서버의 성능이 좋지 않다면 유저는 끊기는 화면을 보거나 아예 볼 수 없을 수도 있을 것이다.
또한 엄청많은 데이터 트래픽으로 인하여 서버가 다운되면??
.
.
이러한 문제점을 없애기 위한 방법이 WebRTC가 있는 것이다.
WebRTC peer to peer connection
WebRTC는 이처럼 유저들끼리 직접 연결을 시켜서 서버를 거치지 않고 통신을 하게 함으로써 websocket의 문제를 해결하였다.
WebRTC 시그널링
간단하게 WebRTC 기술이 peer끼리 연결을 시켜주는지 과정을 알아보겠다.
-
우선 WebRTC연결을 위해서는 서버가 필요하다.
서버 없는 연결이 WebRTC라고 해놓고 서버연결?
그렇다, 각 유저들이 집에서 사용하는 ip는 방화벽이 있거나 또는 사설ip를 사용하는 경우가 대부분이다.
브라우저 간 통신을 위해서는 고정된 공개된 공인 IP를 사용해야하고 이 공인 IP를 찾기 위해서 서버에 연결을 해야하는 것이다.- 보통 STUN서버로 찾는데 방화벽이 있거나 STUN서버연결에 문제가 있을 시 TURN 서버로 연결을 한다.
-
통신을 원하는 상대에게 우선 SDP(Session Description Protocol, 내 미디어 환경에 대한 정보)를 보낸다.
-
상대방은 받은 SDP offer를 보고 자신의 SDP Answer를 보낸다.
-
교환이 완료되면 끝! 이지만 교환을 위해서는 각 peer들의 공인된 IP와 포트등의 정보가 필요하다.
-
앞서 언급한 바와 같이 개인 컴퓨터의 방화벽과 같은 보안사항들 때문에 그냥은 되지 않는다.
-
STUN서버를 통해 공인된 IP를 받고 연결가능한 네트워크 주소들의 후보가 생긴다. -> 이 후보들은 ICE라는 프레임워크를 통해 생성됨
-
이 ICE Candidate를 SDP와 같이 주고 받으며 가장 최적화된 통신 을 찾아 통신을 하게 된다.
WebRTC 단점
WebRTC도 물론 단점이 존재한다.
서버를 통해 데이터를 전송하지 않기 때문에 Websocket보다는 당연 빠르지만
가령 1000명의 유저가 동시 화상채팅을 한다면
내 컴퓨터는 999명의 유저가 보낸 영상, 음성 데이터를 받아야하고
999명의 유저에게 내 영상과 음성 데이터를 보내야한다.
즉 WebRTC 사용의 규모를 키우기에는 문제가 있다는 것
WebRTC 연결 구축 방식
앞서 언급한 데이터 송수신의 과부화로 인한 문제를 일정부분 해결하기 위해 WebRTC는 다음과 같은 연결 방식이 존재한다.
1. Mesh
앞에서 얘기한 Signaling을 할 때만 서버가 개입하는 연결방식
1 : 1 에 적합하다.
장점
- 서버 부하가 적다
- peer to peer라 실시간성이 보장된다.
단점
- N : N , N : M 연결에서 Client에게 부하가 심해진다.
- 주고 받는 link가 각 유저당 ( n - 1 ) * 2 개이기에 다수일수록 부하가 심해진다.
2. MCU( Multi - point Control Unit)
- 다수의 송출 미디어를 서버에서 혼합 가공해 전달한다.
- 서버와 client간 연결이다.
- 연결 link는 보내는거 받는거 각 1개다
- 중앙 서버가 좋아야한다.
장점
- Client 부하가 적다.
- N : M , 다수 연결에 적합하다.
단점
- 실시간성에 저해된다.
- video audio 결합 비용이 증가한다.
2. SFU( Selective Forwarding Unit)
- 종단간 미디어 트래픽을 중계하는 중앙서버 방식이다.
- 서버와 client간 연결이다.
- 보낼 때는 1개의 link 받을 때는 n개의 link를 가진다.
- 1 : N 또는 소규모 N : M 형식의 스트리밍에 적합하다.
장점
- P2P때 보다는 느리지만 비슷한 실시간성을 가진다.
- P2P때 보다 clinet의 부하가 적다.
단점
- P2P signaling보다 비용이 많이든다.
- 대규모 N : M 에서는 여전히 클라이언트 부하가 심하다.
이렇게 Websocket과 WebRTC 기술에 대해서 알아보았다. 마지막으로 관련 기술에 대해 알아볼 수 있는 영상 링크를 걸고 마무리 하겠다.
다음 글에서는 위 WebRTC 기술을 저자의 프로젝트에 쉽게 사용할 수 있도록 도와준 Agora의 SDK와 Agora의 rtc rtm 기술 사용법에 대해서 알아보겠다.
참고
노마드 코더 WebRTC? WebSockets? 5분 개념정리! - https://youtu.be/5EhsjtBE7I4
Traversy Media 웹 RTC 풀 코스 - https://youtu.be/QsH8FL0952k
