WebRTC란 무엇이며 어떤 과정을 갖는가?

WebRTC라는 개념이 있다.

 

WebRTC는 무엇을 위한 기술이며 어떤 과정을 거치게 될까?

 

WebRTC란?

Web Real-Time Communication.

 

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

 

WebRTC를 구성하는 일련의 표준들은 플라그인이나 제 3자 소프트웨어 설치 없이 종단 간 데이터 공유와 화상 회의를 가능하게 한다.

 

쉽게 생각해서 P2P 실시간 커뮤니케이션이 가능하게 해주는 기술이다.

 

WebRTC를 사용하면 카메라, 마이크를 넘어 고급 영상 통화 애플리케이션 및 화면 공유 등에도 활용 가능하다.

 

WebRTC의 과정

WebRTC를 사용하기 위해서는 어떤 과정이 필요할까?

 

P2P 통신이 가능하지만 문제는 상대 피어의 정보를 모른다는 것이다.

 

이러한 문제점을 해결하기 위해 시그널링 서버를 사용한다.

 

Singal

WebRTC connectivity - Web APIs | MDN (mozilla.org)

WebRTC connectivity - Web APIs | MDN

WebRTC의 mdn 문서에 따르면 WebRTC는 중간에 일종의 서버 없이는 연결을 만들 수 없으며 이러한 서버를 Signal Channel 또는 Signaling Service라 부른다.

 

연결을 시작하기 위해 연결의 개시자는 Offer라는 것을 생성한다.

 

이후, 시그널 채널을 이용해 수신자에게 Offer를 전달해야 한다.

 

Offer를 수신한 수신자는 Answer를 만들어 마찬가지로 시그널 채널을 이용해 이를 전달해야 한다.

 

이를 다시 한 번 정리하면 아래와 같다.

1. A가 Offer를 생성
2. B에게 시그널 채널을 이용해 Offer를 전달
3. Offer를 수신한 B는 Answer를 생성
4. A에게 시그널 채널을 이용해 Answer를 전달

Offer와 Answer를 위해 교환해야 하는 정보는 SDP라 부른다

 

시그널링 서버는 시그널링 데이터를 몰라도 된다.

 

이는 비록 SDP지만 (우리는 알고 있지만) 시그널링 서버는 이를 몰라도 큰 문제가 없으며 단순히 시그널링 서버를 통해 상대편으로 가기만 하면 된다.

 

이어서 각 피어는 두 가지 Description을 보관한다.

• 자신을 설명하는 Local Description
• 다른 피어를 설명하는 Remote Description

Offer/Answer 프로세스는 통신의 처음 뿐만 아니라 통신의 형식 등의 설정이 바뀔 필요가 있을 때 수행한다.

 

새로운 통신인지 여부에 관계없이 기본적으로 수행해야 하는 단계는 아래와 같다.

(단, ICE는 제외) (송신자: A, 수신자: B)

1. A가 MediaDevices.getUserMedia를 통해 로컬 미디어 캡처
2. A가 RTCPeerConnection.addTrack()을 통해 요청을 생성
3. A가 RTCPeerConnection.createOffer()를 호출하여 Offer를 생성
4. A가 RTCPeerConnection.setLocalDescription()를 호출하여 Offer를 local description으로 설정
5. A가 STUN 서버에게 ICE candidates를 생성하도록 요청
6. A가 시그널링 서버를 이용해 Offer를 수신자에게 전달
7. B는 Offer를 수신한 후 RTCPeerConnection.setRemoteDescription()를 호출하여 remote description으로 설정
8. B는 A를 위해 필요한 설정을 수행 (로컬 미디어 캡처, RTCPeerConnection.addTrack()를 이용해 각 미디어 트랙을 피어 연결에 연결)
9. B는 RTCPeerConnection.createAnswer()를 호출하여 Answer를 생성
10. B는 RTCPeerConnection.setLocalDescription()를 호출하여 Answer를 전달하며 자신의 local description으로 설정
11. B는 시그널링 서버를 이용해 Answer를 A에게 전달
12. A는 RTCPeerConnection.setRemoteDescription()를 이용해 Answer를 remote description으로 설정
13. A와 B는 서로 자신의 피어에 대한 정보를 알고 있으며 미디어가 의도한 대로 흘러가기 시작

위의 모든 과정을 그림으로 나타내면 아래와 같다.

SDP

SDP - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN

SDP - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN

세션 기술 프로토콜이며 P2P 연결을 설명하는 표준이다.

 

SDP에는 오디오 및 비디오의 코덱, 소스 주소, 타이밍 정보가 포함되며 아래와 같은 형태를 갖는다.

v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0 
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

단독으로 사용되지 않으며 RTP, RTSP와 같은 프로토콜에 의해 사용된다.

 

결론적으로 SDP는 세션을 설명하는 방법으로 WebRTC의 구성요소 중 하나이기도 하다.

 

Session Description

WebRTC 연결에서 엔드포인트의 구성을 Session Description이라 부른다.

 

Description은 전송되는 미디어의 종류, 형식, 사용중인 프로토콜 등이 포함된다.

 

이 정보는 SDP를 사용하여 교환 및 저장된다.

 

사용자가 다른 사용자에게 WebRTC 호출을 시작하면 특별한 Description이 생성되며 이것이 아까 봤던 Offer이다.

 

이 Description에는 송신자에 대한 모든 정보가 포함된다.

 

수신자는 Answer로 응답하며 이는 상대방에 대한 Description이다.

 

위와 같은 방법으로 두 장치는 미디어 데이터 교환을 위해 필요한 데이터를 서로 공유한다.

 

이러한 교환은 ICE를 사용하며 다룰 수 있다.

 

ICE는 두 기기가 분리된 NAT에 존재하더라도 Offer와 Answer를 교환할 수 있는 중재자 역할을 수행한다.

 

ICE

ICE - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN

ICE - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN

대화형 연결 구축

 

네트워크 토폴로지에 관계없이 두 피어를 연결하기 위해 WebRTC에서 사용하는 프레임워크

 

이 프로토콜을 사용하면 두 피어가 모두 NAT를 사용하여 해당 로컬 네트워크의 다른 장치와 글로벌 IP를 공유하는 경우에도 서로 연결을 찾고 설정할 수 있다.

 

두 피어를 연결하기 위해 지연 시간이 가장 짧은 경로를 찾고 아래 옵션을 순차적으로 실행한다.

1. 직접 UDP 연결 (이 경우에만 STUN 서버는 피어의 네트워크 연결 주소를 찾는데 사용)
2. HTTP 포트를 통한 직접 TCP 연결
3. HTTPS 포트를 통한 직접 TCP 연결
4. relay/TURN 서버를 통한 간접 연결 (직접 연결이 실패한 경우)

 

NAT

Nerwork Address Translation

네트워크 주소 변환

 

여러 대의 컴퓨터가 IP 주소를 공유하도록 하는 기술이며 로컬 네트워크 각 컴퓨터에 고유한 주소를 할당하고 들어오고 나가는 네트워크 트래픽을 조정하여 데이터를 올바른 위치로 보내는 기술이다.

 

STUN

Session Traversal Utilities for NAT

NAT용 세션 탐색 유틸리티

 

NAT 주변에서 데이터를 전송하기 위한 보조 프로토콜로 IP 주소, 포트 및 NAT 뒤의 네트워크 컴퓨터의 연결 상태를 반환한다.

 

TURN

Traversal Using Relays around NAT

 

컴퓨터가 NAT 또는 방화벽 뒤에서 데이터를 주고받을 수 있도록 하는 프로토콜로 WebRTC에서 임의의 두 장치가 P2P 연결을 시작할 수 있도록 하는 데 사용한다.

 

ICE Candidate

피어는 미디어에 대한 정보를 교환할 뿐만 아니라 네트워크 연결에 대한 정보도 교환해야 한다.

 

이를 ICE Candidate라 하며 피어가 직접 또는 TURN 서버를 통해 통신할 수 있는 방법을 설명한다.

 

이상적인 후보는 UDP지만 TCP도 허용한다.

 

단, TCP는 UDP를 사용할 수 없거나 미디어 스트리밍에 적합하지 않은 방식으로 제한되는 경우에만 사용한다.

 

또한, 모든 브라우저가 TCP를 통한 ICE를 지원하는 것도 아니다.

 

1:N

위의 설명은 주로 1:1 연결에 초점이 맞춰져 있다.

 

1:N으로 다중 통신이 가능하게 하기 위해서는 어떤 방법이 필요할까?

 

많은 예제 등에서 PeerConnection을 배열 등으로 관리하는 방법을 채택하고 있다.

 

새로운 피어가 최초 접속 시 서버는 소켓 통신을 열고 이미 존재하는 모든 피어의 정보를 새로운 피어에게 전달한다.

 

새로운 피어는 서버로부터 받은 정보를 토대로 이미 존재하는 모든 피어에게 Offer를 보내게 될 것이다.

 

PeerConnection은 다른 피어와 자신의 연결 정보를 갖고 있는 객체기 때문에 이를 배열 등을 활용하여 관리한다면 다양한 피어와의 통신을 관리할 수 있다.

 

단, 각각의 PeerConnection에 대해 Local Description, Remote Description 등을 설정해야 하고 각 피어에 대해 각각 Offer를 전송해야 한다.

 

피어의 수가 많아진다면 많은 부하가 발생할 수 있으며 이를 해결하기 위해 WebRTC의 다양한 구성 방법 중 적절한 방식을 선택해야 할 것이라 생각한다.

---

[참고자료]

• https://webrtc.org/?hl=ko
• https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API