WebRTC, 화상통화 구현이 어려운 당신을 위한 (1)

여러분은 웹/앱을 통해 화상통화 또는 음성 통화를 해본 경험이 있으신가요?

그렇다면 한 번쯤은 "이런 통화는 어떻게 구현하는 걸까?"라는 생각을 해보신 적도 있으실 텐데요.

저희는 이번 글과 다음 글을 통해 화상/음성 통화를 구현하는 WebRTC를 한번 제대로 알아봅시다.

 

먼저 WebRTC의 정의를 알고 가야 뒤의 내용을 이해하기 쉬우실 텐데요.

WebRTC는 웹/앱에서 별다른 소프트웨어 없이 카메라, 마이크 등을 사용하여
실시간 커뮤니케이션을 제공해 주는 기술입니다.

그에 따른 예시로 화상통화, 음성통화 그리고 라이브 강의와 실시간 채팅 등이 있습니다.

동작 조건

 

이러한 WebRTC가 동작하기 위해선 몇 가지 조건이 존재합니다.
조건을 충족시키지 못한다면 WebRTC는 동작하지 못합니다.

그 조건으로는 

1. 기기의 스트리밍 오디오 / 비디오 / 데이터를 가져올 수 있을 것
2. 소통하고자 하는 기기의 IP 주소와 포트 등 네트워크 통신을 위한 데이터가 존재할 것
3. 에러의 보고, 세션 초기화를 위한 신호 통신을 관리할 수 있을 것
4. 서로 소통 가능한 해상도, 코덱 등 미디어 처리 능력을 교환하고 합의할 수 있을 것
5. 기기 간 실제 연결 여부를 확인하고 연결 상태를 추적할 수 있을 것
6. 연결이 유지되는 동안 스트리밍 오디오, 비디오, 데이터의 실시간 송수신이 가능할 것

쉽게 말해서 기기끼리 실시간으로 영상, 소리, 데이터가 오가고, 연결 상태와 오류를 관리할 수 있다면 WebRTC가 동작할 수 있는 환경이 준비되었다는 뜻입니다.

 

통신 원리

 

그렇다면 대체 어떻게 통신하는 것일까요? 간단한 통신 원리를 알아보겠습니다

위 그림은 Peer to Peer 통신, 즉 p2p 통신을 보여주는 그림입니다.

이러한 p2p 통신은 하나의 컴과 하나의 컴이 데이터를 주고받는 형식입니다.

즉, 동등 계층 간 클라이언트/서버의 개념이 없이 동등한 노드들로 구성되어 데이터를 주고받는 형식입니다.

 

이러한 p2p로 연결하기 위해선 중계 서버라는 것이 꼭 필요합니다.
물론 기기끼리 직접 연결을 한다면 베스트겠지요.
하지만 그러한 방식은 NAT/방화벽에 막힙니다. 이때 양쪽 데이터를 대신 전달하는 것이 바로 중계 서버입니다.

 

주요 개념과 용어

그럼 이제 주요 개념과 용어를 알아봅시다.

WebRTC에는 꼭 알아야 하는 주요 용어와 개념들이 존재합니다.

바로 시그널링, SDP, ICE, STUN, TURN 등이 그 주인공입니다. 이제 이 주인공들을 자세히 한번 알아볼까요?

시그널링(Signaling)

바로 직전에 p2p를 연결하기 위해선 중계 서버가 필요하다고 했는데요, 이 중계 서버를 통해 서로를 찾고 연결하는 과정이 바로 시그널링입니다.

 

예를 들어, 소개팅을 진행할 때 주선자가 존재하죠? 이 주선자는 양쪽에게 서로의 정보를 전달해 줍니다. 여기서 주선자의 역할이 바로 시그널링의 개념과 동일합니다.

 

이 시그널링은 서버를 통해 이루어지며, 구현 방식은 완전히 자유입니다.

WebSocket, HTTP 등 적절한 프로토콜을 선택하여 개발하면 됩니다.

SDP(Session Description Protocol)

SDP는 사용자가 무엇으로, 어떻게 소통하지에 대한 정보가 담겨있는 양식입니다.

즉, 나는 이런 오디오, 비디오를 사용할 거야.라고 알려주는 일종의 자소서라고 보시면 편하겠습니다.

 

이러한 SDP에는 세션 정보, 네트워크 정보, 미디어의 종류, 코덱, 스트림의 속성 등 방대한 내용이 담겨있습니다.

 

그렇기 때문에 연결을 시작하는 쪽에선 Offer SDP를 생성하고, 받는 쪽에선 Answer SDP로 응답합니다.

이러한 정보를 통해 양쪽 Peer가 지원하는 코덱, 해상도 등을 협상하여 최적의 설정을 결정하는 것이 바로 SDP입니다.

ICE(Interactive Connectivity Establishment)

그럼 이제 자기소개(SDP)를 했으니 이제 연락 방법을 정해야 합니다.

 

여기서 ICE를 사용하는데요. ICE는 내 주소는 이거야! 여기로 연락해!라고 알려주는 과정입니다.

 

즉, Peer 간의 최적의 통신 경로를 찾기 위해 사용되는 프레임워크입니다.

NAT과 방화벽 등의 네트워크 장벽을 극복하고 직접적인 연결을 가능하게 해주는 역할을 담당하고 있습니다.

ICE가 최적의 통신 경로를 찾기 위해선 여러 절차를 걸쳐 찾아냅니다.

 

먼저 가능한 모든 연결 방법(후보)을 찾아냅니다. 그 후 각 후보에 대해 실제 연결 가능 여부를 테스트합니다. 이제 여기서 가장 효율적인 연결 경로, 즉 지연시간이 가장 짧은 연결을 선택합니다. 이제 NAT 및 방화벽을 통과할 수 있습니다.
이러한 방식을 보기 쉽게 표현한다면, 아래와 같습니다.

1. 연견 후보 수집
2. 연결성 검사
3. 우선순위 검사
4. NAT 및 방화벽 통과

   

최적의 통신 경로를 찾았으니 이제 직접 연결을 진행해야겠죠? 
여기서 ICE는 또 여러 옵션을 순차적으로 진행합니다.

1. 직접 UDP 연결, 사설 IP - 이 경우엔 STUN 서버가 Peer의 네트워크 연결 주소를 찾는 데 사용됩니다.
2. HTTP 포트를 통한 직접 TCP 연결
3. HTTPS 포트를 통한 직접 TCP 연결
4. Rela/TURN 서버를 통한 간접 연결 - 직접 연결이 실패한 경우

이러한 순차적 방식을 통해 ICE는 직접적인 연결을 시도합니다.

 

하지만 일반적으로 p2p통신은 같은 네트워크 환경에 있는 경우보다,
서로 다른 네트워크 환경에 있는 연결 상황에서 더 많이 사용됩니다.

동일한 네트워크에 속해 있는 경우에는 사설 IP를 통한 직접적인 p2p 통신이 가능하지만,
서로 다른 네트워크 환경에 위치한 경우에는 각자의 사설 IP만으로는 직접 연결이 불가능합니다.

이러한 네트워크 제약을 해결하기 위해 등장한 것이 바로 STUN과 TURN 서버입니다.

 

이러한 서버들은 NAT 뒤에 있는 장치들이 인터넷을 통하여 서로 통신할 수 있도록 도와주는 역할입니다.

STUN(Session Traversal Utilities for NAT)

STUN는 우리의 기기가 현재 나는 어디 있어?라고 물어볼 때 대답해 주는 서버입니다.

NAT 환경에서는 Private IP를 별도로 가지고 있기 때문에 p2p 통신이 불가능합니다.

따라서 클라이언트는 자신의 Public IP를 확인하기 위해 STUN 서버로 요청을 보내서 서버로부터 자신의 Public IP를 받아옵니다.

TURN(Traversal Using Relays around NAT)

TURN는 직접적인 연결이 불가능할 때, 중계 서버를 통해 데이터를 대신 전달하는 방식입니다.

이러한 TURN 서버는 STUN 서버로 해결할 수 없는 상황에서 사용됩니다.

일부 NAT은 외부 서버와의 직접적인 p2p 연결을 무조건적으로 막는다.

 

TURN 서버는 중계 서버를 거쳐 연결을 하기 때문에 상대적으로 느리지만, 보다 정확한 중계 서비스를 제공합니다.

 

그렇기 때문에 WebRTC는 보통 

1. STUN으로 가자~ 잘되네? ㅇㅋ 이걸로 확정!
2. STUN이 안되네.... 그럼 TURN 사용하자

이러한 방식으로 사용됩니다. 마치 TURN은 그저 차선책에 불과한 취급을 받고 있죠. 맞긴 해~

즉, 먼저 STUN을 사용해 보고 안된다면 TURN을 사용하는 방식입니다.

 

이번 글에선 간단한 정의, 동작조건, 통신 원리, 주요 개념과 용어 등을 알아봤습니다.
다음 글을 통해선 WebRTC의 동작 원리와 한계점, 그리고 해결책을 알아보겠습니다.