WebRTC 란?

WebRTC(Web Real-Time Communication)는 웹 애플리케이션과 사이트에서 플러그인 없이 직접 브라우저 간 실시간 커뮤니케이션(음성, 영상, 데이터 전송)을 가능하게 하는 기술입니다.

WebRTC로 구성된 프로그램들은 별도의 플러그인이나 소프트웨어 없이 P2P 화상회의 및 데이터 공유를 합니다.

WebRTC 선택 이유

webRTC를 선택한 이유는 다음과 같습니다.
저희 팀은 즉각적인 질문과 피드백을 위해서 통신 간 지연시간이 적어야 한다고 생각했습니다.
WebRTC의 경우 지연시간이 다른 프로토콜보다 지연시간이 짧아 원활한 실시간 소통이 가능하다고 판단하였습니다.
또한 추가적인 플러그인 설치 없이 사용할 수 있기 때문에 누구나 자유롭게 지식 공유할 수 있는 환경을 만들기에 적합했습니다.

그래서 짧은 지연시간과 별도의 플러그인 없이 사용 가능한 WebRTC를 선택하였습니다.

WebRTC의 3가지 통신 방식

WebRTC의 구현 방식은 그림과 같이 크게 3가지 방식이 존재합니다.

• Mesh는 클라이언트 끼리 1:1로 연결되는 방식입니다. (클라이언트 부하⬆️)
• MCU는 모든 클라이언트의 미디어 스트림을 서버에서 하나로 혼합 또는 가공하여 전달하는 방식입니다. (서버 부하⬆️)
• SFU는 클라이언트가 필요로하는 미디어 스트림을 서버에서 선택적으로 전달하는 방식입니다. (보완적)
  

동작 원리

Signaling

p2p 로 소통하기 위해서는 signaling이라는 연결 과정을 거쳐야 합니다. signaling은 무엇으로 어떻게 대화할지 합의하는 과정입니다. 이 합의 과정은 서버를 통해 이루어지는데 개발자가 구현해야 합니다.
signaling에는 SDP(Session Description Protocol) 이라는 무엇으로 어떻게 소통할지를 정하는 양식이 사용됩니다.

어떻게 소통하는가?

클라이언트 들은 각각 소통할 수 있는 네트워크 경로들의 정보를 보냅니다. 이를 ICE 후보군(이것들 중 하나를 사용할 수 있어 라는 뜻)이라고 부릅니다.
이 후보들은 3가지가 있습니다.

• Host Candidate - 같은 로컬 네트워크 환경에 있는 경우(같은집의 공유기를 공유)
• Server Reflexive Candidate - 라우터의 공인 ip와 기기가 사용하는 port를 조합하여 사용자를 식별합니다. 그런데 이 port 정보는 시간에 따라 변경될 수 있습니다.
  따라서 연결을 위해서는 이 정보를 알아내기 위해서 STUN 서버를 이용합니다. 즉, 내 주소를 알아내어 상대방에게 알려주기 위함입니다.
• Relay Candidate - 네트워크 환경이 복잡하거나, 방화벽 등에 의해 P2P 통신이 제한된 경우 TURN 서버를 이용합니다. TURN 서버를 중간에 두고 통신하게 됩니다. TURN 서버는 외부 서비스를 이용할 수도 있고, 성능이나 비용문제로 직접 구현하여 사용할 수도 있습니다.

위 3가지 후보들을 상대방에게 SDP 프로토콜을 이용하여 전달하고, 최선의 방법으로 통신하게 됩니다.

SRTP vs SCTP 중에서 특성과 용도에 맞게 사용합니다. 이 둘은 신뢰성 보다는 빠른 대용량 전송을 위해 UDP를 기반으로 동작합니다.

영상이나 오디오 등은 SRTP 가 가장 많이 사용된다고 합니다. SCTP 는 파일 전송에 주로 사용됩니다.

구현방식

WebRTC는 ICE, STUN, TURN, SDP로 작동된다.
이 서버들과 프로토콜로만 작동이 된다면 매우 간편하겠지만 현실은 그렇지 않다.
P2P 연결을 완성시키기 위해서는 개발자가 peer간의 offer와 answer를 통한 session 정보를 중계해주는 서버를 만들어줘야한다.
하지만 P2P 연결로 3인, 4인 그리고 그 이상의 인원의 데이터 송수신을 지원하게 되면 클라이언트 측면에서의 과부하가 심하게 오기 때문에 권장하지 않는다.
이러한 문제의 해결책으로 나온 것이 SFU와 MCU 방식의 미디어 서버를 두는 것이다.

• signaling 서버 (mesh 형)
• MCU
• SFU

Signaling 서버

위 그림에서 mesh 형식에 해당합니다. 사용자는 다른 사용자들과 1:1로 연결을 해야합니다.
따라서 참가자가 많아질수록 연결에대한 리소스가 커지며, cpu와 네트워크 대역폭에 부하가 발생합니다.
위의 예제로 보자면 upload 부하가 4, 다운로드 부하가 4, 5명 이므로 4+3+2+1 총 10개의 연결이 발생합니다. (서버는 아니지만 클라가 엄청난 부하)

MCU(Multi-point Control Unit) 서버

다수의 송출 미디어를 중앙서버에서 혼합 또는 가공하여 수신측으로 전달하는 방식입니다.
클라간의 연결이 없고 서버와 클라만 각각 통신하게 됩니다.

예를들어 5명의 참가자가 모두 서버와 연결하고 업로드와 다운로드를 진행하게 됩니다.
이때, 중앙서버에서 미디어를 혼합 또는 가공하고 각 클라에게 전달해야 하므로 중앙서버에 부하가 생깁니다.

SFU(Selective Forwarding Unit) 서버

종단 간 미디어 트래픽을 중계하는 중앙 서버 방식입니다.
클라는 자신의 미디어 스트림을 SFU서버로 보내고, 서버는 각 참가자에게 다른 사람들의 스트림을 중계합니다. 서버는 단순히 데이터를 중계하는 역할만 하기 때문에 CPU 부담이 적고 확장성이 뛰어납니다.

클라는 연결된 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보내면 된다.(즉, Uplink가 1개다.)

상대방의 수만큼 데이터를 받는 연결 유지해야 합니다. (Downlink는 P2P(Signaling서버)일 때와 동일하다.)

SFU 방식은 다수의 참가자가 참여하는 화상 채팅을 구현할 때 일반적으로 사용되는 방식입니다. SFU 방식을 적용하기 위해 OpenVidu, mediasoup, jitsi Meet, Twilio 등 SFU 방식을 지원하는 오픈 소스나 서비스를 사용할 수 있습니다.

SFU 방식의 작동 원리

SFU 방식의 작동 원리는 다음과 같습니다.

1. 미디어 스트림 업로드

   각 클라이언트는 자신의 비디오/오디오 스트림을 SFU 서버에 업로드합니다.

2. Selective Forwarding

   SFU 서버는 클라이언트에게 전달한 스트림을 선택적으로 포워딩합니다. 서버는 미디어 데이터를 재가공하지 않고 클라이언트로부터 받은 데이터를 그대로 전달하므로 CPU 부하가 적습니다.

3. 다운로드

   각 클라이언트는 다른 사용자들의 스트림을 SFU 서버로부터 다운로드합니다. 이렇게 하면 각 클라이언트는 SFU 서버와만 연결되며, 여러 명의 사용자와 직접 연결할 필요가 없습니다.

SFU 방식의 장단점

SFU 방식의 장단점은 다음과 같습니다.

장점

• 확장성
  각 클라이언트는 SFU 서버와 하나의 연결만 유지하므로, 여러 클라이언트를 연결할 수 있습니다. 서버 리소스가 허용하는 한 많은 사용자를 동시에 연결할 수 있습니다.
  
• 낮은 클라이언트 부담
  각 클라이언트는 SFU 서버와 하나의 연결만 하면 되므로 대역폭과 CPU 사용량이 줄어듭니다.
  
• 다양한 레이아웃
  서버가 각 사용자의 비디오 스트림을 별도로 처리하지 않으므로 클라이언트에서 원하는 형태로 레이아웃을 조정할 수 있습니다.
  
• 적은 딜레이
  SFU 서버는 클라이언트로부터 받은 데이터를 그대로 바로 전달하므로 지연 시간이 적습니다.
  

단점

• 서버 운영 비용
  SFU는 클라이언트 간에 스트림을 중계하기 때문에 서버 및 네트워크 비용이 발생하며, 사용자가 많아지면 서버 확장이 필요할 수 있습니다.
• Bitrate 관리 필요
  SFU 서버는 여러 비디오 스트림을 선택적으로 전달하기 때문에, 각 사용자의 네트워크 상태에 맞춰 Bitrate를 조절해야 합니다.
  
• 중앙 서버 의존성
  SFU 방식은 서버가 다운되면 전체 연결이 끊어질 수 있습니다. 이를 대비해 여러 서버를 활용한 부하 분산이나 백업이 필요할 수 있습니다.
  

용어

STUN, TURN 서버

STUN과 TURN 서버는 WebRTC에서 P2P(Peer-to-Peer) 연결을 도와주는 중요한 네트워크 프로토콜입니다.

STUN (Session Traversal Utilities for NAT)

STUN 서버는 NAT 환경에서 다음과 같은 역할을 수행합니다:

• 클라이언트가 자신의 공개 IP 주소(Public IP)를 확인할 수 있게 해줍니다
• NAT 뒤에 있는 기기들이 서로 직접 통신할 수 있도록 돕습니다
• 연결 설정 단계에서만 사용되며, 실제 미디어 전송은 피어 간 직접 이루어집니다

TURN (Traversal Using Relays around NAT)

TURN 서버는 STUN의 기능을 포함하면서 추가적인 기능을 제공합니다:

• 직접적인 P2P 연결이 불가능한 경우 중계 서버로 작동합니다
• 방화벽이나 Symmetric NAT와 같은 제한적인 네트워크 환경에서도 통신이 가능하게 합니다
• 연결이 설정된 후에도 계속해서 미디어 데이터를 중계합니다

작동 방식 비교

특징	STUN	TURN
연결 방식	직접 P2P 연결	서버를 통한 중계
리소스 사용	적음	많음
사용 시점	연결 설정 시에만	전체 세션 동안
선호도	우선 시도됨	STUN 실패 시 사용

Interactive Connectivity Establishment (ICE)

Interactive Connectivity Establishment (ICE)

는 브라우저가 Peer를 통한 연결이 가능하도록 하게 해 주는 프레임워크입니다.
Peer A ➡️ Peer B까지 단순하게 연결하는 것으로는 작동하지 않는 것에 대한 이유는 많이 있습니다.

연결을 시도하는 방화벽을 통과 해야하기도 하고, 단말에 Public IP가 없다면 유일한 주소 값을 할당해야할 필요도 있으며 라우터가 Peer 간의 직접 연결을 허용하지 않을 때에는 데이터를 릴레이 해야할 경우도 있습니다.

ICE는 이러한 작업을 수행하기 위해서 위해서 설명하였던 STUN, TURN Server 두개 다 혹은 하나의 서버를 사용합니다.

Session Description Protocol (SDP)

P2P 연결을 설명하는 표준입니다. SDP에는 오디오 및 비디오의 코덱, 소스 주소, 타이밍 정보가 포함되어 있습니다.

참고자료

https://medium.com/@hyun.sang/webrtc-webrtc%EB%9E%80-43df68cbe511

https://web.dev/articles/webrtc-infrastructure?hl=ko#what_is_signaling

https://www.youtube.com/watch?v=bWcNEk0H4Y0