WebRTC를 사용하기 전, 기본적으로 익혀야 할 지식들!!
🌎 NAT(Network Address Translation)
'나'는 누구인지 '이름'으로 구별할 수 있듯, 각 기기에도 자신만의 이름이 있다.
그것이 바로 IP이고 이 IP는 고정IP, 유동IP 로 나뉘어서 실제 고유의 값일 수도 있고 아닐 수도 있다.
더 나아가서는 회사망/내부망(LAN)은 Private IP이기 때문에 다른 네트워크( 구글 홈페이지 접속, 일반적인 웹 사이트 접송) 등 다른 네트워크에서는 통용되지 않는다.
그렇기 때문에,
우리가 통상적인 네트워크에서 데이터를 주고 받기 위해서는 Public IP가 필요하다.
NAT는 Private IP를 Public IP로 1대1 대응시켜 변환하는 장치를 말한다.
또한, IP주소를 재기록 하면서 라우터를 통해 네트워크 트래픽을 주고받는 매커니즘이다.
(Public IP는 인터넷에 접근할 때 부여되고 사용하지 않으면 다른 사람에게 다시 공유되는 방식으로 돌고 돈다.
현재는 수많은 기기들로 인해 IPv4 -> IPv6도 함께 부여된다고 한다.)
하지만, WebRTC 통신은 Peer to Peer 방식으로 서로 데이터를 주고 받아야 하기 때문에 보내고 받는 Peer의 정보 ( Public IP )를 알고 있어야 한다.
그러나 Public IP는 요청을 보낼때마다 private IP -> public IP로 NAT에 의해 바뀌기 때문에 동일한 Public IP로 통신할 수 없는 문제점이 발생하게 된다.
NAT는 WebRTC 통신에 많은 문제를 야기시킨다.
현대의 네트워크 세상에선 NAT와 방화벽을 제외하고는 설명이 안된다.
그렇다면 우리는 어떻게 이 문제를 해결하고 WebRTC 를 사용하며 데이터를 주고 받을 수 있을까?
STUN, TURN 서버를 사용해서 문제를 해결할 수 있다.
NAT는 사설 네트워크(Private Network)에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위함.
즉, private ip 를 사용하고 있는 컴퓨터가 사설 바깥쪽에 있는 public ip에 해당되는 외부세계에 접속할 수 있게 된다.
이때 사용되는 기술이 바로 NAT 이다.
🌎 ICE(Interactive Connectivity Establishment)
ICE는 두 단말이 서로 통신할 수 있는 최적의 경로를 찾을 수 있도록 도와주는 프레임워크이다.
어떻게 최적의 경로를 찾을 수 있을까?
TURN , STUN 서버를 사용하여 최적의 경로를 찾을 수 있다.
왜 ICE를 사용해야하는가?
모든 단말은 각자의 환경(학교 내부망, 회사 내부망, 집의 네트워크 등 )이 다양하기에 Peer A에서 Peer B까지 단순하게 연결되지 않는다.
방화벽이 존재하는 환경에서는 방화벽을 통과해야하고 단말의 퍼블릭 IP가 없다면 유일한 주소값을 할당해야하고 라우터가 Peer간의 직접연결을 허용하지 않을 때는 데이터를 릴레이해야한다.
ICE 프로세스를 사용하면 NAT가 통신을 위해 필요한 모든 포트를 열어두고 두 엔드 포인트 모두 다 연결할 수 있는 IP주소, 포트에 대한 완전한 정보를 갖게된다.
결국, 요청하는 클라이언트와 미디어 서버사이의 연결을 통해 미디어(비디오, 음성)등을 주고 받을 수 있다는 것이다.
ICE 혼자는 작동하지 않으며 STUN과 TURN서버를 사용해야한다.
🌎 STUN(Session Traversal Utilities for NAT)
공개 주소를 발견하거나 peer간의 직접 연결을 막는 등 라우터의 제한을 결정하며 ICE를 보완하는 프로토콜이다.
간단하게 말하면 STUN 서버는 해당 Peer의 Public IP 주소를 보내는 역할을 한다.
STUN은 두 엔트 포인트 간의 연결을 확인하고 NAT 바인딩을 유지하기 위한 연결 유지 프로토콜로도 사용할 수 있다.
하지만, STUN은 항상 효과적이지는 않다.
두 단말이 같은 NAT 환경에 있을 경우 또는 NAT의 보안정책이 엄격하거나 등의 이유에 따라 STUN이 완벽한 해결책이 되지는 않는다.
🌎 TURN(Traversal Using Relays around NAT)
STUN의 확장으로 NAT 환경에서 릴레이하여 통신을 하게 된다.
NAT 보안 정책이 너무 엄격하거나 NAT 순회를 하기 위해 필요한 NAT 바인딩을 성공적으로 생성할 수 없는 경우에 TURN을 사용한다.
TURN 서버는 인터넷망에 위치하고 각 Peer(단말)들이 사설망(Private IP) 안에서 통신한다. 각 Peer들이 직접 통신하는 것이 아니라 릴레이 역할을 하는 TURN 서버를 사용하여 경유한다.
TURN은 이러한 릴레이로부터 IP주소와 포트를 클라이언트가 취득할 수 있는 릴레이 주소를 할당한다.
하지만, 이런 TURN에게 장점만 있는 것은 아니다.
클라이언트와의 연결을 거의 항상 제공하지만 STUN에 비해 리소스 낭비가 심하다.
그렇기 때문에, ICE Candidate과정에서 local IP로 연결할 수 있는지, Public IP로 연결할 수 있는지를 ( 모든 후보군을 찾은 후) 알아낸 후 최후의 수단으로 사용해야 한다.
🌎 ICE Candidate Gathering
Local Address, Server Reflexive Address, Relayed Address 등 통신 가능한 주소들을 모두 가져온다.
이 주소들 중 가장 최적의 경로를 찾아서 연결시켜준다.
📗 참고자료
doc-kurento.readthedocs.io/en/stable/glossary.html#term-nat
developer.mozilla.org/ko/docs/Web/API/WebRTC_API/Protocols
'WebRTC' 카테고리의 다른 글
| [WebRTC] Kurento를 사용하여 실시간 스트리밍하기 (3) | 2021.01.25 |
|---|---|
| [WebRTC] WebRTC를 공부하며 스트리밍 과정 익히기 (1) | 2021.01.16 |
| [Kurento] 쿠렌토 서버 Docker로 실행시켜보기 (feat. 윈도우) (1) | 2021.01.08 |
| [WebRTC] 쿠렌토(Kurento)는 무엇인가? (0) | 2021.01.07 |
| [WebRTC] WebRTC란 무엇일까? (0) | 2020.12.22 |