WebRTC와 미디어서버

오늘은 WebRTC와 미디어서버에 대해서 알아보도록 하겠습니다. 회사에서 미디어서버를 도입하여 공부하는김에 포스팅까지 해보려고합니다. 

 

우선 WebRTC에 대해서 설명하고 넘어가야겠죠?

 

WebRTC

WebRTC를 설명하기 전에 TCP와 UDP에 차이에 대해서 짚고 넘어가도록 하겠습니다. 

 

취준생 단골 질문이기도 한 TCP와 UDP에 차이는 조금만 깊이있게 공부하면 머리가 어지러워지는 상황에 봉착합니다. 

 

제가 TCP의 흐름제어와 혼잡제어에 대해서 올린 포스팅도 있으니 한번 참고해주세요!

 

https://coding-review.tistory.com/466

네트워크 흐름제어와 혼잡제어 (Flow Control, Congestion Control)

 

간단하게 설명해서 TCP는 흐름제어나 혼잡제어와 같은 자체적인 기능덕분에 패킷이 중간에 유실되는 것을 막아주고 이는 높은 신뢰성으로 이어집니다. 

 

반면 UDP는 패킷이 유실되는 것은 둘째치고 데이터 송수신 여부조차도 확인하지 않기 때문에 신뢰성이 낮다는 단점이 있지만 1대1 1대다 다대다 통신이 가능하고 속도가 빠르다는 장점이 있습니다. 

 

즉, 정리하자면 TCP는 파일 전송과 같이 높은 신뢰성이 필요한 서비스에서 주로 사용되고 UDP는 실시간성이 더 중요한 스트리밍같은 서비스에 주로 사용됩니다. 

 

네 아마 짐작하셨겠지만 WebRTC는 UDP입니다. 저도 찾아보면서 처음 알았는데 웹소켓은 TCP라고 하네요. 

 

우선 화상통화와 같은 서비스를 구축하는데 있어서 미디어서버를 두지 않는다면 어떻게 구현해야할까요? 

 

 

만약 한명당 1mbps의 화상통화 영상을 한명의 모니터에 띄워주기 위해서는 각각의 1mbps의 통신을 한명에게 모두 몰아주어야합니다. 

 

 

UDP로 실시간 통화를 진행한다고 가정했을 때 이 영상정보를 인코딩하기도 해야하고 보안을위해 암호화작업도 진행해야 한다면 1mbps의 데이터가 더 거대해질 수 있습니다. 

 

뿐만아니라 만약 서비스를 배포하는데 100명, 1000명이 동시에 화상채팅을 해야한다면 문제가 심각해질 수도 있습니다. 1mbps보다 조금 통신을 주고 받으면서 통화품질을 조금 저하시킨다고 하더라도 이는 해결해야할 문제입니다. 

 

 

미디어서버

이런 상황에서 가운데서 브라우저끼리 서로 통신할 수 있도록 도와주는 것이 바로 미디어서버입니다. 

 

 

미디어 서버를 가운데서 웹브라우저가 요청을 대신 처리해주는 것이라고 쉽게 생각하시면 됩니다. 

 

미디어서버는 SFU, MCU, 하이브리드 이렇게 세가지가 있습니다. 

 

SFU

 

WebRTC 미디어 서버에서 가장 흔하고 대중적인 것이 바로 SFU입니다. SFU는 라우팅을 통해 미디어가 동작하는 부분 그자체를 가능하면 적게 유지합니다. 

 

SFU는 부하를 다른 대안들보다 유연하게 처리하고 네트워크 대역폭 관리와 라우팅로직을 디바이스 (유저) 들에 최적화하여 관리한다는 특징이 있습니다. 

 

MCU

 

 

MCU방식은 가장 오래된 미디어 서버 솔루션이기도합니다. 

 

MCU방식은 네트워크가 제한적이었던 WebRTC보다 몇 년 전에 도입되었습니다. 전화 시스템에는 MCU 개념을 기반으로 구축한 브릿지가 아직도 존재하고 있기도 합니다. 

 

화상 회의 시스템에서 비디오 압축을 위해 특수 하드웨어가 필요했기 때문에 미디어 서버를 사용해야했고, 나중에는 클라이언트 디바이스에서 너무 많은 CPU를 사용하기 때문에 요즘은 잘 사용하지 않는 추세라고합니다. 

 

 

하이브리드 미디어서버는 SFU와 MCU를 합쳐놓은 미디어서버입니다. 때문에 라우팅도 가능하고 프로세싱도 가능하다는 특징이 있습니다. 

 

하이브리드 미디어서버는 다른 유형의 여러 미디어 서버로 배포되어 각각 서비스의 다른 부분을 담당합니다. 이렇게 분할하면 각 미디어 서버 유형에 필요한 워크로드에 따라 개발, 유지 관리 및 확장하기가 더 수월해집니다. 

 

 

STUN서버 TRUN서버

WebRTC를 공부하다보니 STUN서버와 TRUN서버라는 것이 보입니다. 이 서버들은 NAT과 방화벽을 뚫고 P2P방식을 진행하려면 많은 문제가 있었습니다. 

 

우선 NAT이란 private IP와 public IP를 스위치 켜듯이 전환하면서 private으로 묶여있는 네트워크를 public한 인터넷과 연결하기위해 사용됩니다. 

 

NAT과 방화벽이 P2P방식에 많은 제한사항이 있다는건 왜그럴까요?

 

NAT이랑 방화벽은 NAT과 방화벽이 각각 허용하는 아웃바운드 연결 (안에서 밖으로 나가는 네트워크)과 제한적인 인바운드 연결 (밖에서 안으로 들어오는 네트워크) 때문에 peer 사이에 직접적인 연결을 제한합니다. 

 

NAT과 방화벽은 인바운드 아웃바운드를 통제하는 역할을 수행하기 때문에 맞는 말입니다. 

 

그래서 STUN서버와 TRUn서버는 peer간에 연결을 수립하는 것을 도와주는 서버입니다. 

 

STUN서버

STUN은 NAT뒤에서 장치의 퍼블릭 IP주소와 포트들을 발견하기위해 사용하는 프로토콜입니다. WebRTC 애플리케이션이 실행할 때 WebRTC서버는 STUN서버를 퍼블릭 IP주소와 포트를 찾기위해 사용할 수 있습니다. 

 

peer간에 직접적인 연결 (P2P연결) 을 수립하기 위해 퍼블릭 IP와 포트를 공유해야하는데 그 때 STUN을 이용하는 것입니다. 

 

NAT은 퍼블릭 인터넷에 접근 가능한 STUN서버로 요청을 보냅니다. STUN서버는 바깥에서 볼 수 있는 디바이스 (peer)의 퍼블릭 IP주소와 포트 넘버를 응답값으로 보내줍니다. 이 정보들은 ICE 프로세서가 P2P연결을 수립하는 것을 시도하기 위해 사용됩니다. 

 

하지만 STUN서버는 모든 상황에서 통하지는 않습니다. 특히 private IP, 포트와 퍼블릭 IP, 포트를 외부 목적지에서 매핑하고 교환하는 복잡한 NAT 환경에서는 통하지않습니다. 

 

TRUN서버

TRUN은 STUN이 직접적인 연결을 수립하는 것을 실패했을 때의 결점을 보완하기위해 설계되었습니다. TRUN서버는 peer간의 중간 중계자 역할을 하며, 자신을 통해 트래픽을 효과적으로 라우팅할 수 있습니다. 

 

만약 직접적인 연결이 NAT이나 방화벽의 제약조건이나 다른 이슈들에 의해 설립되지 않는다면 WebRTC는 TRUN서버를 peer간 데이터를 받기위해 사용할 수 있습니다. 

 

각각의 peer들은 TRUN서버를 통해 연결이 되고, TRUN서버는 이 연결 사이에 있는 트래픽 앞에 위치합니다. 

 

이를 그림으로 그려보면 다음과 같습니다. 

 

 

P2P연결을 수립할 때 그럼 TRUN서버와 STUN서버를 도입하면 모두 해결되느냐! 

 

그건 또 아닙니다. 만약 TRUN서버를 도입하여 복잡한 NAT에 의한 환경이나 방화벽에 의한 제약조건을 우회할 수 있다고 하지만 TRUN서버를 사용하면 추가적인 지연시간을 야기하고 TRUN서버로부터 더 많은 대역폭을 요구합니다. 

 

이 상황은 직접적인 P2P 연결 방식에 비해 덜 선호되는 상황이기는 합니다. 하지만 P2P연결이 NAT과 방화벽에 의해 연결조차 되지 않는 것 보다는 더 낫기 때문에 TRUN서버는 모든 시나리오에서 연결을 보장한다는 특징이 있습니다. 

 

 

 

마치며

회사에서 WebRTC기반의 미디어서버인 kurento를 기반으로한 오픈소스 openvidu를 도입하기 때문에 공부차 포스팅을 진행해보았습니다. 

 

기본적으로 HTTP통신에서 돌아가는 것들만 봐서 그런지 어려운 내용들이 많아서 이해하는데 좀 어려웠습니다. 하지만 오늘도 하나 더 알아간다는 사실에 기쁘기도 합니다. 

 

이번 포스팅은 여기서 마무리짓도록 하겠습니다. 오늘도 즐거운 하루 되세요!!

 

 

 

 

출처

https://bloggeek.me/webrtc-media-server/#h-how-is-a-webrtc-media-server-different-from-turn-servers

What exactly is a WebRTC media server?

 

https://gh402.tistory.com/43

[WebRTC] 쿠렌토(Kurento)는 무엇인가?