WebRTC란?

WebRTC란?

Web Real-Time Communication의 약자로, 웹이나 앱에서 서버 중개 없이 클라이언트끼리 직접 카메라, 마이크 등을 이용한 실시간 통신을 가능하게 하는 기술이다.

WebRTC의 동작 방식

두 클라이언트가 P2P로 대화하기 위해서는 Signaling이라는 과정을 거쳐야 한다.

Signaling

• Signaling 과정: 두 클라이언트가 P2P로 연결되기 위해 ICE Candidate와 SDP 정보를 교환하여 최적의 연결 경로를 설정하는 과정이다. Signaling은 WebRTC에서 명시하지 않으므로 WebSocket, HTTP 등의 프로토콜로 구현 가능하다.

  • SDP (Session Description Protocol): 통신할 미디어의 유형, 코덱, 해상도 등의 정보를 담아 교환.
  • ICE Candidate (Interactive Connectivity Establishment): 연결 가능한 네트워크 경로 후보 정보를 상대방에게 제공한다.

    • Host Candidate: 한 집이나 같은 오피스와 같이 동일 네트워크에 속한 경우이다. 사설 IP와 포트로 연결할 수 있다.

    • Server Reflexive Candidate: 다른 공인 IP 환경에서 STUN 서버로 공인 IP 주소와 포트 번호를 얻어 연결.

        - NAT: 여러 장치가 하나의 공인 IP 주소를 통해 인터넷에 접속하는 것.
      
        - STUN 서버: 클라이언트가 요청을 보내면 공인 IP 주소와 포트 번호를 응답해주는 서버.
      

    • Relay Candidate: 방화벽이나 복잡한 네트워크 환경에서는 TURN 서버를 통해 통신. 이 경우에는 추가적인 경로를 거치게 되므로 지연 시간이 증가하고, 비용 또한 발생하게 되므로 마지막 옵션으로만 사용된다.

        - TURN 서버: 클라이언트들은 TURN 서버를 가운데 두고, 이를 통해 소통하게 된다.
      

  각 클라이언트들은 각자 가용한 ICE Candidate 정보를 SDP에 포함시켜 상대방에게 전달한다. 이를 통해 서로가 무엇으로, 그리고 어떻게 소통할 수 있는지 확인한 다음, 가장 최선의 방법을 선택하여 연결을 설정하고, 본격적으로 P2P 소통을 시작하게 된다.

데이터 통신

연결된 이후에는 주로 SRTP와 SCTP 중 소통의 특성과 용도에 맞는 프로토콜을 사용하여 데이터를 전송하게 된다.

WebRTC에서 이루어지는 소통은 주로 화상통화나 음성통화와 같은 것이기 때문에 **SRTP**와 **SCTP**는 정보의 신뢰성을 보장하기 위한 TCP보다는 빠른 대용량 전송에 적합한 **UDP 기반**으로 되어 있다.

• SRTP (Secure Real-time Transport Protocol)

  비디오나 오디오의 실시간 전송에 적합한 프로토콜.

• SCTP (Stream Control Transmission Protocol)

  파일 전송의 경우에는 UDP 기반이지만 TCP와 유사하게 신뢰성을 보장하도록 설계되어 있는 SCTP를 사용

WebRTC의 장단점

장점

• 브라우저 내장 API 제공
  • 별도의 플러그인이나 설치 과정 없이, 주요 브라우저(Chrome, Firefox, Safari 등)에 내장된 API만으로 실시간 통신 기능을 구현할 수 있어 사용이 간편하다.
• 서버 비용 절감
  • 클라이언트 간 P2P 연결을 통해 데이터를 주고 받기 때문에, 미디어 스트림이 서버를 거치지 않는다. 이로 인해 서버의 부하가 줄어들고 비용을 절감할 수 있다.
• 낮은 지연 시간(Low Latency)
  • UDP 기반의 전송 방식을 사용하여 실시간 통신의 지연 시간을 최소화한다.
• 높은 확장성과 유연성
  • WebRTC는 단순한 1:1 통신부터 다대다 통신까지 유연하게 확장할 수 있다. Mesh, SFU, MCU 등의 구조를 통해 적합한 방식으로 확장 가능하다.

단점

• STUN 및 TURN 서버의 필요성
  • NAT 환경에서 클라이언트 간 직접 연결이 어려운 경우 STUN 및 TURN 서버가 필요하다. 특히 TURN 서버는 데이터를 중계하므로 비용이 발생하며, 서비스에 따라 성능에 영향을 줄 수 있다.
• 브라우저 및 플랫폼 간 호환성 문제
  • WebRTC는 표준이지만, 브라우저 및 플랫폼에 따라 구현 방식이 다를 수 있어 개발 시 호환성 테스트가 필요하다. 특히, 모바일 환경에서는 성능이나 호환성 문제가 더 두드러질 수 있다.
• P2P의 한계
  • WebRTC의 P2P 방식은 다수의 사용자가 연결될 경우 대역폭 소모가 크게 늘어나고, 특히 Mesh 방식에서는 참여자 개별의 네트워크와 CPU 부담이 커지게 된다. 따라서 대규모 회의나 방송 같은 다중 사용자 환경에서는 SFU나 MCU와 같은 중앙 서버 방식을 고려해야 한다. 다만, 이러한 방식은 추가 서버 설정 및 비용이 발생할 수 있다.
• 네트워크 환경에 민감함
  • WebRTC는 지연 시간과 연결 안정성이 중요한 실시간 통신을 위해 설계되었지만, 네트워크 속도나 품질이 좋지 않은 경우 품질 저하가 발생할 수 있다. 특히, 영상 통화의 경우 품질이 크게 영향을 받는다.

다대다 통신

많은 사용자가 참여하는 다대다 통신의 경우에는 오히려 WebRTC의 성능이 감소할 수 있다. 그렇기에 다대다 통신의 경우에는 SFU나 MCU 등 추가적인 기술을 적용해야 한다.

Mesh

모든 참여자가 자신의 미디어 스트림을 나머지 피어들에게 보내고, 동시에 다른 나머지 참여자들의 미디어 스트림을 모두 전달받는다.

• 장점
  • 비교적 비용이 적게 든다.
  • 구현이 간단하다.
• 단점
  • 연결해야 할 참여자가 많을수록 스트림의 수가 급격히 늘어나기 때문에 참여자 개인의 하드웨어 및 네트워크 환경에 큰 부담을 주는 구조가 될 수 있다.

이 방식은 1:1 혹은 소규모 미디어 교환에 적합하다.

SFU

중앙 서버를 통해 종단간 미디어 트래픽을 중계하는 중앙 서버 방식이다. SFU 방식은 사용자들로부터 각각의 미디어 스트림을 받아 매 순간마다 선택적으로 전달하는 라우팅 머신 역할의 중간 서버를 둔다. 중간 서버에서는 별도의 미디어 가공 과정을 거치지 않고 그대로 각 사용자들에게 전달하며, 각 피어간 연결 할당·암호화 및 복호화 처리 비용 정도를 감수하고 있다.

비교적 서버에 부하가 적게 걸리고 지연시간 역시 낮기에 영상 방송과 같은 1:N 스트리밍 서비스, 혹은 조금 더 확장하여 N:N 소통에 폭넓게 사용되고 있다.

MCU

각 참여자의 미디어 스트림을 중앙 서버에 한꺼번에 모아 믹싱한 후, 그 결과물을 다시 각각의 참여자들에게 전달한다.

다수 참여자의 송출 미디어를 중앙 서버에서 열람해보고 혼합, 또는 가공하여 수신단으로 전달하는 방식이기에, 클라이언트 측 리소스 부담을 줄이고, 네트워크 대역폭을 절약할 수 있지만, 중앙 서버의 리소스 사용이 크게 증가하며, 스트림 믹싱 과정에서 지연이 발생할 수 있다.

믹싱: 여러 클라이언트의 비디오 스트림을 **하나의 통합된 비디오 스트림으로 결합하여 전송**하는 것. 좀 더 자세히 말하자면 "하나의 화면에서 여러 참가자의 비디오를 동시에 볼 수 있도록 레이아웃을 구성하여 전송"하는 방식.

참고

• https://www.youtube.com/watch?v=bWcNEk0H4Y0
• https://gh402.tistory.com/38
• https://medium.com/pplink/1000%EB%AA%85%EC%9D%B4%EC%84%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%BB%A4%EB%AE%A4%EB%8B%88%EC%BC%80%EC%9D%B4%EC%85%98%EC%9D%84-%ED%95%98%EB%8A%94-%EA%B0%80%EC%9E%A5-%ED%9A%A8%EA%B3%BC%EC%A0%81%EC%9D%B8-%EB%B0%A9%EB%B2%95-ca039fbcaedb