WebRTC

WebRTC

유저간 연결 정보(SDP, ICE)를 교환하기 위해서 Signaling Server가 존재 ( 우리 프로젝트에서는 backend)

시그널링을 할때에는 WebSocket이나 XMLHttpRequest. 보통 WebSocket 사용.

1. SDP(Session Description Protocol) : A, B 간에 음성, 영상, 비디오 등 스트리밍 규약을 맞추는 과정. offer, answer 의 과정을 통해 합의.
   1. A에서 Signaling server로 A의 정보들을 보냄 (Signaling offer)
   2. Server에서 연결된 모든 클라이언트들에게 A의 정보 전달
   3. B에서 A의 정보를 활용해 연결에 필요한 일련의 작업을 하고 B의 데이터를 Server로 보낸다.(Signaling Answer)
   4. Server에서 B의 정보를 A에게 보냄 이를 통해 RTC가 A, B를 연결한다.
2. ICE : 두 단말이 서로 통신할 수 있는 최적의 경로를 찾을 수 있도록 도와주는 프레임 워크. ICE를 사용하면 NAT가 통신을 위해 필요한 모든 포트를 열어두고 두 엔드포인트 모두 다 연결할 수 있는 ip주소, 포트에 대한 완전한 정보를 갖게 된다.

STUN Server : A, B 간에 통신 중간에는 방화벽, NAT 등의 이요로 직접적인 Signaling이 불가능하다. 따라서 클라이언트 자신의 공인 IP를 알주는 서버가 필요하다. 이는 오픈소스나 구글에서 운영하는 STUN Server가 존재.(단순히 정보 제공을 위한 서버라 트래픽 발생이 현저히 낮기에 무료 STUN 써도 크게 문제가 없음)

→ 오픈 소스 or 구글에서 운영하느 server

• NAT로 인해 요청을 보낼때마다 private ip → public ip로 NAT에 바뀌기 때문에 동일한 public IP로 통신할 수 없다는 문제.

TURN Server : STUN 서버를 통해서도 연결이 불가능한 경우도 존재(보호정책이 강한 NAT, 라우터, Symmetric NAT환경). TURN 서버는 이를 대비한 간단하게 백업 서버이다. 기존 방식과 같이 TURN Server를 사용할 수 있음.

→ COTURN (오픈소스)

 

<이론 정리>

1. A, B가 Signaling Server를 통해 SDP 정보 교환.
2. A, B가 Stun Server를 통해 ICE 정보를 얻어옴.
3. Signaling Server를 통해 이를 교환.
4. 만약 여러 이유로 직접 연결이 안된다면, 최후의 방법으로 TURN Server를 사용해야함.

 

<구현>

1. client에서 video 태그, stream 등을 연결 하고 세션에 접속
2. 서버에서 세션에 접속하는 client들의 seesion ID를 List로 저장한다.
3. 그 이후에 새로운 client가 접속을 한다면, 새로운 client에게 Signaling Offer을 해준다.
4. 새로운 client는 offer을 받고 answer을 해주어야 한다.
5. 받은 offer을 이용해서 최종 signaling을 즉 p2p을 진행한다

https://terianp.tistory.com/178

 

---

 

+ 우리 프로젝트에서는 사용하지는 않지만 WebRTC에 대한 추가적인 내용.

 

Media Server의 여부에 관한 이야기

 

WebRTC는 크게 Mesh, SFU, MCU 방식이 존재.

1. Mesh : 서버의 자원이 적게 들지만 peer 수가 늘어날 수록 Client 사이드의 과부하가 급격하게 증가하는 방식.
   1. signaling server, stun, turn server를 이용한 전형적인 p2p 구현 방식
   2. 장점 : 서버 부하가 적음. p2p 이기에 실시간 성 보장
   3. 단점 : 연결된 client 수가 늘어날 수록 client의 과부하가 급격하게 증가.
2. MCU(Multi-point control unit)
   1. 다수의 송출 미디어 데이터를 media server에서 혼합 또는 가공해서 수신측으로 전달
   2. p2p방식이 아닌, server와 client간의 peer를 연결한다.
   3. media server의 매우 높은 컴퓨팅 파워가 필요.
   4. 장점 : client 부하가 크게 감소, n:m 구조에서 사용 가능
   5. 단점 : 실시간 성 저해 및 구현어려움 + 서버의 큰 자원
3. SFU(Selective Forward Unit)
   1. 각각의 client간 미디어 트래픽을 중계하는 media serve를 두는 방식
   2. p2p 방식이 아닌, server와 client 간 pper 연결
   3. 장점 : mesh 보다 느리지만 비슷한 실시간성 가능, client 부하 감소.
   4. 단점 : msh 보다는 서버 부하 늘어남, 대교모 n:m 구조에서는 여전히 clent 부하가 크다.