NodeJS - WebRTC

WebRTC (Real-Time Communication)

WebRTC 란 웹 브라우저만으로 실시간 화상 통신을 구현할 수 있는 API이다.

기존에는 플래시와 같은 서드 파티 소프트웨어를 사용하여 화상 통신을 구현 했으나
WebRTC를 사용하여 서드 파티를 사용하지 않고 웹브라우저로만 와상 통신 서비스가 가능해졌다.

모든 브라우저가 아닌 WebRTC기능을 포함한 브라우저(Chrome)을 사용해야 가능하다.
(https://caniuse.com/#search=webrtc)

WebRTC를 지원하는 브라우저 목록

WebRTC API

• getUserMedia: 사용자 단말기의 미디어 장치를 액세스할 수 있는 방법을 제공한다. 미디어 장치라 함은 마이크와 웹캠을 의미한다. getUserMedia 를 통해 미디어 장치를 액세스 하게 되면 미디어 스트림 객체를 얻을 수 있으며 이를 PeerConnection 에 전달하여 미디어 스트림을 전송하게 된다.
• PeerConnection: 가장 중요한 API 이면서 Peer 간의 화상과 음성 등을 교환하기 위한 거의 모든 작업을 수행하는 API 이다.
  WebRTC 어플리케이션이 Peer 간의 연결을 생성하고 오디오와 비디오의 통신에 사용되는 API이다.
• DataChannel: Peer 간에 텍스트나 파일을 주고 받을 수 있는 메시징 API 이다.

SDP (Session Description Protocol)

PeerConnection 객체를 생성하게 되면 PeerConnection 객체에서 offer SDP, answer SDP 를 얻을 있다.
SDP는 미디어에 대한 메타 데이터로 사용할 수 있는 코덱은 무엇들이 있으며, 어떤 프로토콜을 사용하고, 비트레이트는 얼마이며, 밴드위드스는 얼마이다 와 같은 데이터가 텍스트 형태로 명시되어 있다.

Offer SDP 란 연결을 먼저 맺기를 원하는 Peer의 SDP 를 일컫는다. 해당 Peer는 자신의 Offer SDP 를 생성하여 다른 Peer 에게 전달하고 전달받은 Peer 는 Answer SDP 를 생성하여 Offer 에게 전달하여 서로의 P2P커넥션을 맺는다.

Offer와 Answer SDP의 공유는 WebRTC자체에서 해결해주지 않으며 중간에서 중재해주는 Signaling Server(ex. NodeJS)가 필요하다.

SDP 교환 절차

엘리스 -> 이브

1. 앨리스가 RTCPeerConnection 객체를 생성합니다.
2. 앨리스가 createOffer() 메소드를 사용하여 제안(SDP Session Description)을 생성합니다.
3. 앨리스가 제안과 함께 setLocalDescription()를 호출합니다.

4. 앨리스는 제안을 문자열화하고 시그널링 메커니즘을 이용하여 이브에게 보냅니다.

5. 이브는 앨리스의 제안을 가지고 setRemoteDescription()를 호출하였으므로 그녀의 RTCPeerConnection가 앨리스의 설정을 알게됩니다.
6. 이브는 em>createAnswer()를 호출하고 이에 대해 로컬 세션 정보(Local Session Description), 즉 이브의 응답을 인자로 전달하는 성공 콜백 함수를 호출합니다.
7. 이브는 setLocalDescription()의 호출을 통해 그녀의 응답을 로컬 기술(Description)으로 설정합니다.
8. 그리고나서 이브는 시그널링 메커니즘을 사용하여 그녀의 문자열화된 응답을 앨리스에게 다시 전송합니다.

9. 앨리스는 setRemoteDescription()을 사용하여 이브의 응답을 원격 세션 기술(Description)으로 설정합니다.

https://usinuniverse.bitbucket.io/blog/webrtc.html

Signaling (Server)

WebRTC 는 P2P 연결을 통해 직접 통신하지만, 이를 중계해주는 과정이 필요하다. 이를 시그널링이라하고 이를 수행하는 서버를 시그널 서버라 칭한다.

WebRTC 명세에는 들어가 있지 않고 표준화된 방법이 존재하지 않으며 어떤 언어로 개발하든 무방하다.

그렇지만 시그널링의 핵심은 비동기적으로 발생하는 Peer 들의 정보(SDP)를 교환하는 일이다. 그러므로 전이중 통신을 지원하는 websocket 으로 이를 구현하는 것이 가장 적합하다.

https://www.html5rocks.com/ko/tutorials/webrtc/infrastructure/#what-is-signaling

Candidate(후보)

p2p 통신을 하려는 양쪽은 네트워크 연결에 관한 정보도 교환해야한다. 여기서 Candidate는 상대가 나에게 접근할 수 있는 네트워크 경로들에 대한 후보들을 뜻한다.

Ice

각 Peer 가 서로 상대방을 찾기 위해 최적의 NetWork 경로를 찾을 수 있도록 도와 주는 프레임웍이다. ICE 는 STUN 과 TURN 을 활용하여 여러 Candidate 를 검출하고 이들 중 하나를 선택하여 Peer 간 연결을 수행한다.

이를 위해  ICE 서버 URL들을 RTCPeerConnection으로 전달해야한다.
ICE는 첫번째로 디바이스 운영체제로와 네트워크 카드로부터 획득한 호스트 주소를 사용하여 연결을 생성하려 합니다.
만약 실패한다면 (디바이스가 NAT 뒤에 있을 것입니다.) ICE는 STUN 서버를 이용하여 외부 주소를 획득하고 그것이 실패한다면 TURN 중계 서버를 통해 트래픽을 라우팅한다.

STUN

NAT들은 사설 로컬 네트워크에서 디바이스에 IP 주소를 제공하지만 이 주소는 외부에서 사용될 수 없다. 이 문제를 해결하기 위해서 WebRTC는 STUN을 사용한다.
STUN Client 는 NAT나 방화벽 뒤에 존재하며 STUN 서버는 공인 IP 망에 존재한다. STUN Client 는 STUN 서버에게 나의 공인 IP 주소는 무엇인가 라고 질의 하게 되고 STUN 서버는 이를 찾아 응답하게 된다. 이렇게 찾아진 공인 IP 를 통해서 peer 간의 통신을 설정하게 된다.

https://cryingnavi.github.io/WebRTC-Basic/

TURN

STUN 을 통해 통신 설정을 시도 했지만 실패하고 Peer 가 결국 서로를 찾지 못 했을 경우 TURN 서버가 Peer 간의 모든 정보를 중계하여 준다. TURN 은 Peer 간에 발생하는 모든 미디어에 대한 일종의 미디어 proxy 서버라 할 수 있다.

Peer 간의 모든 트래픽을 중계해 주어야 하므로 상당한 부하를 감당해 내야만 한다. 그러므로 실제 서비스에서 가장 큰 비용이 드는 부분이다.

https://cryingnavi.github.io/WebRTC-Basic/

무료 turn, stun서버 리스트

https://gist.github.com/zziuni/3741933

WebRTC의 전체적인 흐름도

https://www.html5rocks.com/ko/tutorials/webrtc/infrastructure/#after-signaling-using-ice-to-cope-with-nats-and-firewalls

---

출처

https://cryingnavi.github.io/WebRTC-Basic/

WebRTC Basic

https://www.html5rocks.com/ko/tutorials/webrtc/infrastructure

WebRTC in the real world: STUN, TURN and signaling - HTML5 Rocks

https://wecomm.tistory.com/3

WebRTC 의 기본요약

https://usinuniverse.bitbucket.io/blog/webrtc.html

불러오는 중입니다...

http://hacks.mozilla.or.kr/2013/08/webrtc-and-the-ocean-of-acronyms/

WebRTC 기술 약어 모음집 ★ Mozilla 웹 기술 블로그