June 19th 2019
Contents
Node.js로 Signaling server를 구축하는 방법과 기본적인 WebRTC API에 대해서 이전 포스팅에서 살펴봤습니다.
Link: Simple video chat with WebRTC
Signaling server를 통해 일단 Client끼지 접촉을 하면, RTCPeerConnection은 media, data streaming을 위해 최대한 직접 소통하려 합니다.

하지만 실제 웹 애플리케이션이 동작하는 환경은 위와는 다릅니다. 웹 애플리케이션이 동작하는 디바이스 대부분은 하나 이상의 레이어 뒤에 위치해 있습니다. 이러한 레이어로는 NAT, 일부 Port와 Protocol을 차단하는 보안 소프트웨어가 있고, 많은 디바이스는 프록시 또는 방화벽 뒤에서 동작합니다. NAT와 firewall은 home wifi router와 같은 한 장치에 의해서 구축될 수도 있습니다.

WebRTC app은 이런 실제 웹 애플리케이션이 동작하는 네트워크 환경의 복잡성에서 오는 문제 극복을 위해 ICE framework을 사용합니다. 이를 위해서, 웹 애플리케이션은 RTCPeerConnection에 ICE server url을 전달해야 합니다.
ICE는 가장 효율적인 접근 방법을 찾습니다. 맨 먼저 클라이언트의 운영 시스템, 네트워크 카드로부터 얻은 호스트 주소로 연결을 시도합니다. 실패할 경우 아마 NAT 뒤에 있을 것이고, 이 경우 STUN 서버를 이용해 외부 주소를 이용합니다. STUN 서버를 통해서도 실패를 하면, TURN 서버를 통해 트래픽을 라우팅합니다.
위키피디아를 참고하면, Interactive Connectivity Establishment (ICE)는 컴퓨터 네트워킹 기술 중 하나이며, peer-to-peer 간 직접적인 커뮤니케이션 방법을 찾는 기술입니다. ICE는 Vioce over internet Protocol(VoIP), peer-to-peer 커뮤니케이션에서 일반적으로 사용됩니다. 이러한 애플리케이션에서 중앙 서버를 거처 커뮤니케이션 하는 것은 느리고 비싼 작업입니다. 그렇다고 하지만, 인터넷을 통해 브라우저 간 직접적인 소통을 하는 작업 또한 매우 까다로운 작업입니다. Network address translations(NATS), firewalls, 다른 네트워크 장벽 등으로 인해 연결이 막힐 수 있기 때문입니다.
ICE는 WebRTC에서 NAT를 우회하는 방법중 하나입니다. ICE는 local IP address, STUN, TURN으로부터 모든 가능한 candidate를 취합하고, 이 취합된 address를 SDP를 통해 remote peer에게 전달합니다. WebRTC client가 모든 ice address를 받으면, 연결 가능한 address를 찾게됩니다.