Framework & Library/WebRTC

WebRTC 개념 정리

RUCKUS 2021. 6. 14. 10:00

프로젝트에서 화상채팅 서비스를 구현해야하는 부분을 담당하게 되었다.

 

막연히 WebRTC쓰면되겠지 뭐~ 라고 생각했는데, 관련 자료들을 서칭해보니 생각보다 기초 지식을 탄탄하게 습득하고 넘어가야 할 것 같다는 판단이 들었다. (시그널링은 무엇이며, peerconnection?은 뭐고... 어떤식으로 동작하는지 등등)

 

하여 내가 이해하는 과정에서 두서없이 막 정리해보려고 한다.

 

아무생각 없이 영상부터 봐보자.

먼저 GoogleDevelopers 유투브 채널에 올라온 영상을 보면서 천천히 익혀보려고 한다.
(영어는 100% 이해안되지만 댓글에 

The only video that provides so much valuable information for beginners at WebRTC.
WebRTC의 초보자들에게 매우 귀중한 정보를 제공하는 유일한 비디오.

라고 작성이 되어있다.)

 

Real-time communication with WebRTC: Google I/O 2013

동영상 내용 이해한 대로 정리하기

  • RTC : Real Time Communication
  • WebRTC는 실시간이야. 그냥 웹페이지 로딩만으로 가능해!
  • WebRTC에 주요 3가지 Tasks가 있다.
    1. 입력 장치에 액세스하기
        마이크 액세스, 웹캠 액세스
    2. 다른 WebRTC에 연결
        
    3. 임의의 데이터 연결?
  • Three main JS APIs
    - MediaStream (aka getUserMedia) : 미디에어 엑세스
    - RTCPeerConnection
    - RTCDataChannel

미디어 스트림

  • 미디어 스트림은 동기화된 단일 소스
  • 미디어 스트림은 하나의 이상의 미디어 스트림 트랙이 포함된다. (예를 들면 웹캠, 마이크)
  • getUserMedia의 메소드를 사용하여 약세스 할 수 있다.

 

RTCPeerConnection

  • getUserMedia에서 스트림을 연결하고 peer커넥션으로 연결한다.
  • RTCPeerconnecton을 이용하여 getUserMedia로 호출한 비디오를 전달해준다.

 

RTCDataChannel

  • Websocket과 비슷한 역할을 한다?? 데이터를 전달하고 받는 거라고 보면 될 것 같다.
  • 아주 낮은 레이턴시
  • 신뢰할 수 있거나 없거나
  • 보안

Servers and Protocol

  • P2P 연결을 위해서는 서버가 필요하다.
  • 양측 연결 대상은 세션을 진행하는데 동의할 수 있는데, 이 과정을 시그널링이라고 한다.
  • WebRTC의 시그널링은 추상적이다. 그 말은 완전히 정의된 프로토콜이 없다는 의미이다. 중요한 부분은 세션을 교환하기만 하면 된다는 것이다.
    - 교환하기 위해 필요한 세션 정보 객체 : 지원하는 형식, 보낼 형식, Peer-to-Peer 설정을 위한 네트워크 정보
    - 모든 메세징 메커니즘 사용가능
    - 모든 메세징 프로토콜 사용가능
    - Websocket쓸지, XHR쓸지, JSON으로 전달할지 등등 이러한 부분에 큰 제약이 없다는 의미같다.

STUN and TURN

STUN

  • 이전에는 양측에 공용 IP주소가 있었다. 하지만 지금은 조금 복잡하다. NAT시대에는 사설 IP주소를 제공하여 실제로 P2P 링크를 만들 수 있는 방법이 없다. 그러하기 때문에 STUN이라는 기술을 제공하는 것.

    As_is -> To_be
  • 간단하게 정리하면 STUN서버가 공용IP 처럼 P2P로 통신할 수 있게 하는 것 같다. 내 공용IP를 알려달라고 요청하는 느낌이라고 보면 된다.

TURN

 

  • STUN 서버의 단점을 보완해주는 느낌인 것 같다. 방화벽이나 네트워크 정책 등등에 의해 STUN 서버가 연결되지 않을 경우 TURN 서버를 대안으로 이용한다.
  • TURN은 클라우드를 중개서버로 이용하는?? 거로 이해했다. 결국 직거래라기 보다는 공인중개사를 이용하는 개념이랄까?? 그렇다면 전송속도나 이런 부분에 속도 저하가 있거나 할 것 같다.

 

ICE

 

  • peer 들 간의 연결을 위한 프레임워크 이다.
  • 각 통화에 가장 적합한 방법을 찾으려고 시도 한다.
  • 대부분 call은 STUN을 사용할 것이다. (TURN은 최후의 수단)

 

Security

  • 미디어 및 데이터에 대한 필수 암호화
  • Secure UI, 명시적인 옵션 제공
  • 구글 샌드박스 사용, 플러그인 없음
  • WebRTC Security Architecture

HTTPS만 쓰면 된다고 한다. HTTPS 사용방법에 대해서 고민해야할 듯 하다.

 

Architectures

어떻게 어플리케이션을 설계해야할까?

  • 단순히 1:1 통신이면 쉽다. 근데 다중 사용자간에는 이 부분이 복잡해지는데 blah..blah...결과적으로 MCU를 사용하기를 추전한다.
  • Peer to Peer
  • Mesh


  • Star
  • MCU

다음에는 초기 세팅을 공부하고 기록해보려고 한다.