webRTC에 대해서 소개하고 서비스를 구축, 설계하며 발생한 이슈를 소개하고, 슈팅하는 과정에 대해서 제가 겪었던 경험들을 공유하면 좋을 듯 하여 포스트를 작성하게 되었습니다. 이번 포스트에서는 webRTC를 이해하기 위한 네트워크의 기본 개념과 webRTC 구축을 위해 필요한 배경 지식에 대해 설명합니다.
기본적으로 webRTC는 저지연 실시간 양방향 통신을 위해 구글에서 구축해준 API입니다. 흔히들 쓰는 구글미트도 webRTC를 사용하며, 아마 이미 많이들 쓰고 있는 서비스 중에 webRTC를 사용하는 곳은 많을 듯 합니다. 세간에 이미 다양한 데이터 스트리밍 기술이 많지만, webRTC는 지연(delay) 측면에서 좋은 성능을 보입니다.
어떻게 지연이 적을 수 있는가? 를 간단히 설명하자면 기본적으로 'UDP를 기반으로 한 P2P 통신을 하기에 그렇습니다.' 라고 대답할 수 있습니다. UDP protocol은 기본적으로 신뢰할 수 없는 프로토콜입니다. 보안이 약하다는 의미의 '신뢰'가 아니라 데이터의 소실이나 소실 여부를 판단할 수 없기에 신뢰할 수 없다고 말합니다. 대신에 그만큼 혼잡 제어가 없으므로 통신이 빠르다는 장점 있습니다. 또한 P2P 통신은 중계서버를 통하는 것 보다 물리적으로 더 빠를 수 밖에 없습니다.
공인 아이피(Public IP), 사설 아이피(Private IP)
아이피는 공인 아이피(Public IP)와 사설 아이피(Private IP)로 나누어 집니다. 공인 아이피는 실제로 할당된 주소를 의미하며 사설 아이피는 라우터(공유기)가 임의로 할당해준 주소를 의미합니다. 사설 아이피가 존재하는 이유는 IPv4의 주소체계에서는 사용할 수 있는 IP 주소 할당 공간이 부족하기 때문입니다. IP와 관련된 자세한 내용은 다음 기회에 작성해보도록 하겠습니다.
NAT(Network Address Translation)
NAT(Network Address Translation, 네트워크 주소 변환)은 컴퓨터 네트워크에서 사용되는 용어입니다. NAT는 라우터와 방화벽의 일부분입니다. 위에서의 언급처럼 공인 아이피와 사설 아이피를 서로 변환시켜주는 역할을 하며 인터넷(외부 네트워크)와 사설 네트워크 사이에서 방화벽 역할을 하여 외부 네트워크에서 들어오는 공격을 방어합니다.
기억해야 할 점은, 우리는 보통 공유기를 설치해서 와이파이를 연결하여 사용 중이니 사설 아이피를 사용중이라는 사실과, 우리 눈에 직관적으로 보이진 않지만 통신 동작들이 외부의 인터넷으로 나갈 때는 NAT를 거쳐 공인 아이피로 바뀐다는 사실입니다. 가장 일반적인 NAT 시나리오를 살펴봅시다.
일반적인 NAT 시나리오
우선 TCP/IP 통신의 시나리오를 먼저 알아보겠습니다. 앞선 언급처럼 대부분의 경우 사설 아이피를 사용하기에 통신 시나리오에서 NAT는 반드시 고려되는 대상입니다.
(시나리오 작성중)
webRTC 통신은 기본적으로 UDP를 기반으로 하였기 때문에 P2P(Peer To Peer) 통신입니다. 그러나 서로 다른 네트워크 사이에서 P2P 통신은 쉬운 일이 아닙니다. 각 엔드포인트 사이에는 NAT가 존재하기 때문입니다. 즉 엔드포인트가 제출한 주소는 다른 엔드포인트가 연결할 수가 없습니다. 또한 엔드포인트는 자신이 통신하려는 다른 엔드포인트 사이에 어떤 네트워크 토폴로지(Network Topology)가 있는 지 모릅니다.
P2P & NAT
그렇다면 NAT를 통과해(NAT Traversal) 엔드포인트 간 통신(p2p)가 가능할까요? 이에 대해서는 대표적으로 다음 세가지 방법이 있습니다.
Relaying
Connection Reversal
Hole Punching[각 방법에 대한 설명, 추후 추가 예정]
NAT traversal in webRTC
위에서의 언급처럼, 각 클라이언트(엔드포인트)는 NAT에 가로막혀 서로가 통신을 할 수 없는 상황에 놓입니다. webRTC 또한 통신을 위해서 NAT traversal이 필요합니다. webRTC는 STUN, TURN 서버를 이용한 NAT 통과 기법을 사용합니다.
STUN (Session Traversal Utilities for NAT)
그림 1. STUN 서버의 역할
그림 2. webrtc 통신 구조 (signaling + stun)
TURN (Traversal Using Relay NAT)
STUN 서버를 통한 피어의 통신이 실패한 경우(데이터를 직접 주고받는 것이 안됨), TURN 서버가 두 피어들 사이의 데이터를 릴레이하며 이 경우 Symmetric NAT 제한을 우회합니다. 물리적으로 당연하게도 딜레이나 품질에 저하가 있을 수 있습니다. 또한 결국엔 서버가 데이터를 경유하게 되므로 트래픽 비용이 발생하게 됩니다.
Signaling & Signaling Server
두 피어는 서로의 Session Description을 SDP에 맞게 주고받아야 합니다. webRTC에서는 두 피어가 주고받으며 연결을 맺어가는 과정을 'Signaling'이라고 합니다. Signaling을 위해서는 별도의 서버가 필요하며 이를 일반적으로 'Signaling Server'라 부릅니다. 앞으로 이 서버를 직접 구축하는 과정을 보이겠지만, 기본적으로 Signaling 서버는 개발자가 직접 만들어야 하며, 이를 위해 필요한 프레임워크는 무엇이든 가능하므로 개발자의 선택입니다. 참고로 저는 NodeJs의 Express를 사용하여 서버를 구축하였습니다.
WebRTC의 Signaling 프로세스는 '제안(offer) > 응답(answer) > IceCandidate 교환' 입니다.
그림 3. WebRTC Signaling Process
두 피어중 하나의 피어(A)가 먼저 다른 피어(B)에게 제안을 보내고, 제안을 받은 피어는 그에 대한 응답을 합니다. 그리고 두 피어가 candidate를 교환합니다. 시그널링 절차가 성공적으로 진행된 경우 연결이 완료되며 스트림 데이터(미디어/오디오)를 확인할 수 있습니다. 이 과정 제안/수락 과정에서 피어가 SDP를 교환합니다.
SDP (Session Description Protocol)
세션 기술 프로토콜(Session Description Protocol, SDP)은 스트리밍 미디어의 초기화 인수를 기술하기 위한 포맷이다.
이 규격은 IETF의 RFC 4566로 규정되어 있다.
- Wikipedia
실제로 두 피어가 미디어를 주고 받기 위해서 피어들 사이의 미디어 연결을 설명하는데 사용되는 데이터 포맷입니다. 쉽게 말하자면, 두 피어간의 멀티미디어 세션을 공유하기 위해 사용되는 프로토콜 입니다.
ICE candidates
피어는 연결을 위해서는 미디어 정보(SDP)뿐만 아니라 네트워크 연결 정보를 교환해야 합니다. 이러한 네트워크 연결 정보들을 ICE candidate라고 합니다. 일종의 연락처 교환과 비슷하며 다수의 ICE candidates를 교환합니다. 각 피어는 수 많은 연락처 후보군 중에 가장 좋은 후보에서 나쁜 후보 순으로 제안하며 연결을 시도합니다. 두 피어가 연결되기 위해 필요한 candidate는 각 하나씩 이므로 다수의 ICE candidates에서 경우의 수에 따라 두개씩 짝 지은 것을 candidate pair라고 합니다. 가장 선호되는 후보는 'UDP 및 피어 간의 직접 연결' 입니다.
트래픽과 관련된 최근 이슈
한국에서 서비스 중인 대표적인 스트리밍 플랫폼(인터넷 방송)이 있습니다. 한국에서는 보통 트위치와 아프리카가 양대산맥입니다. 최근 이슈에서 트위치가 한국에서의 사업을 접고 떠난다는 말이 있었습니다. 이해관계가 복잡하게 얽혀 있어서 갑론을박이 있는 주제(망 중립성, 통신사,기업 등)긴 하지만, 근본적인 이유는 트위치가 한국에서의 스트리밍 트래픽에 대한 비용이 너무 과해서 한국 사업 철수를 고려한다는 것 입니다. 저는 이 이슈를 접하고 들었던 생각은 "아프리카는 왜 괜찮은걸까?" 였습니다.
그래서 알아보니, 아프리카는 시청자가 고화질로 방송을 시청하기 위해서는 특정 프로그램을 설치해야 합니다. 그 프로그램은 그리드(grid) 통신을 위한 것입니다. 그리드 방식의 통신은 엄밀히는 p2p와 다르지만, 트래픽에 대한 부담을 유저가 처리한다는 점에 있어서는 p2p와 유사한 점이 있습니다. 위에서의 언급처럼 두 피어가 직접 통신을 하므로 서버는 아무런 부담을 지지않는 경우와 비슷합니다. 그에 반해 트위치는 트래픽에 대한 모든 비용을 트위치가 부담하고 있는 상황입니다. 즉 아프리카는 유저가 트래픽 부담을 지기 때문에 통신사에 과한 금액을 지불 할 필요가 없었나 봅니다.
webRTC는 설계하기 나름이지만 일반적으로는 p2p 서비스에 많이 이용되고 있으며 제가 업로드할 포스트들도 p2p를 기반으로 합니다. 그러나 TURN 서버를 사용한다면 서바가 트래픽을 부담하게 되므로 클라우드 서비스에 TRUN이 구축되어 있다면 트래픽 비용을 지불해야 합니다. 트래픽과 미디어 서버의 구현 방식에 대해 궁금하다면 아래 블로그 글을 참고해보시길 바랍니다.
