개요

온라인 상에서 통화나 영상통화는 어떻게 가능한걸까?

처음엔 단순하게 생각했다. 누군가가 말을 하면, 그 말이 ‘보내는 채널’을 통해 나에게 전달되고, 나는 그걸 ‘받는 채널’을 통해 듣는 식. 그러니까 두 사람 사이에 음성과 영상이 오가는 두 개의 통신 채널이 있다고 보는 거다.
이게 맞다면, 사람과 사람이 마치 같은 공간에 있는 것처럼 실시간으로 소통하는 그 모든 건 결국 ‘정보를 주고받는 길(채널)’을 얼마나 잘 만드는가에 달려있다.
그런데 이 단순한 상식 뒤에는, 수많은 복잡한 기술들이 얽혀 있다. 그리고 그 중심에 있는 것이 바로 WebRTC다.

옛날에 사용하던 실시간 통화는 브라우저만으로는 불가능했고 플러그인을 깔아야했다. 그리고 통신은 중앙 서버를 통해 중계되는 식.

서버 비용도 많이들고 지연도 컸다. 또한 그 당시 Adobe Flash 플러그인을 사용했는데 이게 해킹과 악성코드의 온상이었다.
여러 문제가 있었던 것이다.
그러다 Skype가 등장했다. Skype는 그 당시로는 획기적인 브라우저나 플러그인 없이 직접 연결로 통화할 수 있도록 했다.
사용자의 컴퓨터를 연결하는 슈퍼노드 네트워크를 구성했고 서버 없이도 통화를 가능하게 했다. 그리고 자체 암호화, 자체 프로토콜을 사용하여 보안과 통화 품질을 높였다.

그러나 이 모든 기술은 비공개였고 자체 암호화 방식과 자체 프로토콜을 사용했기 때문에 이 기술을 사용하여 다른 서비스를 구축할 수 없었다.

그래서 나온것이 바로 Web Real-Time Communication, 줄여서 WebRTC다.

구글이 중심이 되어 개발한 기술로 브라우저끼리 직접 응섬, 영상, 데이터를 주고받을 수 있게 만들었다.
플러그인이나 프로그램도 필요가 없었다.
대표적으로 다음과 같은 기술들을 제공한다.

  • getUserMedia: 카메라,마이크 사용
  • RTCPeerConnection: 브라우저끼리 연결
  • STUN/TURN: NAT환경에서도 통신 가능
  • DataChannel: 텍스트, 파일 등 실시간 교환

우리가 지금 사용하는 Zoom, Google Meet, Discord의 기반기술이다.

기존 방식과의 차이점

기존 방식은 비유하자면 택배 회사다.

우리가 택배를 보내면 중앙 허브로 가서 다시 똑같은 과정을 거쳐서 수신자의 집으로 배송된다.

그러나 RTC는 중간에 중앙 허브로 가지 않아도 드론을 날려 실시간으로 내가 보내고싶은 물건을 보내는 것이다.

드론이 이륙하는 것은 브라우저가 상대방 컴퓨터와 연결을 맺는 과정이라고 이해할 수 있다.

이제 드론이 어느 목적지로 가야하는지 알아야하는데
보통은 GPS를 통해 목적지를 확인할 것이다.
여기에 해당하는 것이 STUN 서버다. 상대방의 공인 IP를 확인한다.
그러나 대부분의 경우에 공인 IP가 고정되어있지 않다.
일반적으로 ip를 할당해주는 DHCP를 사용하기 때문이다. 일반적으로 라우터가 공인 ip와 포트를 확인하여 내부 사설 ip들을 매핑시켜준다.

(작성중)