WebRTC의 동작원리

WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를

포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다.

 

1. 실시간 통신: 브라우저 간에 실시간으로 오디오, 비디오, 데이터 스트림을 주고받습니다.(기본적으로 UDP 사용)
2. 플러그인 불필요: 별도의 설치나 플러그인이 필요 없으며, HTML5와 자바스크립트만으로 통신이 가능합니다.
3. P2P 연결: 서버를 통해 데이터를 중계하지 않고, 사용자들끼리 직접 통신하여 지연 시간을 최소화합니다.
4. 보안: 기본적으로 모든 통신은 암호화되어 있어, 보안이 중요한 실시간 통신에 적합합니다.

 

중개서버를 거치지 않기 때문에 빠른 속도로 통신이 가능하며 HTTPS 사용이 강제되기 때문에 보안 또한 보장됩니다.

속도와 보안과 더불어 WebRTC가 다양한 플랫폼, 브라우저에서 같은 사용자 경험을 제공하기 위해 호환성 또한 고려되어야 합니다.

 

브라우저 호환성은 can i use에서 확인 가능하다.

 

아직까지 완전히 표준화가 되어있지 않은 기술입니다.

WebRTC 자체는 1.0의 표준 버전이 있지만, 이 규격을 모두 준수하는 플랫폼이 많지 않은 것 같네요

아직 각 브라우저 WebRTC API에는 moz, webkit 같은 벤더 프리픽스가 붙어 있습니다.

 

 

MDN 문서에 따르면

각 브라우저마다 다른 코덱 및 기타 미디어 기능에 대한 지원 수준이 다르기 때문에, 코드 작성 전에 Google에서 제공하는 

shim 및 polyfill을 사용하여 다양한 플랫폼의 WebRTC 구현 간의 차이점을 없애주는 Adapter.js 라이브러리를 사용하는 것을 강력하게 권장하고 있습니다.

 

---

WebRTC의 동작원리

 

P2P란(Peer to Peer)?

 

**P2P (Peer-to-Peer)**는 네트워크에서 중앙 서버 없이, 각 참여자가 동등한 권한을 가지고 직접적으로 데이터를 주고받는 통신 방식을 의미

 

 

P2P 절차

WebRTC는 P2P 방싱의 커뮤니케이션이기 때문에 통신 대상인 각각의 웹 브라우저는 다음과 같은 절차를 밟아야 한다.

 

1. 각 클라이언트가 P2P 연결에 동의

2. 서로의 주소 공유

3. 보안 사향 및 방화벽 우회

4. 멀티미디어 데이터를 실시간으로 교환

 

여기서 2번과 3번 단계가 일반적인 통신 방법으로는 이해하기 어려운 부분이다.

브라우저는 웹 서버가 아니기 때문에 외부에서 접근할 수 없는 주소가 없기 때문에 WebRTC가 P2P 기반이긴 하지만

통신 설정 초기 단계에서는 중재자의 역할이 필요합니다.

 

---

방화벽과 NAT 트래버셜

일반적인 컴퓨터에는 공인 IP가 할당되어 있지 않습니다.

보통의 회사 사무실에선 건물의 스위치(NAT)등을 이용해 공유기에 사설 IP를 받아 사용합니다.

(건물의 NAT > 사무실 공유기 NAT > 내 PC)

 

 

일반 컴퓨터에 공인 IP가 할당되지 않는 이유

 

• 공인 IP는 인터넷에 직접 연결되는 고유한 주소이며, 사설 IP는 내부 네트워크에서만 사용되는 주소입니다.
• 일반적인 컴퓨터에 공인 IP가 할당되지 않는 이유는 IP 주소의 부족, 보안, 네트워크 관리의 용이성, 비용 등의 이유 때문입니다. 사설 IP를 사용하여 NAT를 통해 공인 IP를 공유함으로써 이러한 문제를 해결하고 있습니다.

 

예시로 회사 사무실 공유기의 IP 할당에 대해 설명해 보겠습니다.

 

1. 건물 전체의 라우터:
   • 건물 자체에 위치한 라우터가 ISP로부터 공인 IP 주소를 할당받습니다. 이 라우터는 건물의 모든 사무실에 인터넷 연결을 제공합니다.
   • 각 사무실은 건물의 라우터에 연결되며, 이를 통해 인터넷에 접근합니다.
2. 사무실의 공유기:
   • 사무실 내의 공유기는 일반적으로 사설 IP 주소를 할당받습니다. 이 경우 공유기는 건물의 라우터와 연결되어 있으며, 건물의 라우터에서 할당받은 공인 IP를 사용하여 인터넷에 연결됩니다.
   • 공유기는 사무실 내부의 장치(컴퓨터, 프린터 등)에게 사설 IP 주소를 할당하여, 내부 네트워크를 구성하고 인터넷 접속을 관리합니다.

NAT의 역할

• 이 경우, NAT는 두 번 적용됩니다:
  1. 건물의 라우터: 건물의 공인 IP와 내부 네트워크의 사설 IP 간의 변환을 관리합니다.
  2. 사무실의 공유기: 사무실의 사설 IP와 건물의 공인 IP 간의 변환을 관리합니다.

요약

• 공유기가 직접 공인 IP를 할당받지 않고, 건물의 라우터가 공인 IP를 할당받아 여러 사무실에 인터넷을 제공하는 구조가 가능합니다.
• 이 경우 각 사무실의 공유기는 사설 IP를 사용하여 내부 장치를 관리하고, 건물의 라우터를 통해 인터넷에 연결됩니다.

 

일반적으로 라우터가 NAT 역할을 합니다. 외부에서 접근하는 공인 IP와 포트 번호를 확인하여 현재 네트워크 내의 사설 IP 들을 적절히 매핑시켜 줍니다. 

 

결론적으로 어떤 브라우저 두 개가 직접 통신하려면, 각자 현재 연결된 라우터의 공인 IP 주소와 포트 번호를 먼저 알아내야 합니다.

 

But, 어떤 라우터들은 특정 주소나 포트와 연결을 차단하는 방화벽이 설정되어 있을 수도 있습니다. 

이처럼 라우터를 통과해서 연결할 방법을 찾아내는 과정을 NAT 트래버셜이라고 합니다.

 

Traversal - 가로지르는, 여기저기 돌아다니는

---

STUN & TURN

STUN vs TURN

NAT 트래버셜 작업은 STUN(Session Traversal Utilitise for NAT) 서버에 의해 이루어집니다.

STUN 방식은 단말이 자신의 공인 IP주소와 포트를 확인하는 과정에 대한 프로토콜입니다.

즉, STUN 서버는 인터넷의 복잡한 주소들 사이에 유일하게 자신을 식별할 수 있는 정보를 반환해 줍니다.

WebRTC 연결을 시작하기 전에 STUN 서버를 향해 요청을 보내면 STUN 서버는 NAT 뒤에 있는 Peer들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아줍니다.

 

But, STUN 서버를 이용하더라도 항상 자신의 정보를 알아낼 수는 없습니다.

어떤 라우터들은 방화벽 정책을 다르게 할 수도 있고, 이전에 연결된 네트워크만 연결할 수 있게 제한을 걸기도 합니다.(Symmetric NAT)

 

이 때문에 STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우, TURN(Traversal Using Relay NAT)

서버를 대안으로 사용하게 됩니다.

 

TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 방식입니다.

중간에 서버를 한 번 거치기 때문에 엄밀히 말하면 P2P 방식이 아니게 됩니다.

하지만 보안정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이 기 때문에

이 방식은 최후의 수단으로 선택되어야 합니다.

 

---

ICE와 Candidate

위에서 이야기한 STUN, TURN 서버를 이용해 획득한 IP 주소와 프로토콜, 포트의 조합으로 구성 연결 가능한 

주소들은 후보(Candidate)라고 부릅니다. 그리고 이 과정을 후보 찾기(Finding Candidate)라고 부릅니다.

 

후보들을 수집하면 일반적으로 3가지의 주소를 알게 됩니다.

 

- 자신의 사설 IP와 포트 넘버

- 자신의 공인 IP와 포트넘버(STUN, TURN 서버로부터 획득 가능)

- TURN 서버의 IP와 포트 넘버(TURN 서버로부터 획득 가능)

 

이 모든 과정들을 ICE(Interactive Connectivity Establishment)라는 프레임 워크 위에서 이뤄집니다.

ICE는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크입니다.

 

여기까지 내용을 요약하면 ICE 프레임워크가 STUN 혹은 TURN 서버를 이용해 상대방과 연결 가능한 후보들을 갖고 있고,

두 개의 사용자가 통신할 수 있는 주소를 알아냈습니다.

 

이제 주소를 알아냈으니 정보를 교환해야 합니다.

 

 

---

SDP

 

SDP(Session Description Protocol)은 WebRTC에서 스트리밍 미디어의 해상도, 코텍 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기위해 채택한 프로토콜입니다.

 

미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 발행 구독 모델(Pub/Sub)과 유사한 제안 응답 모델(Offer/Answer)을 가지게 됩니다.

다른말로, 어떤 피어가 이러한 미디어 스트림을 교환할 것 이라고 제안을 하면, 상대방으로부터 응답이 오기를 기다린다는 의미입니다.

 

응답을 받게되면 각자 피어가 수집한 ICE 후보 중에서 최적의 경로를 설정하고 협상하는 프로세스가 발생합니다.

수집한 ICE 후보들로 패킷을 보내 가장 먼저 지연 시간이 적고 안정적인 경로를 탐색합니다.

이렇게 최적의 ICE 후보가 선택되면, 기본적으로 필요한 모든 메타 데이터와 IP 주소 및 포트, 미디어 정보가 피어 간 합의가 완료됩니다.

 

---

Trickle ICE

ICE 프레임워크를 설정할 때 자주 접하는 옵션 중 하나가 Trickle ICE입니다. 이 용어가 어떤 의미인지 짐작이 가시나요?

일반적으로 각 피어는 ICE 후보를 수집하여 목록을 완성한 후 한꺼번에 교환합니다.
그러나 이 방식은 SDP의 제안 응답 모델과 맞물려 몇 가지 단점이 있습니다. 후보를 모으는 데 시간이 오래 걸리고, 네트워크 환경에 따라 지연이 발생할 수 있습니다. 또한 한쪽 피어의 ICE 후보 수집이 완료되어야 다른 피어가 후보를 모을 수 있어 비효율적입니다.

Trickle ICE는 이러한 비효율적인 후보 교환을 병렬 프로세스로 수행할 수 있게 해주는 기술입니다. 즉, 두 개의 피어가 ICE 후보를 수집하고 교환하는 과정을 동기적에서 비동기적으로 변화시킵니다.

Trickle 옵션이 활성화된 ICE 프레임워크는 각 피어에서 ICE 후보를 발견하는 즉시 교환을 시작합니다.
이를 통해 서로 연결 가능한 ICE를 더 빨리 찾아낼 수 있습니다. 이 옵션 덕분에 ICE 프레임워크는 피어 간의 연결 상태를 체크하면서 연결 시간을 최적화할 수 있습니다. 결론적으로 Trickle 옵션은 활성화하는 것이 좋습니다.

 

> Trickle ICE는 후보 수집 과정을 병렬적으로 처리하여, 각 피어가 발견한 ICE 후보를 즉시 교환

 

---

시그널링

 

위에서 언급한 모든 과정을 시그널링(Signaling)이라고 합니다.

이는 RTCPeerConnection 통신에 필요한 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보, NAT 통과 방법 등의 통신 규격을 교환하기 위해 두 장치 간의 제어 정보를 주고받는 과정을 의미합니다.

 

시그널링은 WebRTC 자체에서 지원하는 기능이 아니며, 연결 전 미리 준비해야 하는 과정입니다. 또한 WebRTC의 스펙에 포함되어 있지 않아 정해진 방법이 없습니다. 이는 알 수 없는 두 장치가 언제 어떤 방식으로 연결될지 예측할 수 없기 때문이며, 개발자는 자신에게 맞는 최적의 방법을 선택할 수 있습니다.

 

일반적으로 두 장치를 연결하기 위해 시그널링 서버를 직접 구축하거나, 외부 솔루션을 활용합니다.

시그널링 서버를 직접 구축할 경우, 웹 소켓(WebSocket)이나 서버 전송 이벤트(Server-sent Event) 방식을 사용할 수 있습니다.

 

또는 시그널링 정보를 조회할 수 있는 API를 만들고 브라우저에서 주기적으로 XHR 요청을 통해 폴링(polling) 기법을 적용할 수도 있습니다.

 

WebRTC를 처음 접하는 개발자에게는 표준이 없다는 점이 혼란을 줄 수 있습니다. 직접 서버를 구축하는 것은 작업량이 많기 때문에, 시그널링 서버를 제공하는 솔루션을 사용하는 것도 좋은 방법입니다. 예를 들어, 아마존의 Kinesis Video Stream이나 구글의 AppRTC에서 Google App Engine으로 구현된 시그널링 서버를 확인할 수 있습니다.

 

---

References

 

https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API

WebRTC API - Web API | MDN

 

 

https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html

WebRTC는 어떻게 실시간으로 데이터를 교환할 수 있을까? - 재그지그의 개발 블로그