webRTC 의 기초적인 설명은 간단하게 기술할 예정이며, webRTC SFU 방식의 포커싱하여 정리할 예정입니다.
WebRTC 란?
WebRTC(Web Real-Time Communication) 은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다.
- MDN의 WebRTC 문서 인용
MDN 에서 기술한 내용을 참고해 보면 웹 애플리케이션과 사이트가 통신을 하기위해 내 위치 (IP Adress) 를 어떻게 알 수 있는거지? 라는 의문이 발생하게 됩니다.
WebRTC 가 실시간으로 웹에서 데이터교환을 할 수 있는 이유는 시그널링이라고 일컬어지는 NAT 우회 과정을 거치기 때문입니다.
관련하여 어떤 과정들이 일어나게 되는지 아래 기술드리겠습니다.
WebRTC 프로토콜
WebRTC는 TCP와 UDP 기반의 다양한 프로토콜로 이뤄진다.
우선 대략적으로 WebRTC가 위에서 말했던 프로토콜들을 아래와 같이 사용한다.
- Signalling
- Connecting
- Securing
- Communicating
조금 더 자세한 버전을 확인하고 싶다면 W3의 예시 문서를 참고 하길 권한다.
https://www.w3.org/TR/webrtc/images/ladder-2party-simple.svg
https://www.w3.org/TR/webrtc/#simple-peer-to-peer-example
각 단계별 프로토콜은 아래와 같다.
Signalling
XMLHttpRequest
long polling
WebSocket
MQTT Over WebSocket
SDP (Session Description Protocol)
Connecting
ICE (Interactive Connectivity Establishment)
Securing
DTLS (Datagram Transport Layer Security)
SRTP (Secure Real-time Transport Protocal)
Communicating
RTP (Real-time Transport Protocol)
SCTP (Stream Control Transmission Protocol)
RTCP (Real-time Transport Control Protocol)
WebRTC 주요 기술 살펴보기
SDP (Session Description Protocol)
세션 기술 프로토콜(Session Description Protocol, SDP)은 스트리밍 미디어의 초기화 인수를 기술하기 위한 포맷이다. 이 규격은 IETF의 RFC 4566로 규정되어 있다.
WEB RTC는 시그널링 서버의 구현은 별도의 제약이 없다. 따라서 Http Long polling, Web socket, MQTT, SIP등을 사용해서 자유롭게 구현이 가능하다.
WebSocket 이나 SIP등을 통해 공유 신호 채널(시그널링)을 도입 후, WebRTC 연결을 하는데 필요한 첫 단계로 SDP는 매체를 운반하지 않는 대신, 운반할 매체의 종류, 네트워크 전송 수단, 사용 코덱과 그 설정, 대역폭 정보등 메타데이터와 같은 전반적인 커넥션의 특성을 나열한 세션프로필을 설명한다. 아래와 같이 스트링을 직접 전송도 가능하고, XMPP(XML) 로 매핑하기도 한다.
https://ko.wikipedia.org/wiki/XMPP
https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/
에서 단계별로 실험을 해볼 수 있다.
자세한 정보는 크롬의 내장 WebRTC 분석도구를 통해서 확인 가능하다.
- chrome://webrtc-internals
ICE, STUN, TRUN
클라이언트는 STUN을 통해 자신의 공인 IP를 확인을 한 뒤 상대 Peer에게 본인의 공인 IP를 알려준다. 상태 Peer 또한 본인의 공인 IP 정보를 제공한다.
다만 이 Stun으로 모든 것을 해이 어려운 경우가 있는데, Client와 상대 Peer이 같은 네트워크에 존재 할 때는 이것만으로 해결이 어렵다고 한다. 또한 Symeetric NAT의 경우에도 Application이 달라지면 NAT 매핑테이블이 바뀔 수 있어 연결이 어렵다고도 한다.[3]
이런경우 TRUN을 이용하여 수집을 한다. ICE(Interactive Connectivity Establishment, RFC 5245)라는 프레임워크가 수행한다. ICE는 두개의 단말이 P2P 연결이 되도록 최적의 경로를 찾아주는 프레임워크다.
ICE 프로토콜 (RFC 5245)를 사용하면 직접연결이 어려울때는 Stun을 사용하고 그래도 실패하면 turn을 사용한다.
이렇게 클라이언트는 ICE에 사용할 Candidate(후보)를 수집한다. 각 후보는 미디어를 수신 할 수있는 잠재적 주소와 포트. 일반적으로 세 가지 유형의 후보자가 생성된다.[2]
- Host Candidate: Private IP with Port
- Server Reflex Candidate: Public IP with Port by STUN, TRUN
- Relay Candidate: Turn server IP with Port by TURN
더 친절한 도움은 아래 링크를 보자
Connection 동작 개요
각 Peer 간 연결 호 수립이 완료 되면 미디어 데이터를 주고 받는다.
이때 사용하는 프로토콜은 RTP와 RTCP가 있다.
RTP (Real-time Transport Protocol)
실시간 데이터 전송을 위한 표준 패킷형식으로 오디오, 비디오 등 실시간 데이터를 멀티캐스트나 유니캐스트로 전송하기 적합한 기능 제공
RTCP (Real-time Transport Control Protocol)
RTP 와 함께 쓰이며, QoS, 모니터링, 수신자 정보수집, 전송율 계산등을 제공
실시간 전송 프로토콜(Real-time Transport Protocol, RTP)은 IP 네트워크 상에서 오디오와 비디오를 전달하기 위한 통신 프로토콜이다. RTP는 전화, 그리고 WebRTC, 텔레비전 서비스, 웹 기반 푸시 투 토크 기능을 포함한 화상 통화 분야 등의 스트리밍 미디어를 수반하는 통신, 엔터테인먼트 시스템에 사용된다. RTP는 일반적으로 사용자 데이터그램 프로토콜(UDP)로 동작한다. RTP는 RTCP(RTP Control Protocol)와 결합하여 사용된다. RTP가 오디오/비디오와 같은 미디어 스트림을 전달하는 반면, RTCP는 전송 통계와 QoS를 모니터링하고 다중 스트림의 동기화를 도와준다.
- 별도 참고자료
WebRTC SFU Load Testing
