현재 WebRTC로 다자간 화상통화를 할 수있는 시스템을 개발중입니다.

WebRTC?

WebRTC기술은 브라우저에서 중간 서버 없이 오디오, 비디오같은 미디어 데이터를 주고받을 수 있을뿐만 아니라 텍스트, 파일과같은 데이터도 실시간으로 주고받을 수 있는 Web Real-Time Communication 기술입니다.
즉 어떠한 플러그인, 소프트웨어가 없어도 실시간으로 통신이 가능하다는 것입니다!
또한 HTTPS가 강제되어있기때문에 중간자 공격에 대한 보안이 보장되어있고 중간에 거치는 서버가 없기때문에 속도또한 빠릅니다.

WebRTC를 선택하여 개발하게된 이유

P2P 방식으로 피어끼리 연결하여 통신할 수 있다는 점에서 맘에 들었습니다.
중간에 미디어 서버를 둘필요가 없이 중간에 다리만 이어주게 되면 종단간 스트리밍이 가능했기 때문입니다.

그렇다면 Peer간 연결은 어떻게 이뤄지는지?

P2P Connection 이전에 알아두어야할 개념이 몇가지 있습니다.
NAT Traversal, STUN/TURN 서버, Signaling 입니다.
또한 제 프로젝트에서도 해당 개념들이 이용되었으며 이를 먼저 알려드리려고 합니다.

NAT Traversal (Network Address Translation Traversal)

일반적으로 당신의 컴퓨터에는 공인 IP가 할당되어있지 않습니다

공인 IP는 ISP에서 제공하는 인터넷 사용자의 Local network를 식별하기 위해 제공되는 인터넷 프로토콜 주소이며 외부에 공개되어있는 주소입니다.
하지만 공인 IP의 경우 할당될 수 있는 갯수가 정해져있습니다.

즉 공인 IP는 한정되어있기 때문에 여러분들은 사설 IP로 NAT를 거쳐 공인 IP로 변환하여 상호작용할 수 있던것입니다.

그래서 만약 여러분들이 어떠한 컴퓨터의 공인 IP를 안다고하여서 해당 컴퓨터와 통신할 수 있는것은 아닙니다. 해당 컴퓨터의 사설 IP까지 알아야 통신할 수 있는것이죠.

그렇게 된다면 각 피어들끼리 연결하기 위해선 현재 라우터에 연결된 IP 주소와 Port를 알아야합니다.

하지만 어떤 라우터들은 일부 주소, 포트가 제한되어있을 수 있습니다.
이럴 경우 TURN 서버가 필요합니다.

STUN, TURN

STUN은 여러분들의 공인 IP주소와 포트를 알아내거나, 피어간 직접 연결을 제한하는 프로토콜입니다.

WebRTC로 연결을 시작하게되면 여러분들은 STUN서버를 통해 자신의 주소와 포트를 알아내야합니다. 그렇게된다면 여러분들은 P2P 연결을 할 수있는 주소를 알아내게 된것입니다.

하지만 몇몇의 라우터들은 Symmetric NAT 라고 불리는 제한 NAT를 사용하고 있기때문에 STUN 서버를 이용한다고 하여 무조건 자신의 주소를 얻을 수 있는것이 아닙니다.
이럴경우 TURN 서버를 차선책으로 이용해야합니다.
하지만 TURN 서버의 경우 데이터를 전송하기 위해선 TURN 서버를 거쳐야하기 때문에 명백히 오버헤드가 발생하게됩니다.
TURN 서버를 거쳐야 하는 경우는 어쩔 수 없는 경우에만 이용해야만합니다.

ICE, Candidate

여러분들은 위에서 STUN, TURN 서버를 이용하여 자신에게 연결할 수 있는 후보군을 얻었습니다.

• 자신의 공인 IP/port
• 자신의 사설 IP/port
• 자신의 TURN서버 주소
  이를 Candidate라 부릅니다.

하지만 모든 과정은 ICE(Interactive Connectivity Establishment) 라는 프레임워크 위에서 돌게됩니다.
즉 ICE가 STUN, TURN서버를 이용하여 연결할 수 있는 Candidates를 모두 가지고 있다는 소리입니다.

그럼 이제 마지막으로 서로 주고받을 미디어관련 정보를 주고받아야겠네요.

SDP (Session Description Protocol)

SDP는 WebRTC에서 해상도나 형식, 코덱, 암호화같은 멀티미디어 연결을 설명하기위한 표준 프로토콜입니다.

즉 지금 만들고있는 다자간 화상 통화의 경우 비디오 코덱과 해상도같은 정보를 보낼 수 있고 오디오도 포함시킬건지의 여부같은 데이터를 보낼 수 있겠네요.

SDP는 Offer/Answer 모델로 동작합니다.
즉 Peer A가 Peer B에게 Offer를 만들어서 보내면
Peer B는 Peer A에게 Answer를 만들어서 응답합니다.

이와같이 요청에 승낙을 했다면 ICE의 후보군중 최적의 경로를 찾아 연결을 수립하게됩니다.

서로 연결에 성공하였다면 기본적으로 필요한 메타데이터, IP/Port, 미디어 정보가 모두 갖춰진 상태입니다.

그후 로컬 스트림에 대해 엔드포인트가 만들어지고 양방향 통신을 하게됩니다.

Signaling Server

위에서 행해졌던 모든 프로세스들이 모두 Signaling이라고 부를 수 있습니다.
중간자 서버가 없다고했지만 이는 peer간 통신할 때 이야기고
예를들어 offer description이 만들어졌으면 연결하려는 대상도 나의 offer description이 만들어졌다고 알아야만합니다.
알지 못하면 나의 description을 알아볼수가 없으니까요.
결국 p2p로 통신하게 되지만 이를 연결하기까지의 과정은 양측간 signal이 필요합니다.
이게 Signaling Server의 개념이고 현재 저의 프로젝트는 Netty, WebSocket으로 구성되어있습니다.

WebRTC 단점

크로스 브라우징 문제

하지만 이 방식에도 단점이 있습니다. 지원하는 브라우저의 한계가 있는 크로스 브라우징 문제입니다. 각 브라우저 회사에서 이에 맞게 개발을 해야 하는 문제점이 있었지만 지금은 대부분의 브라우저들이 이를 지원합니다. 사파리와 그리고 인지도가 낮은 브라우저를 쓰는 사용자나 예전 버전 브라우저를 쓰시는 분은 사용이 불가능합니다.

7. STUN/TURN 서버 필요

방화벽(firewall)문제가 있습니다. 같은 네트워크 상에서는 문제가 없지만 다른 네트워크상에서는 STUN/TURN 서버를 설치한 후 사용해야 합니다

출처: https://gocoder.tistory.com/1928 [고코더 IT Express]

마치며

반응이 좋다면 현재 개발중인 프로젝트의 소스코드를 공개하고,
Zoom과같은 다자간 화상통화 웹사이트를 만드는 강의를 올려볼까합니다.