최근 제작하려는 프로젝트에 WebRTC 기술을 적용해 보기로 했다.

 

기술 멘토님들과 상의한 결과, 생각보다 기술적으로 해결해야 하는 이슈들이 많았다.

 

따라서 이번 기회에 WebRTC의 기초를 잡아보려고 한다.

 


WebRTC는?

 

  • 웹 어플리케이션(+android & ios) 및 사이트들이 데이터를 브라우져끼리 주고 받을 수 있게 만든 기술
  • 음성, 영상 미디어 혹은 텍스트, 파일 등
  • 별도의 소프트웨어 필요하지 않음
  • p2p로 공유

 

일반적으로 화상 전송 (영상 + 음성) 에 사용한다고 알려져 있지만, 채팅에도 사용할 수 있다.

 

(데이터 형식에 제한이 크지 않다는 의미)

 

www.scaledrone.com/blog/webrtc-chat-tutorial/

 

WebRTC Chat Tutorial

This tutorial will teach you: The basics of WebRTC How to create a 1-on-1 text chat where users can enter their username and be assigned a random emoji avatar How to use RTCDataChannel to send peer to peer messages How to use Scaledrone realtime messaging

www.scaledrone.com

 

WebRTC의 프로토콜

철수와 영희가 연결을 한다고 했을 때 다음과 같은 문제들이 존재한다.

  • 연결을 시도하는 방화벽을 통과해야 한다.
  • 단말에 public IP가 없다면 유일한 주소값을 할당해야할 필요가 있다.
  • 실제 사용자는 private IP를 사용한다. (일반 가정에서)
  • 라우터가 peer간의 직접연결을 허용하지 않을 때에는?

NAT (network address translation)

NAT는 외부망과 분리하고 public 망과 private 망의 IP:Port 를 매핑해주는 것이다

 

IP 변환이라고 생각하면 된다.

앞서 설명한 문제들 중 일부는 우리가 NAT 환경을 사용하기 때문에 발생한다.

 

VoIP 도 그러하지만, WebRTC 역시 Peer 간 연결을 위해서 NAT 환경에 대한 고려가 필요하다.

 

브라우저가 peer를 통한 연결이 가능하도록 하게 해주는 ICE 프레임워크에서는 이러한 작업을 수행하기 위해 다음 서버들을 사용한다. (일부만 사용하기도 함)

 

STUN 서버 (Session Traversal Utilities for NAT)

TURN 서버 (Traversal Using Relays around NAT)

 

STUN 서버

(Simple Traversal of User Datagram Protocol Through Network Address Translators)

STUN은 네트워크 환경에서 Public 관점에서 종단에 Access 가능한 IP:Port를 발견하는 작업이다.

 

IETF RFC 5389에 정의된 네트워크 프로토콜/패킷 포맷으로, 공개 주소(public address)를 발견하거나 peer간의 직접 연결을 막는 등의 라우터의 제한을 결정하는 프로토콜이다.

 

STUN은 IP 종단을 연결하기 위해서

어떤 종단이 NAT/Firewall 뒤에 있는지를 판단하게 해준다.

어떤 종단에 대한 Public IP Address를 결정하고 NAT/FIrewall의 유형에 대해서 알려준다.

 

다음 그림을 보면 과정을 이해할 수 있다.

 

A 클라이언트는 A 클라이언트의 공개주소와 라우터의 NAT 뒤에 있는 클라이언트가 접근가능한지에 대한 답변을 위한 요청을 STUN서버에 보낸다.

 

STUN 은 다음 로직에 따라서 방화벽의 종류를 결정한다고 한다.

 

내부적으로 판별하는 로직

위 로직을 보면 알겠지만, UDP 프로토콜을 사용하는 것을 알 수 있다.

UDP는 연결을 설정하지 않고 수신자가 데이터를 받을 준비를 확인하는 단계를 거치지 않고 단방향으로 정보를 전송한다. (일단 전송해본다)

 

STUN서버는 패킷의 IP 헤더와 UDP 헤더의 값(클라이언트의 공인 주소)과 STUN 메시지 안에 있는 STUN 클라이언트의 IP 주소와 UDP 포트 넘버 (클라이언트의 사설 주소)를 비교한다.

 

STUN 서버는 두 개의 서로 다른 주소에 대한 바인딩 테이블을 생성해 연결을 맺어준다.

 

TURN (Traversal Using Relays around NAT)

Peer간 직접 통신이 실패할 경우 종단점들 사이에 데이터 릴레이를 수행하는 TURN 서버들을 사용해 우회한다.

 

직접 연결이 불가능해 TURN 서버를 통해 통신하는 구조

TURN 서버와 연결하고 모든 정보를 그 서버에 전달하는 것으로 Symmetric NAT 제한을 우회한다.

 

  1. 이를 위해 TURN 서버와 연결을 한 후
  2. 모든 peer들에게 저 서버에 모든 패킷을 보내고
  3. 다시 나에게 전달해달라고 요청한다.

이는 오버헤드가 발생하므로 이 방법은 다른 대안이 없을 경우만 사용하는 방식이다.

 

TCP / UDP

RTCDataChannel은 UDP와 유사한 신뢰성 없는 방식(mode)과 TCP와 유사한 신뢰성 있는 방식 둘 중 하나로 동작할 수 있다.

 

UDP Hole Punching

앞서 말한 NAT 환경에서 연결을 위해 사용하는 방법 중 하나이다.

 

방법 중 하나로 STUN을 사용하기 때문에 앞서 STUN과 TURN 을 설명했다.

 

Hole-Punching 기술 유형은 다음과 같다

기술 설명
Relaying Client 1 → NAT A → Server → NAT B → 2
C-S 모델 연동
Connection Reversal 1 → 2 시 NAT
2 → 1 시 R서버
STUN 서버로부터 Client에 맵핑된 공인 IP 정보 수집
Hairpin 기법 Client A, B는 Server에 NAT 정보 저장
통신 시 A → NAT → B로 전송
Internal 네트워크 Client A, B는 Server에 NAT 정보 저장
통신 시 A → Local Broadcast → B

대규모 연결

사실 WebRTC 방식으로 P2P로 사용자들끼리 연결하는 경우에 소규모인 경우는 문제가 없다.

 

그러나 만약  p2p로 여러 사용자를 연결하는 모두 경우에는 각 peer당 연결해야 되는 peer의 수가 많아져 높은 부하 (인코딩 등)를 감당하게 된다.

Server based
full mesh p2p

그래서 실제 서비스를 운영할 때는 위 두 방식을 부분적으로 조합해 사용한다.

 

전부 연결되었지만, 간선의 수가 full mesh보다 적다

 

 


최큰 카카오 엔터프라이즈가 리모트 몬스터라는 기업을 인수했다.

 

https://www.hankyung.com/it/article/2020052682471

 

카카오엔터, 56억에 리모트몬스터 인수

카카오엔터, 56억에 리모트몬스터 인수, 홍윤정 기자, 산업

www.hankyung.com

리모트몬스터는 WebRTC 방송통신 기술 전문 기업이다. 역으로 말하면 WebRTC 기술을 사용할 때 부하 등 인프라 구조에 대한 깊은 이해도가 필요하다는 의미일것이다.

 

 

출처

http://www.authorstream.com/Presentation/kangsik-3609452-webrtc/

 

하이퍼커넥트-스타트업 핵심기술로서의 Webrtc(�

2018년 11월 1일, RTC KOREA 2018 컨퍼런스에서 하이퍼커넥트가 발표한 내용입니다.- authorSTREAM Presentation

www.authorstream.com

https://alnova2.tistory.com/1110

 

[WebRTC] STUN 과 TURN 에 대하여 #1 - 개요

 VoIP 도 그러하지만, WebRTC 역시 Peer 간 연결을 위해서 NAT 환경에 대한 고려가 필요하다. 이를 위해서 IETF에서 표준을 정의한 것이 바로 STUN과 TURN, 그리고 ICE 이다. 1. NAT에 대하여 NAT는 외부망과 ��

alnova2.tistory.com

https://www.slideshare.net/nurinamu/web-rtc-in-2014

 

WebRTC in 2014

Review the WebRTC issues & news and forecast the future WebRTC industry. This slide is used in GDG Seoul Monthly Meetup at 22th Jan, 2014.

www.slideshare.net

 

'공부 > WebRTC' 카테고리의 다른 글

WebRTC - 01 : 프로토콜  (0) 2020.06.11

+ Recent posts