WebRTC란? (+P2P, SFU, MCU 동작과정)

이전 시간에 라이브 스트리밍 프로토콜에 대하여 알아보고 RTMP와 HLS 그리고 WebRTC에 대해 간략하게 알아보고 비교 분석하여 화상회의 소프트웨어에 WebRTC를 사용하기로 결론지었습니다.

 

비교글을 보고 싶다면 다음을 참조하세요

https://junuuu.tistory.com/377?category=1014988 

라이브 스트리밍 프로토콜 비교(RTMP vs HLS vs WebRTC)

 

지금부터는 WebRTC에 대해 조금 더 깊게 알아보도록 하겠습니다.

 

WebRTC란?

• Web Real-Time Communication의 약자
• 웹, 앱(안드로이드, IOS)에서 별 다른 소프트웨어 없이 카메라, 마이크 등을 사용해서 실시간 커뮤니케이션을 제공해 주는 기술
• 화상회의를 구현할 수 있는 오픈소스
• UDP 기반의 P2P

즉, 웹브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계되었으면 JavaScript API를 통해 실행할 수 있습니다.

 

WebRTC의 동작과정

https://kid-dev.tistory.com/4

P2P 기반의 Mesh 방식, MCU 방식, SFU방식이 존재합니다.

 

크게 나누어 보았을 때 다음과 같이 구분됩니다.

1. 각각의 클라이언트가 모두 자신의 미디어 스트림을 나머지 피어들에게 직접 전달. (P2P 기반의 Mesh)

2. 여러 피어들이 자신들의 미디어 스트림을 중앙 서버에 보내고 서버가 이를 처리하여 피어들에게 전달. (MCU/ SFU방식)

 

하나씩 차근차근 알아가 보겠습니다.

 

 

 

P2P 기반의 Connection으로 동작하는 WebRTC

(P2P기반의 Connection)https://withseungryu.tistory.com/129#%F0%9F%98%8A%20WebRTC%EB%9E%80%3F%3F

 

중간에 서버가 없이 사용자와 사용자가 연결을 수립하고 이를 통해 문자 , 음성 , 영상을 주고받습니다.

 

인터넷에서는 데이터를 주고받기 위해서 HTTP 프로토콜을 사용합니다.

 

브라우저가 서버에게 HTTP 요청을 보내면 서버는 브라우저에게 HTTP 응답 메시지를 보내면서 통신을 합니다.

 

하지만 HTTP는 서버가 브라우저 요청에 응답하고 나면 통신이 끝나게 됩니다.

 

즉, 한번 응답이 끝나면 서버는 클라이언트와 통신이 끊기고 브라우저가 요청을 했을 때만 응답합니다.

 

만약 HTTP를 통해서 채팅과 같은 양방향 통신을 구현하게 된다면 새로운 메시지가 왔는지 확인하기 위해 n초마다 무한하게 클라이언트가 서버에게 "나에게 줄 채팅 정보 있어?"라고 묻는 방식으로 구현할 수 있습니다.

 

이를 polling 기법이라고 합니다.

https://kamang-it.tistory.com/entry/Webhttp%ED%86%B5%EC%8B%A0%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%96%91%EB%B0%A9%ED%96%A5-%ED%86%B5%EC%8B%A0%EA%B8%B0%EB%B2%95-long-polling

Long Polling 기법

또 이를 조금 보완하기 위한 Long polling 기법 또한 존재하는데 N초마다 무한히 물어보는 것이 아니라 클라이언트가 HTTP 요청을 보내서 특정 이벤트까지 계속 기다리다가 서버가 응답해주면 다시 클라이언트가 HTTP 요청을 특정 이벤트까지 기다리는 방식입니다.

 

 

웹소켓 등장

이런 HTTP의 단방향성을 극복하고자 웹소켓이 등장하게 됩니다.

웹 소켓은 HTTP처럼 응답, 요청 방식이 아닌 커넥션을 가지며 이는 Open -Close 된 여부로 판단합니다.

 

브라우저가 웹소켓을 이용해 서버와 연결하면 통신을 원하는 순간까지 계속 열려있게 됩니다.

https://www.youtube.com/watch?v=5EhsjtBE7I4

HTTP는 벽이랑 탁구를 치는 셈이고 웹소켓은 전화통화를 하는 것과 유사합니다.

이런 양방향 통신을 통해 서버와 브라우저는 문자, 음성 , 영상을 주고받을 수 있습니다.

 

채팅의 참여자들의 서버에 참여하고 서버는 모든 참여자 들고 연결하고 정보를 제공해야 하기 때문에 서버의 메모리 파워가 중요합니다.

 

WebRTC 등장

여기서 서버의 부하를 극복하기 위해 WebRTC가 등장하게 됩니다.

채팅의 참여자들이 서버에 접속하는 것이 아니라 P2P로 서로서로 브라우저끼리 연결됩니다.

 

문자, 음성, 영상들이 서버를 통해 전송되지 않으며 중간 매개체가 없기 때문에 더 빠릅니다.

하지만 채팅방에 1000명의 사람이 존재한다면 컴퓨터는 999개의 데이터들을 모두 수신해야 합니다.

이로 인해 확장성에는 제약이 발생합니다.

 

 

그러면 서버는 필요하지 않을까요?

이론상으로 P2P 연결을 통해서 통신하기 때문에 서버는 필요 없어 보입니다.

 

하지만 상대방과 통신하기 위해서는 상대방이 누구인지를 먼저 파악해야 하는데 이때 사용자를 묶어주는 역할을 하는 Signaling Server가 필요합니다.

 

Signaling Server

https://doublem.org/webrtc-story-02/

서로 다른 네트워크에 있는 2개의 디바이스들이 통신하기 위해서는, 각 디바이스들의 IP를 알아야 하며 통신을 위한 미디어 포맷 협의가 필요합니다.

 

이러한 동작 과정을 시그널링이라 부릅니다.

 

시그널링 서버를 통한 동작과정

1. 통신을 원하는 사용자는 상대 사용자에게 Signaling Server를 통해 자신의 정보들을 제공합니다.

2. 상대 사용자는 그 정보들에 대해 자신의 정보를 담아 답장합니다.

 

시그널링 서버의 한계

클라이언트가 방화벽이나 NAT뒤에 있는 경우가 대부분이기 때문에 Public IP 주소를 알아내기 어렵습니다.

이러한 문제를 해결하기 위해서는 STUN/TURN 서버를 이용하여 해결해야 합니다.

 

NAT이란?

IP주소에는 공인 IP와 사설 IP가 존재합니다.

공인 IP는 외부에 공개되어 있는 IP이며 사설 IP는 외부에 공개되어 있지 않은 주소입니다.

https://velog.io/@hidaehyunlee/%EA%B3%B5%EC%9D%B8Public-%EC%82%AC%EC%84%A4Private-IP%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

이때 클라이언트가 알고 있는 IP주소는 사설 IP의 주소

 

NAT Traversal

집에서 인터넷을 사용하는 사람이면 대부분 공유기를 가지고 있을 것입니다.

공유기를 사용하는 이유는 명확합니다.

우리는 ISP(Internet Service Provider)인 SKT, KT, LG 등과 계약 시 여러 개의 공인 IP를 사용토록 계약을 하지 않습니다.

본인이 소유한 모든 인터넷 장치별로 공인 IP가 할당되면 좋겠지만, IP의 경우 그 개수에 한계가 있습니다.

물론 IPv6라는 대안이 나오기는 했지만, 여전히 우리는 IPv4를 많이 쓰는 환경에 살고 있습니다.

 

즉, 이러한 공인 IP와 사설 IP를 매핑하기 위해 Network Address Translation 이하 NAT를 사용합니다.

 

 

ICE, STUN , TURN

https://web.dev/webrtc-infrastructure/#after-signaling:-use-ice-to-cope-with-nats-and-firewalls

STUN과 TURN서버

시그널링을 위해서 사설 IP를 공인 IP로 변환하기 위해서는 STUN서버 또는 TURN서버를 사용해야 합니다.

 

STUN(Session Traversal Utilites for NAT)

공용 네트워크 망에서 동작하며 NAT 뒤에 있는 공인 IP주소를 찾아서 반환합니다.

 

TURN(Traversal Using Replays around NAT)

NAT타입 또는 방화벽의 제한으로 P2P 연결이 실패했을 때 대안으로 사용합니다.

 

 

ICE(Interactive Connectivity Establishment)

두 단말이 서로 통신할 수 있는 최적의 경로를 찾을 수 있도록 도와주는 프레임워크입니다.

모든 가능성을 병렬로 시도하여 가장 효율적인 경로를 선택합니다.

 

동작 과정

1. ICE는 UDP를 통해 기기들을 서로 직접 연결 시도합니다.

2. 기기가 NAT 뒤에 있어 연결이 되지 않는다면 STUN 서버가 이를 해결해줍니다.

3. 이 또한 실패하면 모든 기기는 TURN 서버로 패킷을 보내고, 서버가 이를 가운데서 전달합니다.

 

 

https://doublem.org/webrtc-story-01/

 

 

 

SFU(Selective Forwarding Unit) 서버

https://medium.com/pplink/1000%EB%AA%85%EC%9D%B4%EC%84%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%BB%A4%EB%AE%A4%EB%8B%88%EC%BC%80%EC%9D%B4%EC%85%98%EC%9D%84-%ED%95%98%EB%8A%94-%EA%B0%80%EC%9E%A5-%ED%9A%A8%EA%B3%BC%EC%A0%81%EC%9D%B8-%EB%B0%A9%EB%B2%95-ca039fbcaedb

서버를 이용하여 클라이언트의 미디어 스트림을 중계하는 역할을 수행하며 상황에 따라 연결된 클라이언트 일부만 중계하기도 합니다.

 

P2P/Mesh 기반에서 다수의 사용자를 다루기 힘든 부분을 커버할 수 있는 장점을 가지고 있습니다.

 

P2P 방식에서는 연결된 클라이언트 수만큼의 업로드 트래픽이 발생하지만 중계 서버에게만 업로드 트래픽이 1개 발생하게 됩니다.

 

 중간 서버에서는 별도의 미디어 가공 과정을 거치지 않고 그대로 각 사용자들에게 전달하며, 각 피어 간에 연결 할당, 암호화 및 복호화 처리 비용 정도를 감수하고 있습니다.

 

비교적 서버에 부하가 적게 걸리는 것이 장점입니다.

 

MCU 서버

서버를 이용하여 업로드된 미디어 스트림을 하나로 합쳐서 클라이언트에 1개의 미디어스트림을 내려주는 구조입니다.

 

한꺼번에 모아서 믹싱 하여 전달하기 때문에 네트워크의 부담은 현저히 줄어들지만 CPU 사용량이 매우 커져 높은 컴퓨팅 파워가 요구되는 방식입니다.

 

 

그러면 4가지 서버를 모두 구축해야 할까요?

1. 시그널링 서버(구축해야 함, 특히 Mesh 방식을 사용한다면 가장 중요함)

2. stun 서버(이미 수많은 stun server들이 만들어져 있기 때문에 우리는 요청만 하면 됩니다.)

3. turn 서버(conturn이라는 turn 서버를 오픈소스로 제공해줍니다.)

4. 미디어 서버(구축해야 함)

 

즉, 우리는 시그널링 서버, 미디어 서버를 구축해야 합니다.

 

또한 mesh 방식으로 개발할 것이라면 미디어 서버도 필요하지 않지 않고 시그널링 서버만 필요합니다.

반대로 미디어 서버 방식을 사용한다면 시그널링 서버는 필요 없을 것 같습니다.

결론

P2P 방식을 사용할 것인가 미디어 서버를 구축해서 사용할 것인가?

 

3가지 방식의 특징을 표로 살펴보면 다음과 같습니다.

https://post.naver.com/viewer/postView.nhn?volumeNo=29147132&memberNo=50640104

Mesh 방식은 Client에게 부하가 너무 많이 발생하게 됩니다.

따라서 미디어 서버를 구축하여 Client의 미디어 업로드 트래픽을 1개로 줄여주는 장점을 가져가려고 합니다.

또한 SFU와 MCU 방식을 적절히 고려해봐야 합니다. (서버에서 높은 부하를 줄지 vs 클라이언트에게 부하를 줄지)

MCU 방식은 각 참여자의 미디어 스트림을 매번 인코딩하고 전송해야 하기 때문에 방대한 규모의 서버 인프라가 필요하기 때문에 SFU 방식을 사용하는 것이 좋을 것 같습니다.

 

결론 : SFU 방식을 통한 미디어 서버를 구축하자

 

 

 

 

 

 

 

 

 

 

 

출처

https://webrtc.org/

WebRTC

https://gh402.tistory.com/38?category=935378 

[WebRTC] WebRTC란 무엇일까?

https://withseungryu.tistory.com/129

[WebRTC] WebRTC란?

https://www.youtube.com/watch?v=5EhsjtBE7I4 

https://doublem.org/webrtc-story-02/

WebRTC 시그널링 서버 구현하기 | Doublem.org

https://doublem.org/webrtc-story-01/

WebRTC 시동걸기 | Doublem.org

https://web.dev/webrtc-infrastructure/#after-signaling:-use-ice-to-cope-with-nats-and-firewalls

Build the backend services needed for a WebRTC app