내가 이해한 WebRTC

Jason Moon·2022년 7월 12일
3

프로젝트에 WebRTC 기술을 사용하기 때문에 WebRTC에 대해 찾아봤다. 처음보는 용어들이 많이 나와서 개념을 이해하는데 조금 시간이 걸렸다. 아래 내용도 간략하게 설명하는 것이여서 깊이 들어가면 더 공부해야 할게 많다. 우선 이해한 것 까지만 정리하고자 한다.

WebRTC

브라우저 또는 어플리케이션간에 peer-to-peer 커뮤니케이션을 가능하게 해주는 오픈소스 프로젝트이다.

WebRTC를 이용해 플러그인이나 프레임워크 없이 비디오, 오디오 또는 텍스트 등의 데이터를 웹에서 교환할 수 있다.

왜 WebRTC를 사용할까?

WebRTC를 이용하지 않으면 아래와 같이 두 사람이 커뮤니케이션 하려면 서버를 통해서 소통해야 했다.

서버를 통해서 데이터를 주고 받다 보면 비디오, 음성 채팅의 경우 서버가 무거운 작업을 해야한다. 그리고 다수의 클라이언트가 서버를 이용하는데 그렇게 되면 서버 과부화 및 비용도 많이 들게 된다.

아래와 같이 서버를 통하지 않고 직접 통신할 수 있으면 위의 문제를 해결 할 수 있다. 이런 이유 때문에 Peer to Peer연결 이 되는 WebRTC를 사용한다.

WebRTC 동작 원리

먼저 큰 흐름을 보고 가자

A와 B가 어떻게 통신을 하는지 이해하기 위해서는 먼저 Signaling server, STUN server, TURN server에 대해서 알고 있어야한다.

Signaling server

유저 간 연결을 하기위해 요구되는 정보들을 교환하도록 도와준다. 위 그림에서 SDP, ICE등의 정보를 교환하는데 사용된다.(우리 프로젝트에서 백엔드 서버)

시그널링을 할 때 WebSocket 또는 XMLHttpRequest등을 사용할 수 있다.(우리 프로젝트에서는 WebSocket 사용)

SDP는 간략하게 설명하면 A와 B간의 음성,영상, 비디오 등 스트리밍 규약을 맞추는 과정이라고 보면 된다. 위 그림에서 offer, answer이 있는데 말 그대로 서로 협의하는 과정이다. 제안하고 제안에 응답하고 하면서 RTP프로토콜(실시간 음성, 영상 및 데이터를 IP 네트워크로 전송하는 표준 프로토콜)에 대한 세부적인 내용을 협상한다.

ICE 는 A와 B가 서로 통신 할 수 있는 최적의 경로를 찾을 수 있도록 도와주는 프레임워크이다. ICE는 STUN sever로 확보 된 통신 가능한 여러 IP주소와 포트 넘버를 SDP offer과 SDP Answer를 통해 상대방에게 전달한다. A 와 B는 확보된 모든 주소(Candidates)에 대해 Peer to Peer 연결성 테스트를 진행하고 통신 가능한 주소로 RTP 미디어 스트림을 송수신한다.

STUN server

위의 ICE에 대한 정보를 주는 곳이 STUN server이다. A가 B와 직접통신하기 위해서는 public IP주소를 알아야한다. 보통 우리는 아래 그림과 같이 공인IP주소 부족 또는 보안 문제로 각각의 기기들은 라우터를 통해 private IP 주소를 사용한다. 각각의 기기들은 개인 IP주소만 알 뿐 공용 IP주소를 모른다.

아래 그림과 같이 STUN server을 통해 공용 IP 주소, NAT타입, 포트정보 등(ICE Candidates)을 알 수 있다.

이렇게 알게 된 정보(ICE Candidates)를 Signaling server을 통해 교환한다.

TURN server

TURN server는 간략하게 이야기 하면 백업 서버라고 할 수 있다. 여러가지 이유로 직접통신(peer to peer)이 실패했을 때 사용할 수 있는 server이다. 기존 서버를 통해 데이터를 주고 받는 방식 처럼 TURN server를 이용할 수 있다.

정리

위의 그림을 보며 마지막으로 정리해보자면 John과 Kate가 WebRTC를 통해 연결하고자 한다면 STUN server에 요청해 ICE Candidates(public IP 등)에 관한 정보를 받고 Signaling server를 통해 SDP를 협의(offer, answer)하고 ICE Candidates를 주고 받으며 연결하기 위한 최적의 Candidate(주소)을 찾으면 이제 연결을 시작한다.

그럼 이제 직접연결(Peer to Peer)이 돼서 서버를 통하지 않고 데이터를 주고 받을 수 있다.

만약 여러가지 이유(이건 더 찾아봐야함, 보안 등으로 STUN server에서 public IP를 못받을 수도 있고 다양함) 직접 연결에 실패할 경우 아래와 같이 TURN server을 이용한다.

우리 프로젝트를 위한 추가 설명

STUN, TURN 서버

STUN서버와 TURN서버는 오픈 소스를 통해 가져와 쓸 수 있다. STUN서버와 TURN 서버를 어떻게 구축할 지 아직 잘 모르겠어서 오픈 소스를 가져와 쓰지만 여유가 된다면 서버 구축도 직접해볼 수도 있다.

오픈 소스를 쓰면 안좋은 점은 언제 서버가 닫힐 지 모르고 어떻게 작동하는지 이해하지 못하니 에러가 발생해도 원인을 알 수가 없는 문제가 있다.

왜 채팅에는 Socket io를 쓰기로 했나

WebRTC를 이용하면 비디오, 오디오 데이터 뿐 아니라 텍스트도 주고 받을 수 있어 서버로 채팅 데이터를 보내지 않아도 직접 연결로 채팅할 수 있다. 그런데 위에서 설명한 거 처럼 현재 STUN, TURN서버를 오픈소스를 사용하고 있고 WebRTC 연결에서 문제가 발생했을 경우 화상통화는 안되더라도 채팅으로 소통 가능하도록 Socket io를 선택했다.

profile
어려워 보여도 시간을 들여서 해보면 누구나 할 수 있는 일이다

0개의 댓글