Webrtc
드라이버나 플러그인 설치 없이 웹 브라우저 간 P2P 연결을 통해 데이터 교환을 가능하게 하는 기술
webrtc-adapter
- Webrtc가 브라우저와 운영체제 별로 호환성과 상호 운용성이 상이
- 크로스브라우징 이슈 해결하기 위해 webrtc-adpter 라이브러리 사용
WebRTC API
- MediaStream : 사용자의 카메라 혹은 마이크 등 input 기기의 데이터 스트림에 접근한다.
- RTCPeerConnection: 암호화/ 대역폭 관리 기능. 오디오 / 비디오 연결을 한다.
- RTCDataChannel: 일반적인 데이터 P2P 통신
P2P 절차
- 각 브라우저가 P2P 커뮤니케이션에 동의
- 서로의 주소를 공유
- 보안 사항 및 방화벽 우회
- 멀티미디어 데이터를 실시간으로 교환
NAT 트래버셜
라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어 있을 수도 있음. 이처럼 라우터를 통과해서 연결할 방법을 찾는 과정을 NAT 트래버셜이라 함
STUN, TURN
STUN, TURN 서버를 통해 NAT 트래버셜 작업이 이루어짐
STUN 방식은 단말이 자신의 공인 IP 주소와 포트를 확인하는 과정에 대한 프로토콜. 즉, STUN 서버는 인터넷의 복잡한 주소들 속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환. 즉, WebRTC 연결을 시작하기 전에 STUN 서버를 향해 요청을 보내면, STUN 서버는 NAT 뒤에 있는 피어(Peer)들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아줌
라우터들은 방화벽 정책을 달리 할 수도 있고, 이전에 연결된 적이 있는 네트워크만 연결할 수 있게 제한을 걸기도 함(Symmetric NAT). 이 때문에 STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우, TURN(Traversal Using Relay NAT) 서버를 대안
TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 것. TURN 방식은 중간에 서버를 한 번 거치기 때문에, 엄밀히 이야기하자면 P2P 통신이 아니게 되며 그 구조상 지연이 필연적으로 발생
보안 정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이기 때문에, TURN 방식은 최후의 수단
Symmetric NAT : 목적지에 따라서 같은 private IP 의 노드를 다른 공인 IP 와 포트로 매핑해준다. 이런 경우 라우터는 이전에 연결했던 기기에서의 연결만 허용한다.
ICE와 Candidate
STUN, TURN 서버를 이용해서 획득했던 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소들을 후보(Candidate)라고 부릅니다. 그리고 이 과정을 후보 찾기(Finding Candidate)라고 함.
후보들을 수집하면 일반적으로 3개의 주소를 얻게 됩니다.
- 자신의 사설 IP와 포트 넘버
- 자신의 공인 IP와 포트 넘버 (STUN, TURN 서버로부터 획득 가능)
- TURN 서버의 IP와 포트 넘버 (TURN 서버로부터 획득 가능)
모든 과정은 ICE(Interactive Connectivity Establishment)라는 프레임워크 위에서 이루어집니다. ICE는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크
지금까지의 내용을 요약하자면, ICE 프레임워크가 STUN, 또는 TURN 서버를 이용해 상대방과 연결 가능한 후보들을 갖고 있다는 것입니다. 그러니까 두 브라우저가 P2P 통신을 위해 통신할 수 있는 주소만큼은 확실하게 알아낸 셈입니다. 따라서 마지막으로 남은 것은 이제 미디어와 관련된 정보를 교환
SDP
SDP(Session Description Protocol)는 WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜
미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 제안 응답 모델(Offer/Answer)을 갖고 있습니다. 그러니까 어떤 피어가 이러한 미디어 스트림을 교환할 것이라고 제안 을 하면, 상대방으로부터 응답 이 오기를 기다린다는 의미
응답 을 받게 되면, 각자의 피어가 수집한 ICE 후보 중에서 최적의 경로를 결정하고 협상하는 프로세스가 발생. 최적의 ICE 후보가 선택되면, 기본적으로 필요한 모든 메타 데이터와 IP 주소 및 포트, 미디어 정보가 피어 간 합의가 완료
이 과정에서 NAT의 보안 이슈 등으로 최선의 ICE 후보를 찾지 못할 수도 있기 때문에, 이때에는 폴백으로 세팅한 TURN 서버를 P2P 대용으로 설정
통신에 TURN 폴백을 사용할 때 각 피어는 굳이 귀찮게 P2P로 데이터를 연결하고 전송하는 방법을 알 필요가 없습니다. 대신, 통신 세션 중에 실시간 멀티미디어 데이터를 중개하는 공용 TURN 서버를 알고 있어야 합니다.
json으로 보고 싶으면 별도 라이브러리(sdp-transform) 사용
Trickle ICE
ICE 프레임워크를 설정하다보면 Trickle ICE 옵션을 볼 수 있음.
일반적으로 각 피어는 ICE 후보들을 수집해서 그 목록을 완성한 후 한꺼번에 교환하게 됩니다. 하지만 이러한 방식은 SDP의 제안 응답 모델과 맞물리면서 단점으로 작용
후보를 모으는 데에도 시간이 오래 걸리고, 그 과정에서 네트워크 환경에 따라 지연이 걸릴 수 있습니다. 또한 한 쪽 피어의 ICE 후보 수집 작업이 완료되어야만 다른 피어가 ICE 후보를 모을 수 있기 때문에 비효율적
비효율적인 후보 교환 작업을 병렬 프로세스로 수행할 수 있게 만드는 것이 바로 Trickle ICE
Trickle 옵션이 활성화된 ICE 프레임워크는 각 피어에서 ICE 후보를 찾아내는 그 즉시 교환을 시작합니다. 그래서 상호 간 연결 가능한 ICE를 보다 빨리 찾아낼 수 있죠. 이러한 옵션 덕분에 ICE 프레임워크는 피어 간의 연결 상태를 체크함과 동시에 연결에 걸리는 시간을 최적화
두 개의 장치를 연결할 수 있는 시그널링 서버를 직접 구축하거나, 시그널링 서버를 제공해주는 외부 솔루션을 적용할 수 있습니다.
만약 시그널링 서버를 직접 구축한다면 웹 소켓(Web Socket)이나 서버 전송 이벤트(Server-sent Event) 방법을 적용할 수 있습니다. 시그널링 정보를 조회할 수 있는 API를 만든 후 브라우저 단에서 주기적으로 XHR을 요청하는 폴링(polling) 기법을 쓸 수도 있죠.
시그널링
위에서 이야기한 모든 과정을 일컬어 시그널링(Signaling)이라고 부릅니다. 즉 RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정을 의미
시그널링은 WebRTC 자체에서 지원하는 기능이 아닙니다. WebRTC 연결 전 미리 준비해야 하는 과정입니다. WebRTC 자체의 스펙도 아니기 때문에, 한 가지로 딱 정해진 방법이 없습니다. 정해진 방법이 없는 이유는 알 수 없는 두 장치가 언제 어떤 방식으로 연결될 수 있는지의 모든 경우를 예측하는 것이 불가능하기 때문입니다. 그래서 개발자는 자신에게 맞는 최적의 방법을 선택적으로 적용할 수 있죠.
Webrtc 한계
- 브라우저 간 호환성 입니다. 아직 adapter.js 같은 라이브러리 없이는 다양한 브라우저의 호환성을 장담할 수 없습니다. 특히 사파리와 IE, 엣지
- 시그널링 서버에 대한 명시적인 표준 없음. 진입장벽 높음
- 실시간성이 매우 중요하기 때문에 UDP 위에서 동작, 데이터 손실이 발생할 수도 있죠. 비디오라던가 오디오에 있어서 몇 프레임 정도가 끊기는 것은 큰 문제가 되지 않지만, 중요한 파일들을 전송할 때에는 이 데이터 손실이 문제를 일으킬 수도 있음.(TCP 방식을 사용할 수도 있지만 UDP를 사용할 수 없거나 미디어 스트리밍에 적합하지 않은 방식으로 제한되는 경우에만 사용되고, 모든 브라우저가 TCP 방식을 지원하는 것도 아닙니다.)
동작순서 및 프로토콜
- Signaling
- SDP (Session Description Protocol)
- Connecting
- ICE (Interactive Connectivity Establishment)
- Securing
Singaling 과정중 certificate 생성 후 교환 -> 서로 교환한 certificate를 복호화해서 확인 -> 해커가 가로채도 복호화 불가
- DTLS (Datagram Transport Layer Security)
- RTP 제외한 데이터 암호화 프로토콜 - SRTP (Secure Real-time Transport Protocol)
- RTP 데이터 암호화 프로토콜
- DTLS (Datagram Transport Layer Security)
- Communicating
- RTP (Real-time transport Protocol)
- RTCP (Real-time Transort Control Protocol)
- 미디어, 오디오, screen sharing 할 때만 사용- 전송하는 Stream format을 RTP라 함
- video call을 진해 중인 상황에서 상대방이 말할 때 나는 침묵하니 침묵 데이터를 상대에게 전달할 필요 없으니 대역폭을 낭비하지 않게 조절하는 것을 RTCP라 함
- SCTP (Stream Control Transmission Protocol)
- 오디오, 비디오를 제와한 나머지 데이터 통신 (File sharing / text message / game 관련)- 데이터를 chunk 단위로 채널에 전송
스트리밍 그리고 통신(MCU, SFU)
- P2P
- 중앙 미디어 서버 없이 종단 간 직접 연결
- peer 수가 증가할수록 개별 기기의 높은 성능을 요구한다. 1:1, 최소한 소규모 미디어 교환에 적합
- MCU (Multipoint Control Unit)
- 한쪽 Peer에 서버를 두고, 들어오는 트래픽을 서버에서 믹싱해서 다시 내보내는 방식
- 클라이언트와 네트워크의 부담이 줄어드는 반면, 중앙서버의 컴퓨팅 파워가 많이 요구
- 낡은 기술이고 + 서버 운용 비용이 높아, WebRTC와 같은 실시간성 보장이 우선인 서비스인 경우 장점이 상쇄
- SFU (Selective Forwarding Unit)
- 믹싱하지않고 트래픽을 선별적으로 배분해서 보내주는 방식
- 각 peer 연결 할당과 encrypt / decrypt 역할을 서버가 담당한다. 1:N 스트리밍 구조에 적합
참고
