실시간 통신의 역사
WebRTC?
다만, WebRTC 는 websocket 에서 부족했던 미디어 스트림에 대한 교환을 브라우저 간의 직접 연결을 통해 효율적으로 수행하기 위해 발전된 기술인만큼 요구되는 환경이 존재합니다.
이미지에서 알 수 있듯이 기본적으로 WebRTC 는 Signaling Server을 통해 연결이 이루어집니다. 위에서 언급했던 handshake가 이 서버를 통해 이루어진다고 생각하면 됩니다.
해당 서버를 통해 피어간의 연결을 설정하고, 데이터 전송을 관리할 수 있습니다.
다만, WebRTC 에는 이에 대한 표준이 따리 존재하지 않아 개발자가 직접 구현을 해야하는 번거로움이 있으며 이때 기본적으로 양방향 통신을 지원하는 프로토콜인 websocket 을 많이들 사용하는 걸로 알고 있습니다.
같은 네트워크 상이라면 문제가 없지만, 다른 네트워크에 존재하는 대상과 연결을 하려면 어떻게 해야 할까요? 그걸 위해 우리는 서로의 공용 IP 를 알고 있어야 합니다. 이 역할을 수행해주는 것이 STUN 서버입니다. NAT 환경에 있지 않은 사용자와의 소통을 위해 필요한 것이죠. 이후 포스팅에서 확인하시겠지만, 단지 공용 IP를 확인하는 작업만 진행하다 보니 서버의 부담이 거의 없고 그렇다 보니 오픈소스가 굉장히 많이 있습니다.
그런데 NAT 을 통해서도 통신을 할 수 없을 경우라면 어떻게 해야 할까요? 이를 위해 존재하는 것이 TURN 서버입니다. 서버에서 직접 데이터를 전달하는 것이죠. 다만, 이때부터 피어 간의 직접 연결이라고 볼 수 없고, 서버를 통해 전달하기 때문에 서버의 부하가 생기기 시작합니다. 가장 최후의 수단이라고 생각하셔야 합니다.
이제 연결이 완료되어 브라우저 간에 직접 교환을 진행하고 있게 되었습니다. 그런데 여기서 많은 사용자가 연결이 되면 어떻게 될까요? 사용자에 부담은 점점 가중될 것이고, 동일한 영상을 여러 사용자에게 전달하기 위해 굉장히 많은 중복 인코딩 과정이 발생할 것입니다.
이를 해결할 수 있는 방법의 예를 이 사진을 통해 알 수 있습니다. 일반적으로 WebRTC 는 피어 간의 연결을 통해 직접 데이터를 교환할 수 있게 도와주는 프로토콜입니다. 그런데 위에서 언급했던 것처럼, 연결되어 있는 사용자가 많아질수록 개인의 데이터를 전달하는데 동일한 처리를 나와 연결된 피어의 수만큼 반복해야 하는 문제점이 발생합니다. 이렇게 되면 당연히 해당 클라이언트에는 이 과정을 처리하는데 많은 자원을 사용할 것입니다.
그래서 이걸 대신 해줄 수 있는 중앙 처리 서버를 만들게 됩니다. 이게 익히 말하는 '미디어 서버'입니다. 다만, 이 미디어 서버와 어떤 식으로 연결되어 있느냐에 따라서 마찬가지로 소모되는 자원와 부하 정도가 다릅니다.
미디어 서버에 내 데이터를 올리는 과정을 Upstream, 미디어 서버에서 데이터를 내려주는 과정을 Downstream 이라고 이야기하는데 얼마나 많은 Downstream이 일어나냐에 따라 마찬가지로 피어에 발생하는 부하가 달라집니다. 그래서, 사진에서 볼 수 있듯이 피어의 수만큼 Downstream 이 발생하는 SFU 방식이, 미디어 서버에서 인/디코딩을 모두 처리해 하나로 통합해 내려주는 MCU 방식보다 피어의 부담이 큽니다.
이후 작성할 포스팅에서 구현한 방식은 Mesh 방식입니다. 의도치 않게 시그널링 서버를 Spring boot 로 사용하다 보니, 예제가 많이 없었고 WebRTC 에만 시간을 쏟을 수 없는 환경이라 어쩔 수 없이 구현한 점은 아쉽게 생각하지만, 데이터 채널은 이미 사용되고 있는 플랫폼이 있어 이를 활용하면 충분히 업그레이드 할 수 있을거라 생각해 이론적인 부분을 학습하는 걸 목표로 작성했습니다.
