풀스텍 서비스 네트워킹(9), WebRTC

풀스텍 서비스 네트워킹(9), WebRTC

2022. 12. 11. 21:08ㆍ강의 내용 정리/풀스택서비스네트워킹

728x90

WebRTC

웹 기반의 리얼타임 커뮤니케이션

웹 브라우저로 화상/음성 전화를 사용하도록 지원한다. 웹 브라우저에서도 마이크나 비디오 등을 사용할 수 있도록 지원한다.

1. 들어가는 글

1) Client-Server s Peer to Peer

P2P는 중앙집중화된 서버 없이 상대방과 통신하는 것을 지향한다. 블루투스나 무선랜으로 통신을 지향한다.

2) Client Server model

일반적인 스킴은 Client Server 모델이다.

cf) 매쉬 네트워크: 엑세스 포인트 없이 디바이스들 간에 연결해서 네트워크를 구성한다. 재난 지역의 소방관이나 외국의 산지에서 사용할 수 있다. 우리나라에서는 통신 3사에 의해 자주 사용되지 않는다.

3) p2p

블록체인이 p2p 방식을 사용한 대표적인 예시이다. 블록체인은 은행이 없는 것을 지향한다.

P2P는 다른 사람에게 일부 디스크를 나눠주면서 사용하도록 한다.

P2P는 전통적인 통신 프로그램 중 하나이다.

구글은 왜 WebRTC를 만들었을까?를 고민해보자

2. WebRTC 소개

1) WebRTC 홈페이지

처음에는 웹 브라우저 위에서 돌아가도록 설계되었다. HTML5, 자바스크립트로 표준화되었다. 줌과 같은 기술이다. 브라우저 기반의 기술이었지만 클라이언트에서 사용할 수 있게 됐다. 대표적인 기능은 카메라나 마이크를 사용해서 영상 통화 어플리케이션 및 화면 공유가 가능하다. 다양한 언어에서도 이젠 사용 가능하다.

getUserMedia를 호출하면 웹브라우저가 호출되고, 웹브라우저가 카메라나 마이크 등을 호출한다. 구글밋이 그롬 브라우저 위에서 돌아간다. 결국 WebRTC는 크롬 브라우저를 널리 확산시키기 위해 해당 기술을 /사용하는 것이다. 하지만 화상회의는 구글이 직접 짤 수 있는데 왜 굳이 인수를 해서 해당 기술을 샀는지 고민해보자.

WebRTC는 한글로 가이드가 있다.

2) WebRTC란?

오픈소스로 이를 공유했다. 만들 떄 크롬브라우저 내부에 들어가는 것은 C++로, 그 위에 들어가는 것은 자바스크립트로 짰다.

2) WebRTC의 목적

처음에는 중간자 없이 브라우저 간에 이를 처리하고자 했지만 이는 실질적으로 구현하기 어렵다.

별도의 소프트웨어 설치 없이 화상 회의가 가능하도록 하고자 했다. WebRTC의 API를 사용하고 있다.

3) WebRTC의 대표적인 API

RTCPeerConnection(): 상대방과 나와 시그널 요청(연결설정 해제) 및 압축 커뮤니케이션, 코덱 핸들링, 보안, bandwidth 관리 등을 한다. 데이터를 주고받기 위한 논리적인 연결을 한다.

getUserMedia(): 비디오, 마이크 등을 제어한다.

RTCDataChannel(): 웹소켓 등을 사용해서 양방향으로 데이터를 주고받는다. data를 주고 받기 위한 채널이다.

3. WebRTC 기술

1) ICE

인터넷을 가로질러야하기에 쉽지 않은 기술이다. 노트북은 와이파이에 접속해서 ip address를 가지고 있다. DHCP가 IP를 주고, DHCP 뒷단으로 다른 지역의 컴퓨터와의 통신을 하기 위해 NAT를 한다. 따라서 상대방과 통신하기 위해서 private address가 NAT/PAT를 통과했을 때 public address로 바뀌게 된다. 하지만 NAT, PAT가 서버없이 통신을 하는 것을 막는다. 이러한 문제를 해결하기 위해 STUN과 TURN Server를 사용한다. 이 두개를 합쳐서 ICE라고 한다.

연결 설정 및 해제를 할 때 본인은 본인의 private ip address를 알고 있고, 상대방도 본인의 private ip address를 알고 있다. 하지만 상대방과의 통신을 하기 위해 본인과 상대방의 public ip address를 알고 있어야한다. 이러한 과정이 연결 설정 및 해제를 하기위해 처리해야한다. 따라서 중앙화된 방법보다 더 복잡하게 된다. ip address를 어떻게 전달해야하는지 고민해야한다.

라우터는 자기네들끼리 연결하는 것을 금지하거나 특정 포트를 차단하거나 특정 포트만 열어주기도 한다. 네트워크의 보안을 위해 policy를 하는 것이다. 따라서 네트워크를 통과하기 어렵게 된다. 그래서 서버를 사용한다.

cf) 씨메트릭 NAT: 내 쪽에서 나갔던 포트, 상대방에게 들어왔던 포트의 페어를 기억해서, 해당 포트로 들어오는 것을 뚫어주지만 그 외에는 공격으로 간주해서 막는다.

(1) STUN 서버

내가 속한 네트워크에서 ip address를 내보낼 때 본인이 알고 있어야한다. 즉, 본인의 public ip를 알고 있어야한다. 이에 따라 본인의 public ip address를 알기 위해 STUN server에게 묻는다. 이에 따라 퍼블릭 ip와 포트 번호를 함께 알게 된다.

이후 트래픽을 흘려서 상대방에게 이를 보낸다.

(2) NAT

symmetric NAT는 다른 컴퓨터와의 통신을 진행해야지 연결을 허용한다. 따라서 router나 네트워크의 도움을 받지 않기 때문에 P2P를 사용하는 것을 막아버리는 경우가 있다.

~~(NAT/PAT는 컴퓨터 자원을 많이 잡아먹기에 주고받는 양방향성이 검증되거나 허용이 되는 경우에만 하는 경우도 있다.)~~

따라서 이를 해결하기 위해 바깥의 서버를 통과한다.

(3) TURN

위의 문제에 대해선 중간에 서버를 두 라우터가 통신을 허락할 수 있기에 TURN server가 대신 받아서 이를 릴레이하는 식으로 처리한다. 네트워크에 상대방과 나와의 연결선을 그으면 너무 많아지기에 TURN server라는 라우터를 경유해서 돌아가면 훨씬 간단해진다.

필요한 부분은 표준이 있지만 구현을 해야하는 부분이 어느정도 있다.

(4) SDP

채팅이나 VOIP, 화상 채팅을 하면 세션을 열 때 사용한다. 즉, 누군가와 연결을 할 때에는 SIP를 하지만 세션을 디스크립션하는 SDP를 해야한다. 이를 통해 해상도나 형식, 코덱 등에 대한 정보도 주고받는다.

피어투 피어를 하기 위해서 어떤 정보를 사용할 것인지에 대한 정보를 SDP라는 표준으로 주고 받는다. SDP는 카카오톡을 포함한 채팅서비스, SNS을 활용한 음성 전화에서 사용된다.

SDP는 언급하고 있으나, 원래는 SIP와 페어로 같이 얘기한다. 하지만 해당 문서에서는 반드시 써야하는 것으로 SDP에 대한 얘기만 나오고 있다.

데이터를 주고받는 행위가 아닌 서로 그저 어떤 코덱을 가지고 있는지에 대한 정보를 나누기에 프로토콜은 아니다. 본인 필드의 값을 보내준다. HTTP에서 텍스트는 어떤 것을 받을 수 있는지, 어떤 데이터 타입을 받을 수 있는 지 등에 대한 정보를 보내는 것과 유사하다.

cf) SIP: IP를 기반으로 한 음성 전화, 영상 전화, 채팅을 주고받는 프로토콜로, 어떤 코덱을 쓸지 SDP를 보내서 사용한다.

2) WebRTC 동작 구성 예시

(1) 동일 Private zone

주변 얘들을 찾을 수 있는 경우이다. 이러한 경우에는 하나의 라우터로 통신이 가능하다.

(2) NAT 라우터가 다른 경우

이를 위해 아래와 같은 그래프가 그려진다.

인터넷을 탈 때 퍼블릭 IP를 찾기위한 stun server, NAT가 양방향으로 통신한 이력이 없으면 외부에서 접속한 것을 끊어낼 수 있으니 이를 대신 통과시키는 TURN server가 있다. SDP를 주고받는 과정이 있기에 통신하고자하는 상대방을 알아야하기에 시그널링이 주고가는 시그널링 서버가 있다. 대부분 시그널링 서버에 로그인해서 접속하고, 통신하고자 할 상대방을 찾을 수 있다. 이때 시그널링 서버가 IP 어드레스 등을 보낸다.

여러 서버가 있지만 트래픽은 직접 주고받는 경우가 많다. 즉, TURN 서버가 있지만 트래픽을 직접 주고받는 경우들이 있다. 하지만 1:N인 경우에는 다시 서버가 등장하는 경우가 존재한다.

(3) 연결 예시

peer 간 데이터를 직접 송수신하도록 한다.

이러한 구조로 사용하면 연결만 했다는 정보만 서버에만 남고, 채팅을 했던 기록은 남지 않는 경우가 많다.

처음에는 STUN server를 통해 public ip address를 파악한다. 이후 시그널링 서버를 통해 어떤 사람과 대화를 하고 싶은지 선택하고, SDF를 통해 어떤 정보를 가지고 있는지 전달하여 연결과정을 거친다. NAT가 연결을 차단하는 경우에는 TURN 서버를 통해 트래픽을 주고받아야한다.

cf) 구글이 WebRTC를 산 이유

가능하면 트래픽은 직접 주고받도록 해서 부담이 없다.

연결 설정을 위한 서버(Stun server)는 한대 두고, 통신이 가능하도록 인식시켜주는 과정을 하지만 실제로 데이터를 주고받지 않으니 용량이 많이 필요하지 않아도 된다. 하지만 turn 서버는 트래픽이 많이 있을 수 있지만 오디오와 비디오에서 NAT가 문제 없다면 피어간에 트래픽은 서로 주고받도록한다. 따라서 다른 서버에 집중할 필요가 없어지게 된다.

3) WebRTC 주요 구성요소 요약

STUN 서버를 이용해 연결을 할 수 없다면 TURN 서버를 통해 릴레이해야한다. ICE은 STUN과 TURN을 포함한다.

대규모 서비스를 위해서는 반드시 필요하게 된다.

SCTP(TPC의 진화 형태)와 같은 TCP와 UDP를 혼용한다. UDP 위에서 아이싱이나 stun, turn 작업을 한다.

4) 미디어 처리 구조

세선 관리: SIP에서의 세션이다. 통신을 위해 존재하는 채팅방과 같은 것을 세션이라 한다.

가능하면 서버를 경유하지 않고 직접 통신하도록 처리한다.

4. WebRTC 장단점

1) WebRTC의 장점

(1) Near Real Time

트래픽을 직접 주고받으니 서버를 통해 데이터를 주고받는 것보다 지연이 적다는 장점이 있다. 단, 서버를 경유하지 않는 경우에만 이에 해당한다.

HTTP live stream은 매우 낮은 것을 확인할 수 있다.(Apple HLS, Low-Latency HLS 등)

(2) Inherently Low Latency

glass to glass은 카메라로 찍어서 상대방의 디스플레이에 보내는 것으로 속도가 500ms로 여겨진다. 음성은 100ms 속도라고 한다. 지연속도가 줄어드는 것이 매우 큰 장점이다.

(3) Platform and Device Independence

웹 플랫폼을 사용하기에 디바이스와 독립적이다.

(4) 오픈 소스와 표준화

오픈소스이고 표준화되었다. 표준을 언어별로 오픈소스로 풀었다.

(5) 네트워크 컨디션에 어답트한다.

simulcasting: 멀티캐스팅과는 다른 방법으로, 여러 개의 트래픽이 한번에 보내진다. 이를 받을 때에는 본인이 받고 싶은 것만 받을 수 있다.

서버에서 여러 해상도에 대해 모두 보낸다. 클라이언트가 잘 처리할 수 있는 정도를 확인해서 알아서 받는다.

cf) HTTP 라이브 스트리밍: 보내는 줄은 한 줄이지만 해상도를 조절해가며 보낸다.

2) 단점

(1) Scalability

세션에 참여하고 있는 피어들이 많아지면 부하가 많이 발생해진다. 약 50명의 피어 정도가 있는 경우가 네트워크 기술에서 한계일 것 같다고 얘기한다. P2P로 유지한다면 직접 주고 받을 수 있는 상대방의 개수가 50개 수준이다.

해결책으로는 어느 정도 인원이 넘어가면 서버를 통해서 스트리밍으로 유튜브처럼 뿌리는 형식으로 진행하면 된다.

(2) Broadcast Quality

카메라 화질이 그리 좋지 않다. WebRTC가 품질을 줄이는 것은 아니지만 의도적으로 떨어트리는 부분이 있다?

5. WebRTC 현황

1) 구글

VP8: 구글이 코덱을 만들어서 무료로 개방했다.

단, VP8은 엠펙보다 성능은 좋진 않다. 하지만 다른 플랫폼 디바이스에서 이를 사용한다.

구글에서는 생태계를 구축하기 위해 이를 주도했다.

2) 모질라

WebRTC를 반영했다.

3) 시스코

Webex도 WebRTC를 사용했고, 대규모로 사용할 경우에는 본인의 서버를 사용하도록 했다.

웹브라우저가 기본이지만 파이썬, Dart/Flutter도 가능하다 .

6. SOLID

팀 버너스리가 만든 새로운 프로젝트이다. 피어 투 피어를 활용해 만든 기술이다.

정보에 대한 하나의 단위를 팟으로 본다. 팟들은 서로 연결이 되고 있다. SOLID는 내 정보가 다른 사람과 연결되는 것을 얘기한다. 각자의 정보는 본인의 스토리지에 있고, 누군가가 내 사진을 보고 싶으면 나한테 직접 와야한다. 기존의 웹 기술을 사용한다.

돈이 안돼서 인기는 없다. 하지만 구글 드라이버, 드랍박스 폴더에 본인의 팟을 저장한다. 결국 구글이나 드랍박스와 손을 잡아서, 이를 사용한다. 피어투피어를 하면 이를 고려해볼 수 있다.

웹rtc는 무조건 P2P는 아니고 환경적인 여유가 된다면 이를 지원하는 것이다.