WebRTC에 대해 공부하던 중, STUN과 TURN 서버가 직접 연결이 어려운 경우에 중계 역할을 한다는 내용을 접했고 그렇다면 직접 연결이 어려운 상황은 어떤 경우인지, 그때 TURN 서버가 어떻게 중계 역할을 수행하는지“에 대해 정리해보려 함
WebRTC에서 직접 연결이 어려운 상황, 이유
이유는 NAT (Network Address Translator) 이다. (네트워크 주소 변환자)
인터넷에 연결된 대부분의 디바이스는 공인IP = X / 사설 IP 사용
그렇기 때문에 외부에서는 디바이스의 정확한 위치를 알 수 없음
사설망과 공인망 사이에서 IP 주소를 변환해주는 기술이 바로 NAT다. 공인IP <-> 사설IP
NAT의 종류
-
FUll Cone NAT
가장 열려있는 NAT 외부에서 한번 연결된 포트를 통해 자유롭게 접근할 수 있음 -
Restricted Cone NAT / Port Restricted Cone NAT
특정조건에서만 사용 가능하며, 외부에서 접근은 제한적임 -
Symmetric NAT
내부에서 요청한 외부 주소/포트마다 새로운 매핑이 생성, 외부에서 접근이 매우 어려움 (가장 폐쇄적임)
문제점: 브라우저끼리 직접 연결(P2P) 어려움
WebRTC는 클라이언트 ↔ 클라이언트 간 직접 통신을 시도한다
하지만 대부분의 클라이언트는 NAT 뒤에 있어서 서로의 IP와 포트를 알 수 없고, 직접 연결이 불가능한 상황이 생김
그래서 STUN / TURN 서버를 활용해 해결을 할 수 있다.
역할과 시나리오
- STUN 서버
클라이언트의 공인 IP와 포트를 알아냄. (자신의 외부 주소를 확인함) - TURN 서버
STUN으로도 연결이 안 될 때, 중계 서버 역할을 수행 모든 데이터를 TURN 서버를 거쳐 전달
흐름
클라이언트 A와 B가 각각 STUN 서버에 접속 → 자신의 공인 IP/포트 확인
ICE 프로토콜이 두 클라이언트의 연결 가능성 테스트
연결 실패 시 → TURN 서버를 통해 A와 B가 간접적으로 통신
💡 결론
직접 연결이 이상적이지만, NAT나 방화벽 등 네트워크 제약으로 인해 불가능한 상황이 있다.
그럴 때, TURN 서버를 통해 데이터를 중계함으로써 WebRTC를 활용해 실시간 통신의 신뢰성과 연결성을 확보 가능함
