WebRTC란,
서버와 같은 중간자를 거치지 않고 브라우저 간 P2P로 연결되어 오디오나 영상 미디어를 교환할 수 있도록 하는 기술이다.
화상 통화, 실시간 스트리밍, 파일 공유, 스크린 공유 등이 WebRTC를 기반으로 하고 있다.
중개 서버를 거치지 않기 때문에 빠른 속도가 보장되며, HTTPS가 강제되기 때문에 중간자 공격에 대한 보안이 보장된다.
단점으로는 브라우저와 플랫폼 간 호환성을 말할 수 있다.
WebRTC는 구글이 주도한 오픈소스 프로젝트를 기반으로 하는 웹 표준이기 때문에 크롬이 호환성이 가장 높다. 파이어폭스와 오페라도 적극적으로 후원하고 있다. 사파리 역시 지원되기는 하지만 다른 브라우저에 비해 호환성이 가장 떨어지고 지원도 적다.
WebRTC는 P2P 방식의 커뮤니케이션이기 때문에 다음과 같은 절차를 밟아야 한다.
- 각 브라우저 P2P 커뮤니케이션 동의
- 서로의 주소 공유
- 보안 사항 및 방화벽 우회
- 멀티미디어 데이터 실시간 교환
단순히 공인 IP만을 알아낸다고 해서, 특정한 사용자를 가리킬 수는 없다.
공인 IP뿐만 아니라 해당 네트워크에 연결된 사설 IP 주소까지 알아내야 특정한 사용자를 지정할 수 있게 된다.
일반적으로 라우터가 NAT 역할을 한다.
하지만 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어 있을 수도 있다. 이처럼 라우터를 통과해서 연결할 방법을 찾는 과정을 NAT 트래버셜(NAT traversal)이라고 한다.
STUN 방식 vs TURN 방식
이 NAT 트래버셜 작업은 STUN(Session Traversal Utilities for NAT) 서버에 의해 이루어진다. STUN 방식은 단말이 자신의 공인 IP 주소와 포트를 확인하는 과정에 대한 프로토콜이다.
즉, STUN 서버는 인터넷의 복잡한 주소들 속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환해준다.
WebRTC 연결을 시작하기 전에 STUN 서버를 향해 요청을 보내면, STUN 서버는 NAT 뒤에 있는 피어(Peer)들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아준다.
그러나 STUN 서버를 이용하더라도 항상 자신의 정보를 알아낼 수 있는 것은 아니다. STUN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우, TURN(Traversal Using Relay NAT) 서버를 대안으로 이용하게 된다.
TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 것이다. TURN 방식은 중간에 서버를 한 번 거치기 때문에, 엄밀히 이야기하자면 P2P 통신이 아니게 되며 그 구조상 지연이 발생하게 된다. 하지만 보안 정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P 통신을 할 수 있는 유일한 방법이기 때문에, TURN 방식은 최후의 수단으로 선택되어야 한다.
STUN 서버를 이용해서 획득한 IP 주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소들을 후보(Candidate)라고 부른다. 그리고 이 과정을 후보 찾기(Finding Candidate)라고 부른다.
이렇게 후보들을 수집하면 일반적으로 3개의 주소를 얻게 된다.
- 자신의 사설 IP와 포트 넘버
- 자신의 공인 IP와 포트 넘버 (STUN, TURN 서버로부터 획득 가능)
- TURN 서버의 IP와 포트 넘버 (TURN 서버로부터 획득 가능)
이 모든 과정은 ICE(Interactive Connectivity Establishment)라는 프레임워크 위에서 이루어진다. ICE는 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크이다.
webRTC의 한계는
1. 브라우저 간 호환성
2. 개발자의 능력과 자율성에 맡겨지기 때문에 혼란이 올 수 있다.
3. UDP 위에서 동작하는데 빠르게 전송될 순 있지만 이 과정에서 데이터 손실이 발생할 수도 있다.
