WebRTC

WebRTC

구글에서 만든 웹 기반 실시간 음성, 영상 통신 기술이며, P2P로 브라우저간 통신이 가능하다.

실시간성이 중요한 미디어 처리가 목적이기 때문에 빠르게 전송할 수 있는 UDP 위에서 동작한다.

 

WebRTC는 아직까지 다양한 플랫폼에 대한 표준화가 완전히 구현되지 않아 브라우저와 OS 별로 호환성과 상호 운용성이 상이하며, 각 환경(브라우저,OS) 별로 개발되는 속도의 차이가 있기 때문에 어떤 브라우저에서 지원하는지에 대한 호환성 체크를 항상 해주는 것이 중요하다.

크로스 브라우징 이슈를 해결하기 위해서는 adapter.js 라이브러리를 사용하여 해결할 수 있다.

 

 

P2P 통신 절차

1. 각 브라우저에서 P2P 커뮤니케이션에 동의
2. 통신할 대상의 주소 확인
3. 보안 사항 및 방화벽 우회
4. 미디어 데이터를 실시간으로 교환

 

NAT traversal

일반적인 사용자의 PC는 사설 IP가 할당된다. 사설 IP는 실제 존재하는 IP가 아니라 하나의 네트워크 내에서 각자를 구분하기 위한 용도이기 때문에 사설 IP로 요청을 보내도 해당 PC에 요청이 도달하지 않는다.

 

위 문제를 해결하기 위해 서버와 클라이언트가 요청을 주고 받을 때 클라이언트의 IP 주소는 라우터의 NAT에 의해 공인 IP로 변환되며, 변환된 공인 IP와 포트 번호를 이용해서 사설 IP를 찾을 수 있다.

 

즉, P2P 통신 절차 2번과 3번을 실행하기 위해서는 통신할 대상 브라우저의 공인 IP 주소와 포트 번호를 먼저 알아내야한다.

 

여기서 라우터를 통과해서 연결할 방법을 찾는 과정을 NAT traversal이라고 하는데 WebRTC에서는 STUN과 TURN 2가지 방법을 가장 많이 사용한다.

 

STUN

Session Traversal Utilities for NAT의 약자로 각 피어가 서버에 요청을 보내면 서버가 피어에게 피어 본인의 공인 IP와 포트 정보를 반환한다.

P2P 통신을 진행할 각 피어에서 본인의 공인 IP와 포트 번호를 확인한 다음 서로의 IP와 포트를 중앙 서버(시그널링 서버)를 통해 파악한 후 통신을 진행한다.

만약 N:N 통신이라면 Peer A가 B, C, D ... 의 주소 정보를 모두 가지고 있어야한다.

 

 

TURN

STUN을 사용하더라도 라우터의 방화벽 정책에 따라 자신의 공인 IP와 포트 정보를 찾지 못할 수 있다. 

또는 symmetric NAT를 사용해서 목적지 마다 다른 IP와 포트로 매핑하는 경우 서버에서 받은 공인 IP로는 피어 간 통신이 불가능하다.

 

TURN은 Traversal Using Relay NAT의 약자로 위와 같은 상황에서 사용한다.

중개 서버를 이용하는 방식으로 클라이언트가 TURN 서버에 데이터를 보내고 서버가 다른 클라이언트에게 전달하는 방식으로 피어간 통신이 아니기 때문에 P2P 방식이 아니며, STUN만 사용하는 방식 보다 느리고 부하가 크다.

 

하지만 대칭 NAT 문제를 해결하고 방화벽의 경우에도 대배분 클라이언트가 외부 서버(공인 IP를 가진)에 연결하는 것을 허용하기 때문에 피어간 통신에서 방화벽에 막히는 문제를 해결할 수 있다.

 

 

 

 

ICE와 Candidate

STUN, TURN 서버를 이용해서 획득했던 IP, 포트, 프로토콜의 조합으로 구성된 연결 가능한 네트워크 주소들을 Candidate(후보)라고 부르며, Candidate는 자신의 사설 IP와 포트, 자신의 공인 IP와 포트 정보를 가지게 되고, TURN 방식의 경우 TURN 서버의 IP와 포트 정보를 추가로 가진다.

 

Candidate는 ICE(Interactive Connectivity Establishment)라는 P2P 연결을 하기 위한 피어 간의 최적의 경로를 찾아주는 프레임워크를 통해 찾을 수 있다.

 

즉, ICE 프레임워크가 STUN, TURN 서버를 이용해서 상대방과 연결 가능한 후보들을 갖고 있다.

 

 

 

 

SDP

Session Description Protocol의 약자로 WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 정보를 설명하기 위한 프로토콜이다.

SDP는 Pub/Sub와 유사한 Offer/Answer 모델을 사용하는데 어떤 피어가 미디어 스트림 교환을 제안하면 상대방으로부터 응답을 기다리는 방식이다.

 

응답을 받게되면 ICE 후보 중에서 최적의 경로를 결정하고 협상하는 프로세스가 발생하여, 수집한 ICE 후보들로 패킷을 보내 가장 지연 시간이 적고 안정적인 경로를 찾으면, 기본적으로 필요한 메타 데이터와 IP 주소 및 포트 미디어 정보와 피어 간 합의가 완료된다.

이후 피어 간 스트림을 통해 데이터를 양방향으로 전송한다.

 

 

Trickle ICE

각 피어는 ICE 후보들을 수집해서 그 목록을 완성한 후 한꺼번에 교환하게 된다.

이 방식은 SDP의 제안 응답 모델과 함께 사용되면서 단점으로 작용하게 되는데 후보를 모으는 것도 제안 응답 과정이 발생해서 오래걸리고, 네트워크 환경에 따라 예상치 못한 지연이 발생할 수도 있다.

그리고 ICE는 동기 방식이기 때문에 한쪽 피어에서 후보 수집 작업이 진행 중이라면 SDP에서 제안을 받아도 수집 작업을 끝내야 응답을 보낸다. 

이러한 문제를 해결하기 위해서 각 작업을 병렬 프로세스로 수행하는 비동기 ICE가 바로 Trickle ICE이다.

 

 

 

시그널링

SDP, ICE, NAT traversal의 모든 과정을 시그널링이라고 한다.

NAT traversal은 WebRTC의 스펙이 아니다. 따라서 시그널링 또한 WebRTC의 스펙이 아니기 때문에 정해진 방법은 없다.

시그널링 서버 구현 방법 예시

 

 

 

 

Refer.

https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html#%EB%B0%A9%ED%99%94%EB%B2%BD%EA%B3%BC-nat-%ED%8A%B8%EB%9E%98%EB%B2%84%EC%85%9C

WebRTC는 어떻게 실시간으로 데이터를 교환할 수 있을까? - 재그지그의 개발 블로그

https://www.liveswitch.io/blog/webrtc-nat-traversal-methods-a-case-for-embedded-turn

WebRTC NAT Traversal Methods: A Case for Embedded TURN