search

tastekim / WeAllLie-BE

👀We Are Lie는 보드게임 '스파이 폴' 을 모티브로한 화상채팅으로 진행하는 온라인 보드게임 플랫폼 입니다 !(~2022.12.22)
3 stars 4 forks source link

[Info]webRTC 다대다 연결 방안 #92

Closed tastekim closed 1 year ago

tastekim commented 1 year ago

작업 내용 리스트

각 항목별 내용

👇 comment 참고

필요 환경 설정

OS: Mac Ventura 13.0.1
Node:  v16.1.0 (@tastekim )
npm : v8.19.2 (@tastekim )
tastekim commented 1 year ago

webRTC

webRTC 공식홈페이지 WebRTC는 서버를 최대한 거치지 않고 P2P(Peer-to-Peer Network)로 브라우저나 단말 간에 데이터를 주고받는 기술의 웹 표준입니다.

또한 WebRTC는 표준임과 동시에 표준을 구현한 오픈소스 프로젝트의 이름이기도 합니다. 사실 프로젝트가 먼저 있었고 표준화는 나중에 되었는데, 통신사와 통신솔루션 기업이 독점하고 있던 핵심 통신 기술을 구글이 주도해서 오픈소스화 및 표준화를 진행했습니다. (갓구글!)

webRTC 사용 이유

웹에서 실시간 미디어 스트림을 송수신할 수 있는 유일한 표준이고 또 유일한 P2P 표준이기도 합니다.

WebRTC 등장 이전에는 고가의 라이선스 구매 비용을 들여서 통화 기능, 화상회의 기능 등을 개발해야 했습니다. 하지만 2010년, IT 기술 중에서도 유독 라이선스 사용에 많은 비용이 드는 기술이었던 VoIP(Voice over Internet Protocol) 시장에 기존에는 상상하기 어려웠던 뉴스가 등장했습니다. 구글이 WebRTC의 근간이 되는 여러 독점 기술 기업들(On2, GIPS)을 인수해서 WebRTC 기술을 오픈소스로 풀어버린 겁니다. 이 기술들은 그전까지는 그야말로 세계 탑 수준의 미디어 엔진 및 코덱이었는데 이것을 오픈 한 뒤, 급기야 크롬 브라우저에 탑재시키고 표준화 단체까지 만듭니다.

webRTC의 flow

1:1의 화상채팅을 구현하는 것은 노마드코더 강의에서만 봐도 생각보다 간단했었습니다. 하지만 저희 프로젝트 특성 상 N:N 의 희의형 서비스의 특징을 띄기 때문에 기존보다 더 복잡한 flow를 가지게됩니다. 스크린샷 2022-11-18 오후 5 57 25

N:N 회의형 서비스로 구현할 수 있는 방안

  1. CPaaS 이용 클럽하우스를 비롯한 많은 성공 서비스는 WebRTC 기술과 인프라를 전문적으로 제공하는 CPaaS(Communication Platform as a Service)를 활용하고 있습니다. 매우 현명한 방법이라고 생각합니다. WebRTC 응용 서비스에서 성공을 결정하는 핵심은 WebRTC가 아니라 콘텐츠 자체이기 때문입니다. 핵심에 집중하기 위하여 WebRTC 같은 매우 전문화된 기술은 클라우드 기업에 맡기는 것 입니다. 해외의 경우 Twilio나 Agora.io가 유명하고 국내의 경우 Kakao i Connect Live가 유일한 CPaaS입니다. 이들 CPaaS를 이용하면 WebRTC 응용 서비스 개발에서 WebRTC와 관련된 거의 모든 부분에서 도움을 받을 수 있습니다. 웹 뿐만 아니라 모바일 플랫폼 지원과 대용량 트랜잭션 제어 그리고 미디어 서버 및 TURN서버 등을 지원받게 됩니다.

  2. webRTC 서버 직접 구현 WebRTC 덕분에 이전보다 라이브 스트리밍 혹은 통화 서비스를 개발하기가 한결 쉬워지고 저렴해진 것은 사실입니다. webRTC 서버를 구축하기 위해 필요한 여러 서버들(signaling, media, stun, turn 등)이 있는데 각 서버들을 쉽게 구현할 수 있게 도와주는 오픈소스 라이브러리도 많이 존재합니다. peerJS, openvidu, simple-peer 등 여러가지를 조합해서 필요에 맞게 서버를 구현하는 방법들도 존재합니다.

ghost commented 1 year ago

프로젝트를 완성시키기 위해서는 1번(CPasS) 방식이 안전할 것 같은데... 또 어제 멘토님이 말씀하신 것처럼 배포나 창업보단 구현이 중요하다는 관점에서는 2번으로 가야하나 싶기도 하고... 근데 그러자니 stun, turn은 만들어진 서버를 사용하면 된다고 하는데 이걸 셋팅하고 적용하는 것도 일일 것 같고.. signaling, media는 직접 구현부터 해야하는데 하나도 아니고 둘 다 구현하고 테스트하고 각 서버를 또 통합해서 돌아가게하려면 ㅋㅋ;;;; 일이 너무 커지는 것 같기도 하고... 어렵네요..ㅠㅠ

tastekim commented 1 year ago

🔭webRTC architecture

1. mesh

signaling 서버만을 필요로 하고 signaling 서버로 서로의 offer와 answer을 주고받은 뒤 peer 끼리 미디어 정보를 주고받는다. 인원이 늘을수록 클라이언트에겐 큰 부하가 걸린다. 반면 서버에서는 매우 여유롭다. p2p를 기본으로 하는 방식이라 현재 프로젝트에는 부적합하다.

2. MCU(Multi-point Control unit)

MCU, SFU 에서는 stun / turn 서버가 필요해지고 media 서버도 필요하다. 방식은 서버가 인코딩/디코딩을 전부 맡아서 하고 1개의 upstream/downstream 을 갖는다. 활성화가 되어있는 client를 제외한 나머지의 데이터를 압축해서 퀄리티가 떨어질 수 있다. 1:N에 적합하다. 또한 클라이언트와 서버 중에 서버의 부담이 가장 크다.

3. SFU(Selective Fowarding unit)

필요로 하는 서버의 구조는 MCU 와 같다. 다만 1개의 upstream과 N개의 downstream을 갖는다. 서버와 클라이언트가 부하를 나눠갖는 느낌 N:M 방식에 적합하고 현재 우리 프로젝트에 가장 부합하다고 생각되는 구조이다.

🔧SFU 구현 방법

1. signaling server

각 peer의 offer 와 answer 정보를 주고받아야하기 때문에 socket.io 를 이용해서 전달할 수 있다. 현재 프로젝트도 socket.io 로 로직이 구현되어 있어서 이 부분은 쉽게 해결 가능하다. 필요한 event message만 추가해주면 된다.

2. stun / turn server

NAT(Network Address Translation)은 통상적으로 네트워크에서 데이터를 주고받기 위해서는 public IP가 필요하기 때문에 Private IP를 public IP로 1대1 대응시켜 변환하는 장치이다. ICE(Interactive Connectibity Establishment)는 두 IP 가 서로 통신할 수 있는 최적의 경로를 찾아주는 프레임워크다. 그리고 그 최적의 경로는 STUN/ TURN서버를 사용하여 찾을 수 있다. ICE는 혼자 작동하지 않고 STUN / TURN 서버를 사용해야한다.

STUN 서버는 해당 peer의 public IP 주소를 보내는 역할을 한다. 두 엔드 포인트간의 연결을 확인하고 NAT 바인딩을 유지하기 위한 유지 프로토콜로도 쓰인다. 하지만 두 단말이 같은 NAT 환경에 있거나 NAT의 보안정책이 엄격하거나 등의 이유로 STUN 서버가 모든걸 해결해 줄수는 없다.

TURN 서버는 STUN의 확장으로 NAT 환경에서 릴레이하여 통신을 하게된다. 위에서 STUN 서버의 제한되는 상황에서 TURN 서버가 사용된다. 각 peer 들이 직접 통신하는 것이 아니라 릴레이 역할을 하는 TURN 서버를 경유하는 것이다. TURN은 이러한 릴레이로부터 IP 주소와 PORT를 클라이언트가 취득할 수 있는 릴레이 주소를 할당한다. 하지만 클라이언트의 연결을 거의 보장하지만 리소스낭비가 심하다. 그렇기 때문에 ICE Candidate 과정에서 최적의 경로를 먼저 찾은 후에 최후의 수단으로 사용되야 한다.

ICE Candidate Gathering 은 로컬, 서버, 릴레이 등 통신 가능한 모든 주소를 가져온다. 이들 중 가장 최적의 경로로 연결시켜준다.