WebRTC-이론

WebRTC란?

• 웹 브라우저와 모바일 애플리케이션에서 실시간 통신을 가능하게 하는 기술이다.

주요 특징

1. 브라우저 간 직접 통신 : 중간 서버 없이 P2P연결을 지원한다.
2. 오디오, 비디오, 데이터 전송 : 실시간 음성 및 화상 통화, 파일 공유 등이 가능하다.
3. 개방형 표준 : W3C와 IETF에서 표준화된 오픈 기술이다.
4. 플러그인 불필요 : 대부분의 현대 브라우저에서 별도의 플러그인 없이 동작한다.
5. 보안 : 암호화된 통신을 제공하여 데이터 보안을 보장한다.

동작 원리

시그널링(Signaling)

• WebRTC 연결을 시작하기 위해 피어 간에 메타데이터를 교환하는 과정이다.
• 시그널링 서버를 통해 SCP(Session Description Protocol) 정보와 ICE 후보를 교환한다.
• WebRTC API는 시그널링 메커니즘을 직접 정의하지 않으므로, 개발자가 선택한 방식(WebSocket, HTTP)을 구현할 수 있다.
• Signaling Server는 WebRTC에서 가장 기본이 되는 서버이다.
• 서로 다른 네트워크에 있는 Peer들을 연결시키기 위해서 Session Control Messages, Error Messages, Codec, Bandwidth등 다양한 정보가 필요하다.
• 결국 WebRTC 기술을 활용해서 Peer끼리 연결하기 위해서는 위의 정보들이 먼저 각각의 Peer들에게 전달돼야 한다는 것이다며, 이 프로세스를 Signaling이라고 한다.
• WebRTC와는 별개로 Signaling Server는 직접 구축해야 하며, 많은 가이드에서 일반적으로 클라이언트 사이드와 WebSocket을 사용하여 통신한다.

1. Client Side의 A Client(Peer)에서 Signaling Server로 연결에 필요한 A Client의 데이터를 보낸다.
   • Signaling Offer
2. ServerSide에서, Signaling Server에 연결된 모든 세션들을 A client의 데이터를 전달하낟.
3. Client Side의 B Client에서 A Client의 데이터를 활용해서 연결에 필요한 일련의 작접을 한 후, B Client의 데이터를 Signaling Server로 보낸다.
   • Signaling Answer
4. Server Side에서, A Client의 세션에게 B Client의 데이터를 전달한다.
5. 각각의 데이터를 활용하여 WebRTC가 A Client와 B Client를 연결한다.

ICE(Interactive Connectivity Establishment)

• 피어 간 직접 연결을 위한 최적의 네트워크 경로를 찾는 프레임 워크이다.
• STUN과 TURN 서버를 사용하여 NAT 통과 및 방화벽 문제를 해결한다.

STUN(Session Traversal Utilities for NAT)

• 클라이언트의 공개 IP 주소와 포트를 확인하는 데 사용된다.
• NAT 뒤에 있는 기기들이 서로를 발견할 수 있게 한다.
• STUN Server는 클라이언트 자신의 공인 IP를 알려주는 서버이다.
• Client에서 STUN server로 요청을 보내서 자신의 공인 IP를 확인한 후 해당 IP를 활용하여 Signaling 하게 된다.
  • 오픈소스나 Google에서 운영하는 STUN Server를 활용하면 된다.
• 단순히 정보 제공을 위한 서버라 트래픽 발생이 현저히 낮기 때문에 웬만하면 무료 STUN Server 를 사용해도 문제가 없다.

TURN(Traversal Using Relays around NAT)

• 직접 연결이 불가능한 경우 사용되는 릴레이 서버이다.
• 미디어 스트림을 중계하여 연결을 가능하게 한다.
• 보호 정책이 강한 NAT나 라우터, Symmetric NAT 환경에서 활용된다.
• TURN Server는 Symmetric NAT 제한을 우회할 수 있게끔 해주는 기능을 한다.
• 결국 TURN Server가 Peer간의 통신 채널을 중계해주는 역할을 하며, WebRTC의 가장 큰 특징인 P2P 방식에서 벗어나게 된다.
• 때문에 Peer간 모든 트래픽을 중계해주기 때문에 상당한 부하를 감당해야 하며, 비용 또한 크게 발생할 것이다.
• 즉, Local IP와 Public IP 둘다로도 연결할 수 없는 경우 Turn Server을 최후의 수단으로 사용한다.
  • 위와 같은 이유로 예전에서는 구글에서 무료 제공하는 Turn Server가 존재했지만 현재는 사용하지 못한다.
• 하지만 안정적인 서비스를 위해서는 TURN 서버를 직접 운영하는 것이 필요할 것이다.
  • COTURN이라는 오픈 소스를 활용해 TURN 서버를 구축하는 것을 강력 추천함.

SDP(Session Description Protocol)

• 연결에 사용될 미디어 형식, 코덱, 암호화 방식 등의 세션 정보를 기술한다.
• ‘Offer’와 ‘Answer’ 형태로 교환된다.

P2P 연결 수립

• ICE 후보 교환이 완료되면 DTLS(Datagram Transport Layer Security)를 사용하여 보안 연결을 수립한다.
• SRTP(Secure Real-time Transport Protocol)를 통해 암호화된 미디어 전송이 이루어진다.

미디어 처리(Media Server)

• WebRTC의 구현 방식에는 크게 3가지로 Mesh, SFU, MCU 방식이 있다.
  • 지금까지 위에서 말한 방식은 Mesh 방식으로 서버의 자원이 적게 들지만 Peer 수가 늘어날 수록 Client 사이드의 과부하가 급격하게 증가하는 방식이다.
  • 때문에 소규모 연결에 적합할 것이다.
• Mesh 방식에서는 Media Server가 필요하지 않다.
• Media Server는 SFU, MCU 방식의 WebRTC에서 필요한 서버로, 각각의 Peer들은 Media Server에게 미디어 스트림들을 쏴주고 Media Server에서 미디어 트래픽을 관리하여 각각의 Peer에게 다시 배포해주는 멀티미디어 미들웨어이다.

• 즉, WebRTC의 특징인 P2P 통신이 아니게 되는 것은 TURN Server와 유사하다고 할 수 있고, 클라이언트에 부하가 현저히 줄어드는 대신 서버의 부하가 커지며 구현의 난이도가 상당히 높다.

• getUserMedia() API를 사용하여 로컬 미디어 스트림(비디오, 오디오)를 획득한다.
• RTCPeerConnection을 통해 원격 피어와 미디어 스트림을 주고받는다.

데이터 채널

• RTCDataChannel API를 사용하여 피어 간 임의의 데이터를 주고 받을 수 있다.
• 게임, 파일 전송 등 다양한 용도로 활용 가능하다.

적응형 비트레이드 조정

• 네트워크 상태에 따라 동적으로 비디오 품질을 조정한다.

NAT 통과 기술

• STUN/TURN 서버를 통해 다양한 네트워크 환경에서도 연결을 수립할 수 있다.

구현 방식의 종류

Mesh 방식

• 앞서 설명한 Signaling Server, STUN Server, TURN Server를 사용하는 전형적인 P2P WebRTC 구현 방식이다.

• 1:1 연결 혹은 소규모 연결에 적합하다.

• 장점
  • Peer 간의 Signaling 과정만 서버가 중계하기 때문에 서버의 부하가 적다.
  • 직접적으로 Peer간 연결되기 때문에 실시간성 보장이 된다.
• 단점
  • 연결된 Client 수가 늘어날 수록 Client의 과부하가 급격하게 증가한다.
  • 간단하게 생각해봐도 N명이 접속한 화상 회의라면, 클라이언트 각각에게 N-1개의 연결을 유지해야 하기 때문이다.

MCU(Multi-point Control Unit) 방식

• 특징
  • 다수의 송출 미디어 데이터를 Media Server에서 혼합 또는 가공하여 수신측으로 전달하는 방식
  • P2P 방식 X, Server와 Client 간의 Peer를 연결한다.
  • Media Server의 매우 높은 컴퓨팅 파워가 요구된다.
• 장점
  • Client의 부하가 크게 줄어든다.
  • N:M 구조에서 사용 가능하다.
• 단점
  • 실시간성이 저해 된다.
  • 구현 난도가 상당히 어려우며 비디오와 오디오를 혼합 및 가공하는 과정에섲 고난도 기술과 서버의 큰 자원이 필요하다.

SFU(Selective Forwarding Unit) 방식

• 특징
  • 각각의 Client 간 미디어 트래픽을 중계하는 Media Server를 두는 방식
  • P2P 방식 X, Server와 Client 간의 Peer를 연결한다.
  • Server에게 자신의 영상 데이터를 보내고, 상대방의 수 만큼 데이터를 받는 형식
  • 1:N 혹은 소규모 N:M 형식의 실시간 스트리밍에 적합하다.
• 장점
  • Mesh 방식 보다 느린 것은 어쩔 수 없다. 하지만 비슷한 수준의 실시간성을 유지할 수 있다.
  • Mesh 방식보다는 Client의 부하가 줄어든다.
• 단점
  • Mesh 방식 보다는 서버의 부하가 늘어난다.
  • 대규모 N:M 구조에서는 여전히 Client의 부하가 크다.