[WebRTC] WebRTC 이해하기

Suzie·2022년 12월 28일

WebRTC

Web Real-Time Communication
웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술

드라이버나 플러그인 설치 없이 웹 브라우저 간 P2P 연결로 데이터 교환
UDP 방식
- 빠르지만 데이터 손실에 대한 리스크

01_Cross-Browser Compatibility Issues

: 아직 다양한 플랫폼에서 표준화가 완전하지 않음

각 브라우저의 WebRTC API에 vendor prefix가 붙어있음(moz, webkit)
- vendor prefix: 표준이 아닌 CSS 속성을 사용할 때 쓰는 prefix
따라서 adapter.js 꼭 함께 사용해야 함
- 서로 다른 웹 브라우저에서 구현된 WebRTC 코드들의 호환성 문제를 해결해주는 js 코드 모음
- Polyfill과 Shim 사용해 다양한 플랫폼에서 WebRTC 구현 간의 차이 없애 줌

Polyfill: 최신 기능을 지원하지 않는 이전 브라우저에서 최신 기능을 사용할 수 있게 도와주는 코드 모음(브라우저가 지원하지 않는 신규 API를 구현하기 위해)
Shim: 이미 존재하는 코드의 동작을 바로잡는 데 사용하는 코드 모음(문제를 일으키는 신규 API에 대응하기 위해)

02_P2P 절차

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

03_NAT traversal(NAT 트래버셜)

: P2P 통신을 위해 라우터(NAT역할)의 공인 IP주소와 포트를 알아야하는데 방화벽설정이 되어있는 경우 라우터를 통과해 연결하기 위해 NAT traversal 사용

STUN(Session Traversal Utilities for NAT)
- 단말이 자신의 공인 IP주소와 포트를 확인하는 과정에 대한 프로토콜
- 자기 자신을 식별할 수 있는 정보 반환
- WebRTC 연결 시작 전 STUN 서버 향해 요청을 보내면, STUN서버는 NAT 뒤에 있는 Peer들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아줌(우리 집 주소 찾기)
TURN(Traversal Using Relay NAT)
- 방화벽 문제 혹은 Symmetric NAT(연결된 적 있는 서버만 연결 가능하게)등으로 자기 주소를 못찾으면 대안으로 사용
- 네트워크 미디어를 중개하는 서버 이용(P2P가 아님, overhead 발생)
- 보안이 엄격한 개인 NAT 위치한 브러우저와의 통신 최후의 수단

NAT(Network Address Translation, 네트워크 주소 변환)
- IP패킷의 TCP/UDP 포트 숫자와 소스 및 목적지 IP 주소 등을 재기록 하면서 라우터를 통해 네트워크 트래픽을 주고받는 기술
- 주로 사설 네트워크에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위해 사용함
- 사용 목적
    - 인터넷의 공인 IP주소 절약가능
    - 인터넷이란 공공망과 연결되는 사용자들의 고유한 사설망을 침입자들로 부터 보호 가능

DHCP(Dynamic Host Configuration Protocol)
- 호스트의 IP주소와 각종 TCP/IP 프로토콜의 기본 설정(네임 서버 주소, IP주소, 게이트웨이 주소 할당)을 클라이언트에게 자동적으로 제공해주는(임대) 동적 주소 할당 프로토콜
- 장단점
    - PC의 수가 많거나 PC 자체 변동사항이 많은 경우 IP 설정이 자동으로 되기 때문에 효율적으로 사용 가능
    - IP를 자동으로 할당해주기 때문에 IP 충돌을 막을 수 있음
    - DHCP 서버에 의존되기 때문에 서버 다운 됐을 때 작동 문제

04_ICE(Interactive Connectivity Establishment)

: 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크

ICE가 STUN,TURN 서버를 이용해 상대방과 연결 가능한 Candidate 가짐(IP주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소)

SDP(Session Description Protocol)
: WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜
- Offer/Answer 모델(peer가 미디어 스트림 교환할 것이라고 제안하면, 상대방으로부터 응답이 오기를 기다림)
- 응답을 받으면 피어가 수집한 ICE 후보 중 최적경로 선택
- peer에서 로컬 데이터 스트림 엔드포인트 생성

Trickle ICE
- 일반적으로 peer는 ICE Candidates를 한번에 교환
- 이러한 비효율적인 후보 교환 작업을 병렬 프로세스로(비동기적) 수행할 수 있게 만들어줌

05_WebRTC APIs

getUserMedia
- Chrome 및 Firefox에 내장되어 있으며 브라우저가 카메라 및 마이크의 output capture로 음성 및 비디오 스트리밍 할 수 있음
RTCPeerConnection
- local 컴퓨터를 remote peer와 연결하고 효율적인 통신을 위해 stable connection 유지
PTCDataChannel
- non-audiovisual data(text chats, image)교환 가능케함

06_Signaling

: RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정

'직접 구축'하거나 '외부 솔루션'을 사용한다.
하지만 영상통화만 구현하는 게 아니라, 어쨌든 사용자 간의 통신 메커니즘이 필요하기 때문에
다른 대안은 보다는 동일한 신호 프로토콜 사용하자

직접 구축
- WebSocket
- Server-sent Event
- API 만들고 브라우저에서 XHR 요청, polling
외부 솔루션
- Kinesis Video Stream(Amazon)
- AppRTC(Google)

07_WebRTC Architecture

Mesh
- P2P, 1:1
- client에 부담, 1:N, N:M일때는 더
- Signaling server
MCU
- 1 upstream, 1 downstream
- 서버가 peer stream을 모아 incoding & decoding 모두 해줌
- peer 부하가 가장 적고, 서버 부하가 큼
- Media server + Signaling server
SFU
- 1 upstream, N downstream
- Mesh보다는 서버가 부하 부담
- Media server + Signaling server

Recap

(1) video chat을 시작할 때 나(peer1)와 peer2는 서로의 브라우저 정보를 얻기 위해 NAT firewall을 우회해 STUN, TURN 서버가 필요
(2) Offer에 ICE candidates를 넣어 SDP를 통해 peer2에게 전송
(3) peer2에게 ICE candidates와 함께 response(Answer)받음
(4) 두 브라우저가 negotiate & create a channel(secure, encrypted)
(5) 실시간 통신을 통해 비디오, 오디오, 텍스트 데이터 공유