WebRTC (Web Real-Time Communication)

• 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술
• WebRTC를 구성하는 일련의 표준들은 플러그인이나 제 3자 소프트웨어 설치 없이 종단 간 데이터 공유와 화상 회의 가능
• 음성, 화상 회의, 파일 교환 등의 멀티미디어 기능 제공

WebRTC 개념 및 사용법

• WebRTC는 피어들 간의 커넥션이 만들어지는데 어떤 드라이버나 플러그인도 필요하지 않다. 두 피어 간의 커넥션은 RTCPeerConnection 인터페이스를 통해 이루어진다. 커넥션이 이루어지고 열리면, 미디어 스트림(MediaStream)들과 데이터채널(RTCDataChannel)들을 커넥션에 연결할 수 있다.

인터페이스

• RTCPeerConnection

  로컬 컴퓨터와 원격 피어 간의 WebRTC 연결을 담당하며 원격 피어에 연결하기 위한 메서드들을 제공하고, 연결을 유지하고 연결 상태를 모니터링하며 더 이상 연결이 필요하지 않을 경우 연결을 종료합니다.

  RTCPeerConnection → EventTarget

• RTCDataChannel

  임의의 데이터의 양방향 Peer-to-Peer 전송을 위해 사용될 수 있는 네트워크 채널을 나타낸다. 모든 데이터 채널은 RTCPeerConnection과 연결되며 각 피어 연결에는 이론상 최대 65,534개의 데이터 채널이 존재할 수 있다.
  데이터 채널을 만들고 원격 피어에 가입을 요청하려면 RTCPeerConnection의 createDataChannel()를 호출한다. 데이터 교환에 초대된 피어는 데이터 채널이 연결에 추가되었음을 알리는 datachannel 이벤트를 수신한다.

• RTCDataChannelEvent

  RTCDataChannelEvent() 생성자는 datachannel을 나타내는 신규 RTCDataChannelEvent 객체를 반환한다. 이 이벤트는 두 피어 사이에서 원격 피어가 RTCDataChannel을 개통하도록 요청되었을 때 RTCPeerConnection에 전달된다.

• RTCIceCandidate

  WebRTC API의 한 종류로서, RTCPeerConnection을 구축할 때 사용되기도하는 Internet Connectivity Establishment(ICE)의 후보군(candidate)를 말한다.
  하나의 ICE candidate는 WebRTC가 원격 장치와 통신을 하기 위해 요구되는 프로토콜과 라우팅에 대해 알려준다. WebRTC 피어 연결을 처음 시작하게 되면, 일반적으로 여러 개의 candidate들이 연결의 각 end에 의해 만들어진다.그리고 이 과정은 로컬 유저와 원격 유저가 연결을 위해 최고의 방법을 서로의 동의하에 선택하기 전까지 계속된다.이후에 WebRTC가 선택한 candidate를 사용해서 연결을 시도하게 된다.

• RTCIceTransport

  인터넷 연결 설정(ICE) 전송에 대한 정보를 나타낸다.

• RTCPeerConnectionIceEvent

  대상이 있는 ICE 후보와 관련하여 발생하는 이벤트(일반적으로 RTCPeerConnection)을 나타낸다. icecandidate 유형의 이벤트만 있음.

• RTCRtpSender

  RTCPeerConnection에서 MediaStreamTrack의 데이터 인코딩 및 전송을 관리한다.

• RTCRtpReceiver

  RTCPeerConnection에서 MediaStreamTrack의 데이터 디코딩 및 수신을 관리한다.

• RTCTrackEvent

  새롭게 수신된 MediaStreamTrack이 생성되고 관련 RTCRtpReceiver 개체가 RTCPeerConnection 개체에 추가되었음을 나타낸다.

• RTCSctpTransport

  스트림 제어 전송 프로토콜(Stream Control Transmission Protocol, SCTP (en-US)) 전송을 설명하는 정보를 제공하고, 모든 RTCPeerConnection 데이터 채널에 대한 SCTP 패킷이 송수신되는 기본 데이터그램 전송 보안 계층 프로토콜(Datagram Transport Layer Security, DTLS (en-US)) 전송에 접근하기 위한 방법을 제공합니다.

P2P 절차

• WebRTC는 P2P 방식의 커뮤니케이션이기 때문에 각각의 웹 브라우저는 다음과 같은 절차를 밟아야 한다.

1. 각 브라우저가 P2P 커뮤니케이션에 동의
2. 서로의 주소를 공유
3. 보안 사항 및 방화벽 우회
4. 멀티미디어 데이터를 실시간으로 교환

방화벽과 NAT 트래버셜

• 일반적인 컴퓨터에는 공인 IP가 할당되어 있지 않음. 방화벽(Firewall), 여러 대의 컴퓨터가 하나의 공인 IP를 공유하는 NAT, 유휴 상태의 IP를 일시적으로 임대받는 DHCP때문.
• 단순히 공인 IP만을 알아낸다고 해서, 특정한 사용자를 가리킬 수 없음 & 해당 네트워크에 연결된 사설 IP 주소까지 알아내야 특정한 사용자를 지정 가능
• 일반적으로 라우터가 NAT 역할을 함. 외부에서 접근하는 공인 IP와 포트 번호를 확인하여 현재 네트워크 내의 사설 IP들을 적절히 매핑시켜줌.
• 즉, 어떤 브러우저 두 개가 서로 직접 통신을 하려면, 각자 현재 연결된 라우터의 공인 IP 주소와 포트를 먼저 알아내야 함.
• NAT 트래버셜(NAT traversal) : 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어 있을 수도 있는데 이처럼 라우터를 통과해서 연결할 방법을 찾는 과정

STUN (Session Traversal Utilities for NAT)

단말이 자신의 공인 IP 주소와 포트를 확인하는 과정에 대한 프로토콜.
STUN 서버는 인터넷의 복잡한 주소들 속에서 유힐하게 자기 자신을 식별할 수 있는 정보를 반환해줌.
즉, WebRTC 연결을 시작하기 전에 STUN 서버를 향해 요청을 보내면, STUN 서버는 NAT 뒤에 있는 피어(Peer)들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아줌

TURN (Traversal Using Relay NAT)

STUN 방식을 통해 자신의 정보를 알아내지 못한 경우, TURN 서버를 대안으로 이용.
TURN 방식은 네트워크 미디어를 중개하는 서버를 이용. 중간에 서버를 한 번 거치기 때문에, 정확하게는 P2P 통신이 아니게 되며 그 구조상 지연이 필연적으로 발생하게 됨. 보안 정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이기 때문에, TURN 방식은 최후의 수단으로 선택되어야 함.

ICE와 Candidate

후보(Candidate)

• STUN,TURN 서버를 이용해서 획득했던 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소 → 후보 찾기 (Finding Candidate)

후보들을 수집하면 일반적으로 3개의 주소 얻을 수 있음.

• 자신의 사설 IP와 포트 넘버
• 자신의 공인 IP와 포트 넘버 (STUN, TURN 서버로부터 획득 가능)
• TURN 서버의 IP와 포트 넘버 (TURN 서버로부터 획득 가능)

이 모든 과정은 ICE라는 프레임워크 위에서 이루어짐.

ICE(Interactive Connectivity Establishment)

• 두개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크
• ICE 프레임워크가 STUN, 또는 TURN 서버를 이용해 상대방과 연결 가능한 후보들을 갖고 있음.

Reference

WebRTC_API
WebRTC는 어떻게 실시간으로 데이터를 교환할 수 있을까?
WebRTC란? (STUN과 TURN 서버의 이해) (2)
Build the backend services needed for a WebRTC app
kurento-tutorial-java