WebRTC
개요
웹 브라우저간 플러그인 도움 없이 서로 통신할 수 있도록 설계된 API이다.
주요 브라우저에서 자바스크립트 API로 제공된다.
브라우저 뿐만 아니라 다양한 플랫폼에서 사용가능하다. 실제로 Android 및 iOS에서 WebRTC 기능을 제공하는 기본 라이브러리가 존재한다.
browser - server - browser 가 아닌 browser-browser 직접 연결방식이다.
브라우저끼리 직접 연결한다고 server가 필요없는것은 아니다. 네트워크를 찾거나, 세션관리, 미디어와 관련된 메타데이터 교환도 해야하며, 사용자 방화벽 문제나 공용IP주소가 없거나, 라우터가 피어간 직접 연결을 막는 경우 피어간 연결이 되지 않을 수 있다. 다음과 같은 문제들을 해결하기 위해 서버가 필요하다.
ICE
위와 같은 문제가 발생하더라도 피어간 연결 위해 사용하는 기술이다. ICE는 STUN과 TURN서버를 사용한다.
STUN
STUN이란 피어의 공용주소를 알아내고, 피어간 직접 연결을 막는 라우터의 제한 사항을 알아내는 프로토콜을 말한다.
클라이언트는 STUN서버에 요청을 보내고 STUN서버는 클라이언트의 공용 IP주소와. 라우터의 NAT 뒤에서 액세스 가능한지 여부를 반환해 준다.
NAT
개인 디바이스에 공용 IP주소를 제공하는데 사용된다. 라우터는 공용 IP주소를 가지고 있고 이와 연결된 모든 디바이스는 개인 IP주소를 가진다. 요청 이후에는 개인 IP주소에서 유일한 포트를 가진 공용 IP주소로 변환된다. 유일한 포트를 가진 공용IP를 가지면 각 디바이스는 유일한 공용IP 없이도 인터넷 상에서 검색이 가능하다.
하지만 일부 라우터들은
디바이스와 네트워크 연결을 막는 경우도 있다.
즉, STUN서버에서 공용 IP주소를 알아내도 연결이 불가능할 수 있다는 뜻이다. 이때 TURN을 사용한다.
TURN
TURN은 Symmetric NAT(이전에 연결했던 피어들과의 연결만 허락하는 것)의 제약조건을 우회하기 위해 사용된다. 클라이언트들은 TURN서버에 패킷을 보내고, TURN서버는 이 패킷들을 포워딩한다. 당연히 오버헤드가 발생한다. 따라서 다른 방법이 없을때만 사용한다.
흐름
- SDP교환 - 서로 주고받을 미디어가 어떤 형태인지 정함
- ICE 협상 - 어떤 방식으로 통신할 것인지 정함
서버 구현방식
- P2P
서버가 통신에 관여하지 않고 클라이언트끼리 직접 연결, 4명의 인원이 P2P방식으로 통신하려면 1명은 나머지 3명과 개별적으로 연결하고 내 미디어를 3명에게 전송한다. 그리고 3명에게서 받은 미디어를 표시한다. 간단하게 구현 가능, 다수의 사용자와 연결시 사용자 PC에 부담
- SFU
클라이언트간 연결이 아닌 클라이언트-서버 연결 방식, P2P방식과 다르게 사용자는 서버만 연결하면 됨 4명의 인원이 SFU방식으로 통신하면 각각 인원이 서버와 연결하고 서버로 각자의 미디어를 보낸다 그럼 서버에는 4개의 미디어가 있을거고 서버는 각자의 미디어를 제외한 3개의 미디어를 반환한다. P2P보다 네트워크 트래픽 적음, 대규모 연결에 적합,상황에 따라 미디어 품질 조정가능, 하지만 전달되는 미디어가 많을수록 PC에 부담이됨, 전달된 모든 미디어에 디코딩 해야하기 때문
- MCU
SFU와 거의 비슷함 SFU와 다르게 서버로 전달된 모든 미디어를 믹싱해서 하나의 미디어로 만들어 사용자들에게 전달함 클라이언트 부담 감소, 하지만 미디어를 합치는 과정에서 많은자원이 소모됨
궁금증
SFU,MCU 서버를 구현할때도 ICE가 필요한가?
참고
https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols
https://www.baeldung.com/webrtc
https://doublem.org/webrtc-story-02/
