WebRTC 이론 정리

WebRTC란 ?

WebRTC(Web Real-Time Communications)란, 웹 또는 앱(Android, IOS)에서 별도의 소프트웨어, 플러그인 없이 음성, 영상, 텍스트 같은 데이터를 브라우저끼리 주고 받을 수 있게 해주는 기술이다.
MDN의 WebRTC 문서에서는 WebRTC를 다음과 같이 정의하고 있다.

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

구글이 GIPS 회사를 인수한 후, 해당 회사의 음성/영상 코덱 및 에코캔슬링 기술을 갖게 되었는데, 2011년도에 이 기술을 webRTC라는 이름으로 공개한 것이 webRTC의 탄생이라고 볼 수 있다.

구성 방식

두 단말이 서로 실시간 통신을 하기 위해서는 다음과 같은 사항이 필요하다.

1. 기기의 스트리밍 오디오 / 비디오 / 데이터를 가져올 수 있을 것
2. 소통하고자 하는 기기의 IP 주소와 포트 등 네트워크 통신을 위한 데이터
3. 에러의 보고, 세션 초기화를 위한 신호 통신을 관리
4. 서로 소통할 수 있는 해상도인지, 코덱은 알맞는지 등 capability 정보 교환
5. 실제로 연결을 맺는다.
6. 이후 연겨뢰는 동안 스트리밍 오디오/비디오/데이터를 주고 받을 수 있어야 함.

이 조건들을 충족하기 위해 webRTC에서는 다음과 같은 API를 제공한다.

• MediaStream: 카메라와 마이크 등의 데이터 스트림 접근
• RTCPeerConnection: 암호화 및 대역폭 관리 및 오디오, 비디오 연결
• RTCDataChannel: 일반적인 데이터의 P2P 통신

이 3가지의 객체를 통해서 데이터 교환이 이뤄지며 RTCPeerConnection 들이 적절하게 데이터를 교환할 수 있게 처리해 주는 과정을 시그널링(Signaling)이라고 한다.

PeerConection은 두 명의 유저가 스트림을 주고 받는 것이므로 연결을 요청하는 콜러(Caller)와 연결을 받는 콜리(Callee)가 존재한다. 콜러(Caller)와 콜리(Callee)가 통신을 하기 위해서는 중간 역할을 해주는 서버가 필요하고, 서버를 통해서 SessionDescription을 서로 주고 받아야 한다.

RTCPeerConnection을 통해 사용자간의 어떠한 방식으로 통신이 되는 것인가 ?

아래는 유명한 엘리스와 이브의 이야기를 가지고 잘 설명한 글이다.

엘리스가 RTCPeerConnection 객체를 생성합니다.
엘리스가 createOffer 메소드를 사용하여 제안(SDP Session Description Protocol)을 생성합니다.
엘리스가 제안과 함께 setLocalDescription을 호출합니다.
엘리스는 제안을 문자열화하고, 시그널링 메커니즘을 이용하여 이브에게 보냅니다.
이브는 엘리스의 제안을 가지고 setRemoteDescription을 호출하였으므로 그녀의 RTCPeerConnection이 엘리스의 설정을 알게됩니다.
이브는 createAnswer을 호출하고 이에 대해 로컬 세션 정보(Local Session Description Protocal), 즉 이브의 응답을 인자로 전달하는 성공 콜백 함수를 호출합니다.
이브는 setLocalDescription의 호출을 통해 그녀의 응답을 로컬 기술(Description)로 설정합니다.
그리고 나서 이브는 시그널링 메커니즘을 사용하여 그녀의 문자열화된 응답을 엘리스에게 다시 전송합니다.
엘리스는 setRemoteDescription을 사용하여 이브의 응답을 원격 세션 기술(Description)으로 설정합니다.

출처: https://withseungryu.tistory.com/129

P2P 절차 요약

1. 각 브라우저가 P2P 커뮤니케이션에 동의
2. 서로의 주소를 공유
3. 보안 사항 및 방화벽 우회
4. 멀티미디어 데이터를 실시간으로 교환

시그널링 (Signaling)

P2P 통신을 위해서는 두 기기가 서로 연결되어 있어야 한다. 그런데 두 기기를 연결하기 위해서는 서로 간의 IP 정보 등을 알아야 한다. 그래서 두 기기를 연결하기 위해서 시그널링 과정이 필요하다.

시그널링 과정은 아래의 단계로 진행된다.

1. 각 peer(사용자)는 webRTC session의 종단을 나타내기 위해 RTCPeerConnection 객체를 생성한다.
2. 각 peer는 ice candidate 이벤트를 처리하기 위한 핸들러를 설정하고 시그널링 채널을 통해 candidate들을 발신한다.
3. 각 peer는 이벤트를 처리하기 위한 핸들러를 설정한다. 이는 remote peer가 stream에 track을 추가할 때 이를 수신하여 처리하기 위한 것이다. 이 때, <video> element등을 사용하여 수신자에게 track을 연결한다.
4. 발신자(caller)는 서로를 식별할 수 있도록 고유 식별자(unique identifier) 또는 토큰을 생성하고 수신 peer와 공유한다.
5. 각 peer는 시그널링 서버(WebSocket 등 미리 합의 프로토콜을 생성해둔 서버)에 접속하여 메세지를 교환한다.
6. 각 peer는 4단계에서 생성한 토큰 등의 정보와 함께 WebRTC session에 참여하기 원한다는 신호를 보낸다.

WebRTC에서 해주지 않는 것: Signaling

Signaling은 통신을 조율할 메시지를 주고 받는 일련의 과정을 의미한다. 이를 위한 구체적인 구현 방법이나 프로토콜 사용은 webRTC에 명세되어 있지 않기 때문에, 개발자들이 편한 방식을 선택하면 된다. 어떤 사이트에서는 XHR과 Channel API를 사용하여 구현하였고, 또 어떤 사이트에서는 Node.js 위에 socket.io를 사용하여 구현했다.

Signaling이 하는 역할을 나열하면 다음과 같다.

• Session control messages: 통신의 초기화, 종료, 그리고 에러 메세지
• Network configuration: 외부에서 바라보는 ip와 포트 정보
• Media capabilities: 상호 두 단말의 브라우저에서 사용 가능한 코덱, 해상도

해당 작업은 스트리밍이 시작되기 전에 완료되어야만 한다.

네트워크 정보 교환(Network configuration)

• ICE 프레임워크를 사용하여 서로의 IP와 포트를 찾는 과정
• Candidate에 서로를 추가

미디어 정보 교환(Media capabilities)

• offer와 answer 로직으로 진행
• 형식은 SDP(Session Description Protocol)

Signaling을 성공적으로 마치고 나면, 실제 데이터는 Peer to Peer로 통신하게 된다.

서버의 역할

webRTC는 P2P 방식이라고 한 시점에서 의구심이 들것이다. 왜 서버가 필요한지가 궁금할 것이다. 그냥 클라이언트 끼리 통신을 해도 되는데 말이다. 하지만 P2P로만 연결을 한다고 가정해도 서버가 필요한 경우가 있다. 서버는 다음과 같은 역할을 수행한다.

• 사용자 탐색과 통신 / Signaling
• NAT / 방화벽 탐색
• P2P 통신 중계서버

여기서 ICE 프레임워크가 등장한다. ICE 프레임워크는 기기를 발견하고 연결하기 위한 프레임 워크이다. ICE 프레임워크는 UDP 프로토콜을 통해 기기들에 직접 연결을 시도한다. 연결이 되었다면 미디어 정보를 교환하지만, 연결이 안된 경우 (보통 NAT나 방화벽이 있는 경우) 이를 해결해 줄 수 있게 SUTN 서버로 넘긴다.

STUN은 해당 기기의 공인 IP주소를 알려준다. 또한 기기의 NAT가 직접 연결을 허용하는지 여부도 파악한다. 클라이언트가 STUN 서버에 요청을 보내면 공인 IP주소와 함께 통신에 필요한 정보들을 보내주는데, 클라이언트는 이를 이용해 다른 기기와 통신한다. 하지만 이러한 경우에도 통신이 되지 않는다면 TURN 서버로 넘기게 된다.

통신이 안되어 TURN 서버로 넘어가는 대표적인 이유로는 Symmetric NAT가 있다. 이는 같은 공인 IP환경에 있는 두 기기를 연결할 때 발생하는 현상으로, 이 경우 STUN 서버는 똑같은 공인 IP를 매핑해주기 때문에 결국 자기 자신과 통신하는 꼴이 되어 버린다.

TURN 서버는 이러한 Symmetric NAT 제약조건을 우회하기 위해 만들어졌다. TURN 서버와 연결을 맺고, 이 서버에서 모든 교환 과정을 중계한다. 모든 기기는 TURH 서버로 패킷을 보내고, 서버가 이를 포워딩한다. 모든 작업을 한 서버에서 처리하는 만큼 오버헤드가 있다.

ICE 프레임워크를 사용하는 대표적은 오픈소스 프로젝트로는 코튼(Coturn) 서버가 있다.

WebRTC 장/단점

장점

• 대기시간이 짧다.
  인스타 라이브, 유튜브 스트리밍, 트위치 방송, 아프리카 방송과 같은 플랫폼들은 RTMP(Real Time Message Protocol)를 사용한다. RTMP 같은 경우는 어느정도 대기시간이 있는 반면, WebRTC는 대기시간이 거의 없는 Real Time과 비슷하다.
• 별 다른 소프트웨어, 플러그인이 필요 없다.
  별도의 소프트웨어, 플러그인을 설치할 필요 없이 웹 브라우저에서 바로 사용할 수 있다.
• 개발하는데 있어서 진입장벽이 낮다.
  현재 자료도 많이 나와있고, javascript를 이용해서 사용법도 어렵지 않다.
• 무료이다.

단점

• 크로스 브라우징 문제
  WebRTC는 Chrome, Opera, FireFox, Android, IOS 등 다양한 브라우저, 앱에서 사용할 수 있는데, 그렇다고 모든 브라우저에서 다 가능한건 아니다. 잘 사용되지 않는 브라우저에서는 WebRTC를 사용할 수 없다.
• STUN/TURN 서버 필요
  Peer to Peer 통신을 하기 위해서는 사용자의 IP주소를 알아야한다. 하지만 실제 개개인의 컴퓨터는 방화벽 등 여러가지 보호장치들이 존재해서 Peer들 간의 연결이 쉽지않다. 이렇게 서로간의 연결을 위한 정보를 공유하여 P2P 통신을 가능하게 해주는 STUN/TURN 서버가 필요하다.

WebRTC 용어 정리

WebRTC를 처음 공부하게 될 때 용어 때문에 많이 어렵다고 느껴진다. 그래서 내가 이해하기 힘들었던 용어들을 정리해 보려고 한다.

STUN(Session Traversal Utilities for NAT)

• STUN 서버는 각 Client의 NAT 통과 전후의 IP를 기록하여 상대방 Client에 이 정보를 전달해 주며 이를 통해 P2P 연결을 성립시킨다.
• 클라이언트 자신의 Public Address(IP:PORT)를 알려준다.
• peer간의 직접 연결을 막는 등의 라우터의 제한을 결정하는 프로토콜 (현재 다른 peer가 접근 가능한지 여부 결정)
• 클라이언트는 인터넷을 통해 클라이언트의 Public Address와 라우터의 NAT 뒤에 있는 클라이언트가 접근 가능한지에 대한 답변을 STUN서버에 요청한다.

NAT(Network Address Translation)

• 단말에 공개 IP(Public IP) 주소를 할당하기 위해 사용한다.
• 라우터는 공개 IP 주소를 갖고 있고 모든 단말들은 라우터에 연결되어 있으며 비공개 IP주소 (Private IP Address)를 갖는다.
• 요청은 단말의 비공개 주소로부터 라우터의 공개 주소와 유일한 포트를 기반으로 번역한다. 이 덕분에, 각각의 단말이 유일한 공개 IP 없이 인터넷 상에서 검색 가능하다.
• 몇몇의 라우터들은 Symmetric NAT이라고 불리우는 제한을 위한 NAT을 채용한다. 즉, peer들이 오직 이전에 연결한 적 있는 연결들만 허용한다. 따라서 STUN 서버에 의해 공개 IP 주소를 발견한다고 해도 모두가 연결을 할 수 있다는 것은 아니다. (위의 설명에서 STUN 서버에 다른 peer가 접근 가능한지 여부를 요청하는 이유)
• 이를 위해 TURN이 필요하다

TURN (Traversal Using Relays around NAT)

TURN 서버는 STUN 서버를 이용한 연결이 실패하였을 경우 사용된다. 공인 IP로 돌아가는 TURN 서버를 이용하여 각 Client가 보내주는 데이터를 다른 Client로 보내는 작업을 실시하여 P2P 연결을 성립시킨다.

• TURN 서버와 연결하고 모든 정보를 그 서버에 전달하는 것으로 Symmetric NAT 제한을 우회 하는 것을 의미한다.
• 이를 위해 TURN 서버와 연결을 한 후 모든 peer들에게 저 서버에 모든 패킷을 보내고 다시 나(TURN 서버)에게 전달해달라고 해야 한다.
• 명백히 오버헤드가 발생하므로 이 방법은 다른 대안이 없을 경우만 사용해야 한다.

SDP(Session Description Protocol)

각 Peer에서 송수신 되는 멀티미디어 컨텐츠 규격(해상도, 포멧, 코덱, 압축 등)의 표준으로 SDP를 이용하여 서로의 컨텐츠의 정보를 이해할 수 있다. (SDP는 컨텐츠 데이터가 아니라 컨텐츠의 메타데이터 라는 점)

• 해상도나 형식, 코덱 암호화등의 멀티미디어 컨텐츠의 연결을 설명하기 위한 표준이다.
• 두 개의 peer가 다른 한쪽이 데이터가 전송되고 있다는 것을 알게 해준다.
• 기본적으로 미디어 컨텐츠 자체가 아닌 컨텐츠에 대한 메타데이터 설명이다.
• 기술적으로 보자면 SDP는 프로토콜이 아니다. 그러나 데이터 포멧은 디바이스간의 미디어를 공유하기 위한 연결을 설명하기 위해 사용한다.

Signaling

서로 다른 네트워크에 있는 Client들은 서로를 연결하기 위해서 각 Client의 위치와 미디어 포맷 협의가 필요하다. 이러한 프로세스를 Signaling이라고 하며 Signaling을 위해서는 Signailing 서버가 필요하다.

Signaling 서버

두 Client 사이에서 서로의 Signaling 정보를 전달 할 수 있는 서버가 필요하며 어떠한 통신 방법이든 상관없다. 또한 Signaling에서 사용되는 협의 메세지인 SDP의 내용도 몰라도 된다. 그냥 Signaling 서버는 Client에서 오는 정보를 다른 Client로 전달하는 역할만 수행하면 된다.

ICE(Interactive Connectivity Establishment)

• 브라우저가 peer를 통한 연결이 가능하도록 해주는 프레임 워크이다.
• peer간 단순 연결 시 작동하지 않는 이유들
  • 연결을 시도하는 방화벽을 통과해야 함
  • 단말에 Public IP가 없다면 유일한 주소값을 할당해야 한다.
  • 라우터가 peer간의 직접 연결을 허용하지 않을 때 데이터를 릴레이 해야 하는 경우
• ICE는 위의 작업들을 수행하기 위해 STUN과 TURN 서버 둘 다 혹은 하나의 서버를 사용한다.

ICE candidate

Signaling을 이용하여 SDP를 결정한 후에 ICE candidate(후보)들을 교환하기 시작한다. ICE candidate는 발신 Client에서 통신을 어떻게 하는지의 방법을 설명하며 통신 방법이 검색되는 순서대로 ICE candidate를 보낸다. 이미 ICE를 정해 미디어 스트리밍을 시작 했더라도 가능한 모든 ICE candidate를 전송하여 최고의 ICE를 결정한다. (이 때문에 초반에 영상의 품질이 낮을 수 있다)