[개념]WebRTC 개념 정리

0.WebRTC(Web Real-Time Communication)이란?

인터넷 브라우저나 앱에서 플러그인 없이 오디오,비디오와 같은 데이터를 실시간으로 주고받는 통신을 가능하게 해주는 기술로 P2P방식으로 작동하여 서버에 부담이 적은 것이 특징이다.

(p2p란? Peer to Peer의 줄임말로 서버를 거치지 않고 사용자끼리 직접 데이터를 주고받는 방식을 의미(peer는 동등한 위치에 있는 상대를 뜻하는 것으로 여기서는 사용자와 사용자를 의미한다))

 

그리고 WebRTC를 구현하기 위해서는 아래 개념들을 반드시 숙지하고 있어야 한다.

 

---

1.Signaling(시그널링)

위에서 WebRTC는 P2P 방식으로 작동한다고 했다. 먼저 P2P 통신이 가능하기 위해서는 이 Signaling이란 과정을 거쳐야한다.

시그널링은 두 클라이언트가 어디서/어떻게 통신할지, 무슨 미디어를 줄지(영상인지 음성인지)에 관해 서로 시그널을 주고 받는 과정이다.

시그널링은 당연히 P2P연결이 이루어지기 전이므로 서버를 통해 이루어지는데 이 서버를 시그널링 서버라고 부른다.

그리고 이 시그널링 서버를 통하여 두 사용자 간에는 SDP(Session Descript Protocol),ICE Candidate(Interactive Connectivity Establishment)정보를 주고 받는다.

 

다시 말하면, 클라이언트 A가 클라이언트B에게 이 시그널링 서버를 통해 시그널을 보내는 것이다. 이 때 클라이언트와 시그널링 서바간에 이루어지는 통신은 웹소켓 통신이다.

(웹소켓은 요청을 주고 응답을 받는 HTTP 통신과 달리 한 번 연결되면 양방향으로 실시간 데이터를 주고받을 수 있는 통신 방식으로 시그널링 과정에서 클라이언트 간에 주고받아야할 세션 정보나 연결 제안등을 빠르고 효율적으로 전달 할 수 있다)

 

 

2.SDP(Session Description Protocol)

SDP는 세션정보,  오디오/미디어와 같은 미디어 스트림 정보가 담겨있다.
마치 클라이언트끼리 어떤 코덱을 쓸 것인지 비디오 해상도는 어떤지와 같은 설정정보를 협상(?)하는 정보이다.

클라이언트 A가 시그널링 서버를 통해 SDP offer(제안)를 보내고 클라이언트 B가 이 SDP에 대해 answer(응답)을 보내면서 양쪽이 어떠한 설정으로 미디어 데이터를 주고 받는지 정한다.

 

3.ICE Candidate(Interactive Connectivity Establishment)

ICE Candidate는 두 클라이언트 간에 어떻게 실제로 연결할지에 대한 네트워크 경로(주소,포트)에 대한 정보다.

클라이언트 A와 B는 여러가지 네트워크 경로가 될 수 있는 후보(Candidate)리스트를 시그널링 서버를 통해 주고 받는데 이 때,
WebRTC엔진이 내부적으로 각 경로후보들을 테스트하면서 가장 연결 품질이 좋은 경로를 자동으로 선택한다.

ICE Candidate에 들어가는 정보들

연결타입에 대해서 살펴보자면,

 

3-1. Host Candidate

내 로컬 IP를 통해 연결.  두 사용자가 한 집이나 오피스 등 같은 로컬 네트워크(같은 와이파이,같은 유선망)에 속한 가장 간단한 경우에 사용가능하다

 

3-2. Server Reflexive Candidate(STUN서버가 알려준 공인IP를 통해 연결하는 방식)

일반적으로 화상통화를 한다면 서로 다른 네트워크에 속해있을 것이고 이 경우에 사용가능한게 바로 이 연결타입이다. 이 타입은 서로의 공인IP와 포트를 통해 연결하는 것인데 문제는 일반적으로 클라이언트는 자신의 공인IP와 포트를 모른다.

그래서 이때 사용하는 것이 STUN(Session Traversal Utilites for NAT Server) 서버다.

(:NAT(공유기) 뒤에 있는 클라이언트의 공인 IP주소와 포트를 알아내기 위한 서버)

클라이언트는 이 STUN서버에 요청을 보내면 STUN서버는 해당 클라이언트의 공인IP주소와 포트번호를 알려준다.

이렇게 알게 된 공인IP주소와 포트번호를 상대방에게 알려주는 것이다.

따라서 우리는 WebRTC를 위해서 STUN서버도 구축해야하는데, 현실적으로 STUN서버까지 구축하는 것은 어렵다.

그래서 보통 구글이 제공하는 공용 STUN서버를 사용한다.

 

3-3.Relay Candidate(TURN 서버를 거치는 중계IP를 통해 연결하는 방식)

그런데 복잡한 NAT환경에서는 위의 STUN서버를 이용해도 연결이 불가할 때가 많다.

그럴 경우 어쩔 수 없이 클라이언트간에 P2P연결이 불가하는데, 이 때는 결국 서버가 중간에서 데이터를 대신 전달해주는 방식을 택한다. 이때 사용하는 것이 TURN서버다.

 

---

 

이렇게 두 클라이언트간에 시그널링 서버를 통해 SDP와 ICE Candidate를 주고받음으로써 P2P연결이 맺어지면,

두 클라이언트는 SRTP(Secure Real-time Transport Protocol-주로 오디오나 비디오같은 실시간 미디어 스트림 전송에 사용)프로토콜 혹은 SCTP(Stream Control Transmission Protocol-채팅,파일 같은 일반 데이터전송에 사용)프로토콜을 통해 데이터 전송을 하는 흐름으로 두 사람간의 연결과 데이터 전송이 이루어진다.

 

즉 WebRTC는 시그널링 ->P2P 연결 -> SRTP/SCTP를 통한 데이터 전송  이흐름으로 작동하게 되는 것이다.