🪵 2. WebRTC 구현 방식

Mesh (P2P)

• 모든 사용자가 서로 직접 연결되는 구조
• 미디어 서버를 거치지 않고 다른 사용자에게 직접 스트림을 보낸다.
• 처음 WebRTC가 peer간의 정보를 중계할 때만 서버에 부하가 발생한다.
  • 정보 교환을 위한 서버를 **시그널링 서버**라고 하며, 이는 WebRTC의 초기 연결 설정을 돕는다.
• Mesh 방식에서는 선택적으로 스트림을 전달하지 않고, 모든 참가자가 서로의 스트림을 모두 직접 주고받는다.
  • 즉, 각 피어가 연결된 모든 다른 피어에게 자신의 미디어 스트림(오디오, 비디오, 또는 데이터)을 다 보내야 한다.
• 장점
  • 미디어 서버가 필요 없어서 비용이 적게 든다.
  • 지연 시간이 낮다.
• 단점
  • 참가자가 많아질수록 각 사용자가 모든 참가자와 스트림을 주고받아야 하므로 네트워크 부하가 증가한다.
  • 확장성에 한계가 있어 소규모 그룹에 적합하다.

MCU

• Multipoint Control Unit
• 서버는 각 클라이언트로부터 받은 스트림을 디코딩한 후, 이를 하나의 혼합된 스트림으로 합친다.
• 이후 재인코딩을 통해 단일 스트림으로 변환하여 각 클라이언트에게 전달한다.
• 장점
  • 대규모 그룹 통화에 적합하며, 대역폭 문제가 있는 경우 유용하다.
  • 클라이언트는 혼합된 단일 스트림만 받으면 되므로 처리 부담이 줄어든다.
  • 중앙에서 스트림 품질을 조정할 수 있어 전체 품질이 향상될 수 있다.
• 단점
  • 스트림을 디코딩, 혼합, 인코딩하는 작업 때문에 서버의 처리 비용이 크다.
  • 처리 오버헤드로 인해 지연 시간이 늘어난다.

SFU

• Selective Forwarding Units
• 서버가 각 참가자의 미디어 스트림을 받아서 필요한 참가자에게만 선택적으로 전달하는 방식
• SFU는 비디오를 디코딩한 뒤, 다시 인코딩하지 않고 단순히 데이터를 라우팅한다.
• 장점
  • 보다 많은 사용자(보통 수십 명까지)를 효율적으로 지원할 수 있다.
  • 각 사용자는 하나의 스트림만 서버로 보내고, 서버가 필요한 참가자에게만 전달하기 때문에 클라이언트 측의 대역폭 사용이 절감된다.
  • 특정 스트림(예: 발언자의 비디오)을 우선적으로 전달할 수 있다.
  • 확장이 가능하며 순서를 재구성할 수 있다.
• 단점
  • 중간에 전달 역할을 하는 중앙 서버가 필요하다.
  • Mesh보다 서버 복잡도가 높다.

결론

이렇게만 읽어봤을 때는 SFU가 우리 프로젝트에 가장 적합해보인다.

• 게임 특성 상 많은 참가자를 수용할 수 있어야 한다. (최소 5명 이상)
• 클라이언트 측에서 병합(CRDT)할 수 있어야 한다.
• 선택적으로 스트림을 보낼 수 있다.
  • mesh 방식에 비해 낮은 대역폭

참고

• WebRTC Architectures: Mesh, MCU, and SFU