[WebRTC] TURN 서버의 필요성

WebRTC 기술을 사용해 음성 애플리케이션을 만들어 테스트하는 중 P2P 연결이 잘 안 되는 문제가 있었다.

원인을 찾아보려고 코드를 계속 수정했지만 실행이 되지 않았다.

그러던 중 LTE를 사용하고 있던 Test 폰을 와이파이를 연결해보니 잘 동작했었고, LTE 환경에서 P2P 연결이 안 된다는 것을 알 수 있었다!!

🧐 Why?

WebRTC에서 P2P 연결을 위해

최적의 ICE를 찾으며 연결해야할 사용자에게 갈 수 있는 최적의 네트워크 경로를 찾는다.

이때 최적의 경로는 어떻게 찾게 되는 걸까?

보통은 NAT환경에 있는 사용자를 찾기 위해 STUN서버를 사용하고 이를 통해 NAT 뒤의 종단(사용자)을 파악할 수 있다.

하지만 이때 STUN 서버를 거쳐도 NAT 뒤에 누군가가 있는지 (IP정보가 무엇인지) 알 수 없는 상황이 오면 어떻게 해야 할까?

보통 이러한 문제적인 상황은 Symmetric NAT 환경에서 나타난다.

Symmetric NAT이란?

The recent proliferation of symmetric NATs has reduced NAT traversal success rates in many practical situations, such as for mobile and public WiFi connections.
최근 Symmetric NAT의 확산이 NAT traversal 성공 확률을 감소시키고 있다.

=> 모바일이거나 public WIFI 연결 같은 상황에서
Hole punching techniques, such as STUN and ICE, fail in traversing symmetric NATs without the help of a relay server, as is practiced in TURN.
STUN과 ICE와 같은 기술은 relay server 없이 Symmetric NAT에서 실패한다. TURN서버가 필요하다

Port prediction techniques are only effective with NAT devices that use known deterministic algorithms for port selection.

포트 예측 기술은 오직 포트 선택을 위한 결정 알고리즘을 사용하는 NAT 디바이스에서만 효과가 있다.
This predictable yet non-static port allocation scheme is uncommon in large scale NATs such as
those used in 4G LTE networks and therefore port prediction is largely ineffective on those mobile broadband networks.

하지만 이러한 예측 가능한 체계는 대규모 NAT 환경 (4G 네트워크)에서는 평범한 것이 아니다.

참고 : www.wikipedia.org/

좀 더 쉽게 설명하자면,

접속하는 서버에 따라 외부 포트가 달라지고, 목적지에 따라 다른 공유기의 외부 IP:PORT를 갖는다는 것이다.

따라서 이러한 Symmetric NAT 환경인 LTE, 스타벅스 공인 WIFI와 같은 상황에 대비해 TURN 서버를 구축해놔야 한다.