ICE(Interactive Connectivity Establishment)와 Candidate
위의 STUN, TURN 등으로 찾아낸 연결 가능한 네트워크 주소들을 Candidate(후보)라고 할 수 있다.
ICE라는 프레임워크에서 Finding Candidate(후보 찾기)를 한다.
보통 3종류의 후보들을 갖게되는데, 그 종류는 아래와 같다.
- [Direct Candidate] Local Address : 클라이언트의 사설 주소(Host Candidate), 랜과 무선랜 등 다수 인터페이스가 있으면 모든 주소가 후보가 됨
- [Server Reflexive Candidate] Server Reflexive Address : NAT 장비가 매핑한 클라이언트의 공인망 주소로 STUN에 의해 판단한다.
- [TURN relay Candidate] Relayed Address : TURN서버가 패킷 릴레이를 위해 할당하는 주소
즉, ICE는 (2개의) peer끼리 P2P 연결을 가능하게 하도록 최적 경로를 찾아주는 프레임워크다.
SDP(Session Description Protocol)
ICE를 통해 우리는 확실히 P2P 통신을 할 수 있는 주소 후보들을 찾았다. 이제 정보들을 서로 주고받게 만들어줘야 하는데, 이 때 쓰이는 것이 SDP다.
SDP(Session Description Protocol)는 WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위한 프로토콜이다. 비디오의 해상도, 오디오 전송 또는 수신 여부 등을 송수신 할 수 있다.
이처럼 미디어와 관련된 초기 세팅 정보를 기술하는 SDP는 응답 모델(Offer/Answer)을 갖고 있다고 한다. 그러니까 어떤 피어가 이러한 미디어 스트림을 교환할 것이라고 제안을 하면, 상대방으로부터 응답이 오기를 기다린다는 의미다. 그렇게 응답을 받게 되면, 각자의 peer가 수집한 ICE 후보 중에서 최적의 경로를 결정하고 협상하는 프로세스가 발생하고 수집한 ICE 후보들로 패킷을 보내 가장 지연 시간이 적고 안정적인 경로를 찾는 것이다. 이렇게 최적의 ICE 후보가 선택되면, 기본적으로 필요한 모든 메타 데이터와 IP 주소 및 포트, 미디어 정보가 피어 간 합의가 완료된다.
이 과정을 통해 피어 간의 P2P 연결이 완전히 설정되고 활성화된다. 그 후 각 피어에 의해 로컬 데이터 스트림의 엔드포인트가 생성되며, 이 데이터는 양방향 통신 기술을 사용하여 최종적으로 양방향으로 전송된다. 이 과정에서 NAT의 보안 이슈 등으로 최선의 ICE 후보를 찾지 못할 수도 있기 때문에, 이때에는 폴백으로 세팅한 TURN 서버를 P2P 대용으로 설정한다. 통신에 TURN 폴백을 사용할 때 각 피어는 굳이 귀찮게 P2P로 데이터를 연결하고 전송하는 방법을 알 필요가 없다. 대신, 통신 세션 중에 실시간 멀티미디어 데이터를 중개하는 공용 TURN 서버를 알고 있어야한다.
Trickle ICE(물방울 ICE)
일반적으로 각 peer들은 ICE 후보들을 수집해서 그 목록을 완성한 후 한꺼번에 교환하게 된다. 하지만 이러한 방식은 SDP의 제안 응답 모델과 맞물리면서 단점으로 작용한다. 후보를 모으는 데에도 시간이 오래 걸리고, 그 과정에서 네트워크 환경에 따라 지연이 될 수 있다. 또, 한 쪽 peer의 ICE 후보 수집 작업이 완료되어야만 다른 peer가 ICE 후보를 모을 수 있기 때문에 비효율적이라고 한다.
이러한 비효율적인 후보 교환 작업을 병렬 프로세스로 수행할 수 있게 만드는 것이 바로 Trickle ICE다. 두 개의 peer들이 ICE 후보를 수집하고 교환하는 과정을 동기적 프로세스에서 비동기적 프로세스로 만드는 기술이라고 할 수 있다.
즉, Trickle 옵션이 활성화된 ICE 프레임워크는 각 peer에서 ICE 후보를 찾아내는 그 즉시 교환을 시작한다. 그래서 상호 간 연결 가능한 ICE를 보다 빨리 찾아낼 수 있다. 이러한 옵션 덕분에 ICE 프레임워크는 피어 간의 연결 상태를 체크함과 동시에 연결에 걸리는 시간을 최적화할 수 있다. 결론적으로 Trickle 옵션은 가능하다면 활성화하는 게 좋다고 한다.
Signalling
위의 설명한 일련의 과정을 시그널링이라고 한다. 시그널링은 WebRTC 자체에서 지원하는 기능은 아니라서, 미리 준비해야 하는 과정이라고 한다. 시그널링은 WebRTC 자체의 스펙도 아니기 때문에, 한 가지로 딱 정해진 방법이 없다. 정해진 방법이 없는 이유는 알 수 없는 두 장치가 언제 어떤 방식으로 연결될 수 있는지의 모든 경우를 예측하는 것이 불가능하기 때문다. 그래서 개발자는 자신에게 맞는 최적의 방법을 선택적으로 적용해야 한다.
이 때문에 일반적으로 두 개의 장치를 연결할 수 있는 시그널링 서버를 직접 구축하거나, 시그널링 서버를 제공해주는 외부 솔루션을 적용할 수 있다. 만약 시그널링 서버를 직접 구축한다면 웹 소켓(Web Socket)이나 서버 전송 이벤트(Server-sent Event) 방법을 적용할 수 있다.
여러 시그널링 방법에 대해 여기 깃을 참고하자. https://github.com/muaz-khan/WebRTC-Experiment/blob/master/Signaling.md
시그널링 서버를 제공해주는 솔루션을 쓰는 것도 방법이 될 수 있다고 한다. 아마존의 Kinesis Video Stream 이 대표적인 예이고, 구글의 AppRTC에서는 Google App Engine으로 구현된 시그널링 서버를 확인할 수 있다.
