WebRTC란?

출처: https://aal-izz-well.tistory.com/entry/WEBRTC-%EA%B3%B5%EB%B6%80%ED%95%9C-%EA%B2%83-%EC%A0%95%EB%A6%AC

 

 -웹 어플리케이션 및 사이트들이 별도의 소프트웨어나 플러그인 중간자(서버) 없이 음성, 영상 미디어 혹은

텍스트, 파일 같은 데이터를 브라우저끼리 주고받을 수 있게 만든 기술

 

-P2P연결에 최적화 되어있고 P2P 방식으로 구현할 시 별도의 서버를 거치치 않고 바로 영상스트리밍을 제공하기

때문에 속도가 빠르다 

 

-P2P연결 방식의 단점인 보안상에 취약점을 HTTPS를 강제함으로써 보안을 보장했음.

(자바 스크립트 WebRTC API만 HTTPS가 강제됨) 

사용하는 이유

-예전에 상용화된 스트리밍 방식인 HTML5의 보안상의 취약점과 호환성  그리고 사용자에게 거부감이 느껴지게 하는

덕지덕지 설치되는 active-x나 Flash형 도구들의 문제를 해결하기 위해 별도의 플러그인 없이

실시간 음성, 화상채팅 데이터 교환까지도 가능하도록 하기위해서 사용하고 있습니다.

(위의 기존의 상용화된 스트리밍 방식의 문제점들은 구체적인 부분은 나중에 더 공부해서 정리하겠습니다)

WebRTC 통신 원리

 

 

P2P 방식으로 WEB RTC 구현절차

1)각 웹(앱)어플리케이션이 P2P 커뮤니케이션에 동의

2)서로가 주소를 공유

3)보상 사항 및 방화벽 우회

4)멀티미디어 데이터를 실시간으로 교환

 

-여기에서 우리는 2번과 3번 단계의 경우 웹(앱)어플리케이션은 서버가 아니여서 외부에서 접근할 수 있는 주소가 없기 때문에 통신 설정 초기에는 중재자서버(시그널링 서버)가 필요하다

 

시그널링

-웹이나 앱 어플리케이션간에 스트리밍 데이터를 교환하기 위해 

-서로다른 네트워크에 있는 2개의 디바이스 혹은 웹 브라우저들을 통신하기 위해서는 ICE 교환과 SDP 교환이 필요합니다. 프로세스(과정)를 시그널링 이라 부르고 각 디바이스(웹 브라우저)들을 상호간에 동의된 서버(Socket.io 혹은 WebSocket 혹은 구글에서 제공하는 서버)에 연결시키고 이 때  상호간에 동의된 서버를 시그널링 서버 합니다.

 

 

방화벽과 NAT 트래버셜 & 라우터

-일반적으로는 라우터가 NAT 역할을 합니다 외부에서 접근하는 공인 IP와 포트 번호를 확인하여 현재

네트워크 내의 사설 IP들을 적절히 매핑시켜준다. 그러므로 어떤 앱(웹)애플리케이션 두개가 서로 직접 통신을

하기 위해선 각자 라우터의 연결된 공인 IP주소와 포트번호를 먼저 알아내야 한다.

 

하지만 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어있을 수 있다. 

이 라우터를 통과해서 연결할 방법을 찾는 과정을  NAT 트래버셜(NAT traversal)이라고 한다.

 

STUN & TURN

1)STUN

-NAT 트래버셜 작업은  STUN(Session Traversal Utillities For NAT) 서버에 의해 이루어진다.

STUN 방식은 단말이 자신의 공인 IP 주소  포트를 확인하는 과정에 대한 프로토콜이다.

-STUN 서버는 인터넷의 복잡한 주소들 속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환해준다.

-STUN서버에 요청을 보내면 STUN서버는 NAT 뒤에 있는 피어들이 서로 연결할 수 있는 공인 IP주소와 

포트 번호를 찾아준다.

EX)다른 사람이 우리집에 찾아올 수 있도록 사전에 우리집 주소를 조회해서 알아내는 것과 비슷하다.

 

2)TURN

-STUN 서버를 사용하더라도 라우터의 방화벽 정책이나 이전에 연결된 적이 있는 네트워크만 연결 할 수 있게 제한이 걸려 있는 경우에 의해 STUN서버를 통해 자기 자신의 주소를 찾아내지 못한 경우 TURN 서버를 대안으로 이용하게 된다.

-TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 것이다.

-TURN 방식은 중간에 서버를 한번 거치기 때문에 엄밀히 이야기하면 P2P 통신이 아니게 되며 그 구조상 

지연이 필연적으로 발생하게 되어서 TURN 방식은 최후의 수단으로 주로 선택된다.

 

Candidate와 ICE 

 

STUN과 TURN 서버를 이용해 획득했던 IP주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한

네트워크 정보들을 Candidate(후보)라고 한다.

 

-후보를 수집하면 일반적으로 3개의 주소를 얻게됩니다.

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

이 모든 과정을 ICE라는 프레임워크에서 이루어집니다.

ICE는 두 개의 단말이 P2P연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크입니다.

 

SDP(Session Description Protocol)

SDP 사진을 보면 나의 ICE후보가 보인다.

-스트리밍 미디어의 해상도나 형식, 코덱등의 멀티미디어 컨텐츠의 초기 세팅정보를 설정하기 위해 채택한 프로토콜

-발행구독모델과 유사한 제안 응답 모델을 갖고 있습니다.

    -어떤 피어가 이러한 미디어 스트림을 교환할 것이라고 제안을 하면 상대방으로부터 응답이 오기를 기다린다는 의미입니다. (소켓 통신의 Listen, accept와 비슷함)

-그렇게 응답을 받으면 각자의 피어가 수집한 ICE 후보중에 최적의 경로가 있는 ICE 후보를 선택

-그 후 각 피어가 로컬 데이터 스트림의 엔드포인트(도착지)가 생성되며 이 데이터는 양방향 통신 기술을 사용하여 양방향으로 전송된다.

 

이 과정에서 NAT의 보안 이슈 등으로 최선의 ICE 후보를 찾지 못할 수도 있기 때문에, 이때에는 폴백으로 세팅한 TURN 서버를 P2P 대용으로 설정합니다.

통신에 TURN 폴백을 사용할 때 각 피어는 굳이 귀찮게 P2P로 데이터를 연결하고 전송하는 방법을 알 필요가 없습니다. 대신, 통신 세션 중에 실시간 멀티미디어 데이터를 중개하는 공용 TURN 서버를 알고 있어야 합니다.

 

SDP 교환 및 ICE 교환 과정 예시

1)Alice는 offer를 생성한다.

2)Alice는 생성한 offer를 LocalDescription에 등록한다.

3)Alice는 생성한 Offer를 Bob에게 보낸다.

4)Bob은 받은 Offer를 RemoteDescription에 등록한다.

5)Bob은 answer를 생성한다.

6)Bob은 생성한 answer를 LocalDescrition에 등록한다.

7)Bob은 생성한 answer를 Alice에게 보낸다.

8)Alice는 Bob에게 받은 answer를 RemoteDescription에 등록한다.

9)Alice는 Bob은 시그널링 서버를 통해 각자의 ICE Candidates를 전송한다.

10)그리고 Alice와 Bob은 각자 수신받은 ICE Candidate을 addIceCandidate 함수를 호출하여 상대방의 ICE Candidate을

네트워크 정보에 추가한다.

 

 

참고

https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html