[Android][WebRTC] 1. WebRTC란 무엇일까?

WebRTC란 무엇일까?

 

웹 브라우저 기반의 통신 방식인 WebRTC는 구글이 오픈 소스화한 프로젝트에서 기원하였다

오픈 소스 - 위키백과, 우리 모두의 백과사전

 

MDN 에서 WebRTC를 이렇게 정의하였다.
https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API
WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다. 

WebRTC API - Web API | MDN

• Web Real-Time Communications
• 별도의 소프트웨어 없이 음성, 영상 텍스트, 파일 등의 데이터를 브라우저끼리 주고 받을 수 있게 만든 기술
• P2P 통신에 최적화

P2P(Peer-to-Peer) 네트워크란? 중앙 서버없이 각 단말들이 서로 동등한 입장에서 통신을 하는 네트워크를 뜻한다. 즉 각 단말은 서버이기도 하면서 동시에 클라이언트가 된다. 중앙 집중식 관리 시스템을 사용하지 않고, 상호 연결된 노드(피어)들이 서로 간에 자원을 공유하는 P2P 네트워크. 이 네트워크 구성 모델은 보통 중앙 서버를 통하는 통신 형태의 클라이언트-서버 모델과는 구별된다. https://ko.wikipedia.org/wiki/P2P P2P 네트워크의 장단점 서버를 준비할 필요가 없고, 각 노드들이 트래픽과 자원을 할당해 부하를 분산시켜줌 즉, 노드가 증가하더라도 서비스를 유지할 수 있는 높은 확장성을 갖고 있음 새로운 기능을 추가하거나 업데이트를 할 경우 관리가 어려움 네트워크 전송 시간 때문에 노드간 정보 불일치, 성능 저하가 발생하기 쉬움

• 크게 다음과 같은 클래스에 의해 실시간 데이터 교환
  • getUserMedia() : 사용자의 device에서 오디오와 비디오 데이터 추출 할 장치를 준비
  • MediaStream : 카메라와 마이크 등의 데이터 스트림 접근
  • RTCPeerConnection : 암호화 및 대역폭 관리 및 오디오, 비디오 연결, 
    Peer들 간의 데이터를 안정적이고 효율적으로 통신 처리
  • RTCDataChannel : 일반적인 데이터의 P2P 통신

이 4가지의 객체를 통해 데이터 교환이 이뤄지며

RTCPeerConnection들이 적절하게 데이터를 교환할 수 있게 처리해주는 과정을 시그널링(Signaling)이라고 한다.

 

Signaling은 3가지 종류의 정보를 교환합니다.

• Session control messages: 통신의 초기화, 종료 그리고 애러 리포트를 위해.
• Network configuration: 외부 세상으로 내 컴퓨터의 IP 주소와 Port는 어떻게되지 ?
• Media capabilities: 내 브라우저와 상대브라우저가 사용 가능한 코덱들과 해상도들은 어떻게 되지?

 

 

위 그림은 시그널링을 하는 과정이며 PeerConnection은 2 명의 유저가 스트림을 주고 받는 것이므로 연결을 요청하는 콜러(Caller)와 연결을 받는 콜리(Callee)가 존재한다.

 

콜러와 콜리가 통신을 하기 위해서는 중간 역할을 해주는 서버가 필요하고 서버를 통해 SessionDescription을 서로 주고 받아야한다.

 

Caller가 Signaling 서버를 통해 자신의 SessionDescription을 보내면

Callee도 마찬가지로 Signaling 서버를 통해 자신의 SessionDescription을 보낸다.

그 외에도 ICECandidate를 Signaling 서버를 통해 주고받으며 peer 간 연결을 완료하고 Caller와 Callee 간에 Media 데이터를 주고받는다.

 

Peer를 통한 연결이 가능하도록 해주는 ICE(Interactive Connectivity Establishment) 프레임 워크를 수행하기 위해서는
STUN 과 TURN 서버 둘 다 혹은 하나의 서버를 사용해야한다.

 

STUN(Session Traversal Utilities for NAT)

클라이언트 자신의 IP 와 PORT를 알려주고, Peer간의 접근이 가능한지 여부를 결정하는 프로토콜

 

클라이언트는 인터넷을 통해 클라이언트의 Public Address와 라우터의 NAT 뒤에 있는 클라이언트가 접근 가능한지에 대한 답변을 STUN서버에 요청한다.

 

TURN(Traversal Using Relays around NAT)

STUN( Session Traversal Utilities for NAT )은 애플리케이션이 NAT를 통과하는 한 가지 방법을 제공합니다. STUN을 사용하면 클라이언트가 피어로부터 패킷을 수신하는 데 유용할 수 있는 전송 주소(IP 주소 및 포트)를 얻을 수 있습니다. 

그러나 STUN에서 얻은 주소는 모든 피어에서 사용할 수 없습니다. 이러한 주소는 네트워크의 토폴로지 조건에 따라 작동합니다. 따라서 STUN 자체는 NAT 통과를 위한 완전한 솔루션을 제공할 수 없습니다.

 

완전한 솔루션을 위해서는 클라이언트가 패킷을 공용 인터넷으로 보낼 수 있는 모든 피어로부터 미디어를 수신할 수 있는 전송 주소를 얻을 수 있는 수단이 필요합니다. 이것은 공용 인터넷에 상주하는 서버를 통해 데이터를 릴레이함으로써만 수행할 수 있습니다. 중계 NAT(TURN)를 사용한 순회는 클라이언트가 이러한 중계기에서 IP 주소와 포트를 얻을 수 있도록 하는 프로토콜입니다.

 

TURN은 거의 항상 클라이언트에 대한 연결을 제공하지만 TURN 서버 제공자에게는 리소스를 많이 사용합니다. 따라서 가능한 경우 다른 메커니즘(예: STUN 또는 직접 연결)을 선호하는 최후의 수단으로만 TURN을 사용하는 것이 바람직합니다. 이를 달성하기 위해 ICE( Interactive Connectivity Establishment ) 방법론을 사용하여 최적의 연결 수단을 찾을 수 있습니다.

 

 

 

 

참고

• https://velog.io/@jaeyunn_15/Android-WebRTC
• https://www.html5rocks.com/ko/tutorials/webrtc/basics/
• https://m.blog.naver.com/sehyunfa/221678622407
• https://ko.wikipedia.org/wiki/P2P
• https://snowdeer.github.io/blockchain/2017/07/04/blockchain-and-p2p/
• https://surprisecomputer.tistory.com/9
• https://en.wikipedia.org/wiki/STUN