WebRTC 동작원리 및 나의 생각

오늘은 WebRTC에 대한 동작원리를 제가 아는 만큼 설명을 해보겠습니다 . 

 

 

Webrtc란 별도의 소프트웨어 도움이 없이 음성 , 영상 미디어, 텍스트 ,파일 데이터를 주고받을 수 있게 하는 기술이다.

다시말하자면 어떤 플러그인(상업회사에서 개발되어 배포되는 소프트웨어 (ex adobe flash, window media player)

필요없이 음성채팅, 화상채팅, 데이터 교환이 가능하다. 라고 생각하시면 되겠습니다. 

 

WebRTC는 P2P통신을 하기위해 적합한 기술인데요 

이유로는 WebRTC가 여러 API를 제공해주기 때문입니다.

 

MediaStream : 사용자의 카메라 혹은 마이크 등 input 기기의 데이터 스트림에 접근한다.

RTCPeerConnection : peer간 안정적이고 효율적인 통신 설정하고 관리해줌 

등등

 

/* 

webRTC 연결방식에는 P2P, SFU,MCU 방식이 있는데 

저는 P2P 방식으로 사용하였습니다. 

SFU, MCU 방식은 대규모 서비스에 적합하며 중간에 미디어서버를 두고 연결을 한다고만 알고있습니다.

*/

 

 

먼저 P2P가 무엇인지 알아보도록 하겠습니다 . 

쉽게말하자면 클라이언트나 서버의 개념이 없이 디바이스와 다른 디바이스 간 직접적인 통신을 통해 디지털 자원(CPU, 파일 등)을 공유하는 기술.

 

즉. 디바이스 자체가 클라이언트와 서버가 되어 직접적으로 데이터를 주고받는 것 이라고 생각하면 되겠습니다.  

 

 

WebRTC 기술을통해 P2P가 이루어지는 과정으로는

1.서로의 주소를 공유

2.보안 사항 및 방화벽 우회

3.데이터를 실시간으로 교환

 

1,2번의 과정을 '시그널링' 이라고한다 . 이 시그널링을 하기위해서는 중간 역할을 해주는 서버가 필요하다

 

 

/*

여기서 잠깐 의문점이 있습니다 . P2P통신은 별도의 서버개념이 필요없다고했는데 WebRTC는 P2P통신을 하기위해 서버가 필요하다고 하고있습니다. 뭔가 좀 이상하지 않으신가요?? 

이유는 바로 P2P통신을 하기위한 조건 때문입니다 .

 

P2P 통신을 하기위한 조건으로는

 

1. 기기의 스트리밍 오디오 / 비디오 / 데이터를 가져올 수 있을 것

2. 소통하고자 하는 기기의 IP 주소와 포트 등 네트워크 데이터가 필요 (NAT , Stun , Turn 서버 )

3. 에러 보고, 세션 초기화를 위해 신호 통신을 관리해야 함

4. 서로 소통할 수 있는 해상도인지, 코덱은 맞는지 capability 정보 교환(SDP)

5. 실제 연결을 맺음 (ICE)

6. 이후 스트리밍 오디오 / 비디오 / 데이터를 주고 받을 수 있어야 함.

 

결론

P2P통신을 하기위한 조건을 충족시켜주기 위해서 서버가 필요하다고 저는 생각을 합니다 .

*/

 

 

그럼 다음으로는 서버에서 일어나는 '시그널링'에 대해서 말해보도록 하겠습니다. 

 

서버에서 일어나는일 첫번째로는 

1. NAT (Network Address Translation)

 

P2P연결을 하려면 서로의 IP를 알아야 합니다. 하지만 개인과 개인의 IP를 그대로 노출하게 되면 외부 공격(해킹)에 노출이 되기 쉽기때문에 자신의 개인 IP를 노출하는대신 공인 IP를 외부에 노출한다.

쉽게말하면 개인 IP를 공인 IP로 변환하여 서버에 노출하는 것 입니다.

(이 기능을 대체로 라우터(공유기의 IP 주소, 와이파이) 에서 처리하는 경우가 많다.)

이 과정을 한 다음 공인 IP를 STUN이나 TURN 서버로 내보내게 된다.

 

 

밑에 그림을 참조하세요 (그림의 INTERNET 은 서버 , HOST는 Strun 서버라고 생각하시면 됩니다 . )

 

이 과정을 거친 다음에 Stun 서버에서는 받은 공인 IP를 가지고 개인을 식별할 수 있는 IP로 바꾸고 연결가능한 프로토콜, 포트 등을 다시 사용자에게 전달을 해줍니다 . 

아래 그림을 참조하세요. (빨간줄을 보시면 되곘습니다 . 파란줄은 ICE를 설명할 때 말하도록 하겠습니다 . )

 

/*

Turn 서버 

일반적으로 TURN서버는 STUN 프로토콜로 자신의 정보를 알아낼 수 없을 때 TURN서버를 사용한다.

 

보호정책이 강한 NAT나 라우터(특정 주소나 포트와의 연결을차단하는 방화벽 설정 되어있는 경우)를 사용할 경우 STUN 프로토콜로 연결이 불가능하기때문에 TURN 서버를 사용한다

(Turn 서버는 사용해본적이 없기때문에 여기서 pass하겠습니다 . 죄송합니다)

*/

 

어쨋든 이렇게 STUN, TURN 서버를 이용해서 획득했던 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소들을 후보(Candidate)라고 부르게 됩니다 .

 

제일 중요한 것은 이 모든것들이  ICE라는 프레임워크 위에서 이루어지게 된다는 겁니다. 

 

/*

ICE (Interactive Connectivity Establishment) 프레임워크란 무엇인가?

STUN ,TURN 서버를 통해 획득한 정보와 개인 정보

 

자신의 사설 IP와 포트 넘버(원래 디바이스에서 가지고있음)

자신의 공인 IP와 포트 넘버 (STUN, TURN 서버로부터 획득 가능)

TURN 서버의 IP와 포트 넘버 (TURN 서버로부터 획득 가능)

 

위의 정보들을 ICE가 가지고 있다가 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크 입니다.

*/

 

아까 넘어갔던 파란색 선을 생각하시면 되겠습니다 .

 

 

여기까지의 과정이 P2P 통신을 하여서 미디어 관련된 정보를 교환할 수 있는 기반이 형성이 된다고 볼 수 있겠습니다 .

 

그 다음으로는 이제 SDP 를 교환 해야겠죠??? 

 

/*

SDP(Session Description Protocol)란?

WebRTC에서 스트리밍 미디어의 해상도나 형식,코덱 등의 멀티미디어 컨텐츠의 초기 설정을 설명하기 위해 채택한 프로토콜이다 .

 

한 마디로 서로 어떤 데이터를 교환할것인가에대한 설정 합의를 보는 과정입니다. 

*/

 

이 SDP를 어떻게 정하냐면 제안 응답 모델(Offer/Answer) 으로 정하는데 Offer가 제안을하면 Answer가 승낙을 하게되고

Offer가 수락을 받게되면 ICE 프레임워크를 통하여서 두 Peer를 연결하게되고 서로간의 합의가 완료되어 데이터 교환을 할수있게된다 .

 

번외로 제가 궁금해서 찍어본 로그 . 

 

저는 WebRTC에 동작원리도 모른체 되기만하는 코드를 가져왔는데 이번에 정리도하고 공부도 해보니까 이런 동작원리가 있었구나 다시 생각해보게되었습니다. 

여기까지가 제가 공부한 WebRTC 공부입니다 . 부족한점은 댓글 남겨주세요 .