[Django] webRTC

Jayson Hwang·2022년 7월 10일

Django Basics

목록 보기

14/14

webRTC란?

webRTC(Web Real-Time Communication)은 웹 어플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림할 뿐 아니라, 임의의 데이터도 교환 가능하도록 하는 기술

쉽게 말하자면, 특정한 드라이버나 기타 플러그인의 설치 없이 웹 브라우저 간 P2P 연결을 통해서 데이터를 교환할 수 있도록 하는 기술이다.

그리고, P2P 방식의 커뮤니케이션인 webRTC는 각각의 웹 브라우저에서 아래와 같은 과정을 거쳐서 멀티미디어 데이터를 실시간으로 교환하여야 한다.

서로의 주소를 공유
보안 사항 및 방화벽을 우회

하지만, 브라우저는 웹 서버가 아니기 때문에 외부에서 접근할 수 있는 주소가 없으므로, 이를 해결하기 위해서는 아래 정보들에 대한 이해가 필요하다.

NAT Traversal
방화벽(Firewall)
STUN
TURN
ICE & Candidate
SDP(Session Description Protocol)

NAT Traversal & Firewall

webRTC는 서버의 개입없이 웹 브라우저 간 통신을 할 수 있어야 하는데, 이때 꼭 필요한 과정이 서로의 IP주소를 공유하는 것이다. 하지만, 일반적으로 우리가 사용하는 컴퓨터에는 방화벽, NAT, DHCP 등의 이유로 공인 IP가 할당되어 있지 않다.

NAT 는 라우터를 통해 네트워크 트래픽을 주고 받는 기술로 여러대의 컴퓨터가 하나의 Public IP를 공유(공유기에서 Public IP를 Private IP로 맵핑시켜주는 환경)하고, DHCP 로 사용되지 않고 있는 Private IP를 일시적으로 임대받는다. 이로 인하여 단순하게 Public IP만 통해서는 webRTC를 위한 특정 사용자(정확히는 사용자의 IP)를 가리킬 수 없으며, Public IP와 Private IP 주소 모두를 알아내야 사용자를 특정할 수 있다.

그리고, Public IP와 Private IP를 알아내는 과정 속에서 허들이 될 수 있는 방화벽 설정 등을 헤치고 라우터를 통과해서 연결할 방법을 찾는 것이 NAT Traversal 이며,

시그널링을 하고 연결하기 위한 UDP Hole Punching 방식은 아래와 같이 2가지가 있다.

STUN (Session Traversal Utilities for NAT)
TURN (Traversal Using Relay NAT)

STUN & TURN

STUN과 TURN 서버에 대해서 알아보기 전에 우선 NAT 환경에 대하여 아래의 그림을 통해 다시 한번 살펴보자.

위와 같이 중간에 방화벽(Firewall)이 존재하거나, NAT 환경에 있는 경우에는 Peer 간 직접적인 시그널링이 불가능하다.

STUN 서버

STUN 을 정의하자면,

자신의 Public IP 주소와 Port를 확인하는 과정에 대한 프로토콜

NAT 환경에서는 별도의 Private IP를 가지고 있기 때문에 P2P 통신이 불가능하다. 따라서, 클라이언트는 인터넷의 복잡한 주소들 속에서 자신을 식별할 수 있는 정보를 STUN 서버에 요청하고, 서버는 해당 정보를 반환해준다.

정리하자면, webRTC 연결을 하기 전

STUN 서버를 향해 요청을 보내고,
STUN 서버는 Public IP와 Port를 찾아서 클라이언트에게 반환 해준다.

그리고 이때부터 자신이 받은 Public IP를 이용하여 시그널링을 할 때 받은 정보로 시그널링을 하게된다.

하지만 다른 방화벽 정책 혹은 Symmetric NAT(연결된 적 있는 네트워크만 연결하도록 하는 제한) 등의 이유로 NAT 매핑테이블이 변경되는 경우에는 STUN 서버를 이용하더라도 해결이 불가능하다.

이 경우에 사용할 수 있는 대안이 TURN(Traversal USing Relay NAT) 이다.

TURN 서버

TURN 을 정의하면,

네트워크 미디어를 중계하는 서버를 이용하는 방식
NAT 타입 또는 방화벽의 제한으로 P2P 연결이 실패했을 때 대안으로 사용

자세히 살펴보면 아래 그림과 같은 방식으로 동작하는데,

TURN 서버는 클라이언트들이 통신할 때 Public 망에 존재하는 TURN 서버를 경유해서 통신을 한다.

순서를 정리하면,

클라이언트가 Private IP가 포함된 메세지를 TURN 서버로 전송
TURN 서버에서 메세지에 포함된 Network Layer IP 주소와 Transport Layer의 UDP Port 차이를 확인
(UDP: IP를 사용하는 네트워크 내에서 컴퓨터들 간에 메세지가 교활될 때 제한된 서비스만을 제공하는 통신 프로토콜, TCP의 대안)
해당 내용을 클라이언트의 Public IP로 응답하고, NAT는 NAT 매핑테이블에 기록되어있는 정보에 따라 내부 네트워크에 존재하는 Private IP로 메세지를 전송

<< STUN & TURN 정리 >>

STUN

자신의 Public IP 와 Port를 확인하는 과정을 명시한 프로토콜

TURN
- 패킷 릴레이를 위한 서버를 할당 받기 위한 과정을 명시한 프로토콜

ICE & Candidate

ICE : 모든 통신 가능한 주소를 식별하는 것

Candidate : IP 주소와 Port 넘버의 조합으로 표시된 주소

STUN, TURN 서버를 이용해서 획득한 IP 주소, 프로토콜, 포트 넘버의 조합으로 통신 가능한 모든 네트워크 주소를 Candidate(후보) 라고 하며, 사설망에 있는 3개의 통신 가능한 주소를 획득한다.

Local Address
자신의 Private IP & Port 넘버
Server Reflexive Address
자신의 Public IP & Port 넘버 (STUN, TURN 서버로부터 획득)
Relayed Address
TURN 서버의 IP 주소 & Port 넘버 (TURN 서버로부터 획득)

Direct Connection
Host Candidate 간의 직접 미디어를 송수신
Server Reflexive Connection
Server Relexive Candidate를 이용한 미디어 송수신
TURN Relay Connection
Relay Candidate를 이용한 미디어 송수신

그리고, 이런 과정들은 ICE (Interactive Connectivity Establishment) 라는 프레임워크를 통해서 이루어지며,ICE 는 P2P 연결이 가능하도록하는 최적의 경로를 찾아준다.

ICE Candidate Gathering

Caller은 SDP Offer에 확보된 3개의 Candidate의 우선순위를 정하고, 시그널링 채널을 이용하여 Callee에게 전송한다.
Callee 또한 Candidate Gathering을 통해 3개의 Candidate 주소를 확보하고 우선순위를 정해 SDP Answer에 담아서 Caller에게 전송한다.