오랜 만에 글을 쓰는 것 같습니다.
요즘 화상채팅 동작 원리가 궁금하기도 하고 한번 구현해보면 어떨까 해서 글을 쓰게 되었습니다.
또한 현재 공부중인 학생이므로 이 글이 혹시라도 잘못된 정보가 있더라면,
댓글로 잘못된 부분을 지적해주신다면 수정하겠습니다.
앞으로 잘못된 부분을 잘 지적해주셔서 제가 올바르게 성장이 할수 있게 도와주십시오.

Webrtc를 소개하게 된 이유

최근에 실시간 화상 통화를 개발할 일이 생겼는데
"어떻게 하면 쉽게 구현할수 있을까?" 라는 생각을 하게되었다.
그래서 이것저것 블로그와 구글링을 뒤적뒤적 해본뒤 WebRTC라는 API가 있는것을 알게 되었다.

WebRTC를 알게 된 후 WebRTC Documentation을 본격적으로 공부를 하기 시작했다.
일단 제가 네트워크 구조는 별로 접해본적이 없었는데 접하게 되어서
문서를 이해하는데 꾀나 많은 시간을 투자한 것 같았다 ㅜㅜ.

제가 문서를 다 이해한뒤 혹시라도 나중에 또 안만지다 보면 까먹을 것 같아서 블로그로 정리해놓으면 좋겠다라는 생각이 들어서 정리를 하게 됬다.

WebRTC 소개

WebRTC는 (Web Real Time Communications) 라는 뜻을 가지고 있다.
한마디로 정리해 보면 Web(브라우저) RTC(실시간 통신)이라는 뜻으로
웹 브라우저에서 데이터 교환, 실시간 통화, 등을 할수 있도록 해주는 기술이다.

WebRTC의 네트워크는 기본적으로 P2P(Peer To Peer)로 되어 있다.
상황에 따라서 SFU(Selective Forwording Unit)나 MCU(Multi-point Control Unit)를 사용할 수도 있다.

WebRTC의 통신 원리

사진 출처
WebRTC 기술은 P2P 네트워크 통신하는 것에 매우 최적화 되어 있다.
WebRTC의 실시간 데이터 교환은 대체적으로 3가지 클래스에 의해서 일어난다.

MediaStream : 비디오 / 오디오 접근 권한부여
RTCPeerConnection : 네트워크 대역폭 관리 및 데이터 암호화
RTCDataChannel : 일반적인 P2P 통신

위와 같은 3가지의 객체를 통해서 실시간 데이터 교환을 이루며,
RTCPeerConnection들이 적절하게 신호를 주고 받으면서 데이터 교환을 이루는 것을
Signaling (신호 전달 서버) (이)라고 한다.

또한 데이터가 P2P로 교환 되어야 하므로 2명의 유저가 데이터를 교환해야 한다.
데이터 교환을 요청하는 콜러(Caller)와 교환을 받는 콜리(Callee)에 의해서 2명의 유저의 실시간 데이터 교환이 일어난다.

STUN, TURN 서버

Stun서버와 Turn서버는 미디어를 교환할때 방화벽 뒤에 있거나 교환이 막혔을 때 임시 중개 서버 역할을 하는 서버이다.

비디오 / 오디오의 미디어를 교환할때 방화벽 뒤에 있어서 연결이 막히는 경우가 있다.
이런 현상을 방지하기 위해서 STUN 서버가 임시 서버로 2명의 미디어스트림을 공유해주는 역할을 한다.

TURN 서버는 다른 외부 노트북으나 다른 기기로 접속하여 테스트를 할때 외부로 접속한 기기의 비디오나 오디오가 검은화면으로 나오는 경우가 있다.
그럴때 TURN서버를 이용하여 접속통로를 열어주는 것이다.
또한 STUN 서버를 사용했는데도 불구하고 연결이 안될 때 TURN 서버로 열어주면 된다.

이렇게 미디어 스트림의 공유가 예기치 못하게 막혔을 때 임시서버로 미디어 스트림을 중개해주는 역할을 하는 서버가 바로 STUN과 TURN 서버의 역할이다.

STUN과 TRUN서버 통신 과정

사진 출처

SFU와 MCU와 P2P

앞서 말했듯이 WebRTC는 P2P와 통신에 최적화 되어있다.
하지만 여러명의 사용자가 접속 해야 할 상황이 생겼을때, P2P로 연결하면 서버에 과부하가 걸리거나 접속중인 사용자 PC에게 엄청난 과부하를 줄 수가 있다.

P2P (Peer To Peer)

P2P는 1:1 연결에 적합하다.
클라이언트간에 서로 1:1로 연결을 주고 받으면서 통신한다.

P2P 통신 방식

사진 출처
이런식으로 서로 간의 1:1 통신을 각자 연결해서 사용한다.
이런 P2P 네트워크는 보통 블록체인 기술에 많이 쓰는걸로 알고있다.

장점
쉽게 구현할 수 있다.
종간단 암호화가 가능하다.
서버의 비용이 들지 않는다.

단점
서버의 과부화가 걸릴 수 있다.
1:N 연결에 적합하지 않다.

따라서 1:N, M:N 통신에 최적화 되어있는 SFU와 MCU를 사용한다.

SFU (Selective Forwording Unit)

SFU는 1:N 연결에 최적화가 되어 있다.
중앙 서버를 두고 클라이언트를 1명씩 중개해주는 역할을 한다.

SFU 통신 방식

사진 출처
이런식으로 4명의 사용자가 있다고 가정하면 중앙서버를 두고 사용자를 받아서 한명씩 클라이언트를 중개해주는 역할을 한다.

장점
P2P 보다 트래픽이 적개 발생함.
대규모 통신연결에 적합.
상황에 따른 미디어의 품질을 바꿀 수 있다.

MCU (Multi-point Control Unit)

MCU는 M:N 연결에 최적화가 되어 있다.
중앙 서버를 두고 클라이언트를 묶어서 한번에 전달하는 방식이다.

MCU 통신 방식

사진 출처
SFU와는 다르게 클라이언트가 중앙서버로 들어오고 중앙서버는 들어온 클라이언트를 묶어서 한번에 전달해준다.

장점
클라이언트의 트래픽을 줄일 수 있다.

단점
관리가 어렵다.
서버의 자원을 많이 사용한다.
한번에 묶어서 보내야 하기 때문에 미디아 품질을 일일히 다 조정해서 보내야한다.

이처럼 상황에 따라서 네트워크 방식을 변경해야 할 때도 있다.
그런 상황이 오면 SFU나 MCU를 이용해서 네트워크 구조를 변경해야 한다.

Singaling 서버

Signaling 서버는 Signal(신호) ing(전달) 이라는 뜻을 가지고 있다.
따라서 Signaling 서버는 미디아 스트림이 통신할때 오고가는 신호를 중개해주는 역할이다.
한마디로 Singaling 서버는 미디아 스트림의 신호 전달만 해주는 서버고,
별다른 처리를 하는 경우는 거의 없다.
보통 Signaling 서버는 Node.js의 Socket.io나 다른 Socket모듈로 구현 할수 있다.

사진 출처
이런식으로 2개의 Peer가 통신하기 위하여 신호를 전달해준다.

정리 하며

코로나 19로 밖에 나가지도 못하고 집에만 틀어박혀 있는 상황이 생겼다.
WebRTC를 공부하면서 그런 시간이 훌쩍 지나가버린 것 같다.
또한 WebRTC를 이렇게 정리를 해놔서 나중에 가도 쉽게 까먹지는 않을 것 같다.
이제 더 열심히 공부하여 WebRTC를 열심히 알아놔야 겠다는 생각이 들었다.
이 글을 읽는 분들도 이 글을 읽고 WebRTC가 조금이라도 더 정리가 되었으면 한다.
더 자세한 내용을 알고 싶고 공부하고 싶다면은 아래의 WebRTC 공식 문서를 참고 하길 바란다.

WebRTC 공식 문서

이상으로 WebRTC 정리를 마치겠다.