WebRTC 3 : 다음 스텝을 위한 개념정리

지난 시간의 개념을 정리하는 겸,

공부를 더 이어가기 전에 먼저 알아두면 좋은 용어와 개념에 대해서 정리를 해보겠습니다:)

NAT(Network Address Translation)

NAT는 '네트워크 주소 변환'으로 IP 패킷에 있는 출발지와 목적지의 IP주소와 TCP/UDP 포트 숫자 등을 바꿔 재기록하면서 네트워크 트래픽을 주고 받는 기술이다.

자세히 설명하자면, 각 기기에는 자신만의 identifier(IP)가 있는데, 이건 같은 컴퓨터 네트워크상에서 유효하다. 즉, 회사망/내부망인 LAN은 Private IP를 사용하기 때문에 다른 네트워크(인터넷 웹사이트 방문 등)에서는 통용되지 않는다. 그렇기 때문에 우리가 통상적인 네트워크에서 데이터를 주고 받기 위해서는 Public IP가 필요하다. NAT는 Private IP를 Public IP로 1:1 대응시켜 변환하는 장치를 말한다.

마찬가지로 WecRTC 통신도 P2P 방식으로 서로 데이터를 주고 받아야 하기 때문에 보내고 받는 Peer의 정보(Public IP)를 알고 있어야 한다. 하지만 단순한 NAT 환경은 WebRTC 통신에 많은 문제를 야기시킨다. 예를 들어 통신상의 안정성이나 방화벽에 막히는 일 등 말이다. 어떻게 이 문제를 해결할까? 이를 해결하기 위한 것이 ICE, STUN, TURN 서버를 사용하는 것이다. WebRTC에서는 ICE를 써보고 안되면 STUN, 안되면 TURN 식으로 연결의 안정성을 지향한다.
ICE(Interactive Connectivity Establishment)

모든 단말은 환경이 다양하기 때문에 Peer A에서 Peer B까지 단순하게 연결되지 않는다. 방화벽이 존재하는 환경에서는 방화벽을 통과해야 하고 단말의 Public IP가 없다면 유일한 주소값을 할당해야 하며, 라우터가 Peer 간의 직접연결을 허용하지 않을 때는 데이터를 릴레이해야 한다. 하지만 ICE 프로세스를 사용하면 NAT가 통신을 하기 위해 필요한 모든 포트를 열어둬서 두 엔드 포인트 모두 다 연결할 수 있는 IP주소, 포트에 대한 완전한 정보를 가지게 된다. 결국 요청하는 클라이언트와 미디어 서버 사이의 연결을 통해 미디어, 데이터 등을 주고 받을 수 있는 것이다. 이런 ICE는 혼자 작동하지 않으며 STUN, TURN 서버를 사용해야 한다. WebRTC 애플리케이션은 이런 문제를 해결하기 위해 ICE 프레임워크를 사용한다. 특별히 우리가 RTCPeerConnection 객체를 생성할 때 ICE Server URLs을 우리 앱이 Pass하도록 해야 한다.

ICE 프레임워크는 기본적으로 두 단말 간이 서로 통신할 수 있는 최적의 경로를 찾을 수 있도록 도와주는 프레임워크다. 같은 선상에 있는 다른 모든 가능성들을 시도하고 그 중에 가장 효율적이고 효과적인 옵션을 선택한다. 두 Peer은 그들의 ice candidate를 다른 peer에게 보내게 된다.

프로세스는 이런데,
1) ICE Framework는 동작하고 있는 단말로부터 얻은 host adress를 사용해서 connection 생성을 시도한다.
2) 만약 이게 작동하지 않는다면, STUN 서버가 external (public) network adress를 얻는게 사용된다.
3) 만약 다이렉트 P2P Direct Connection이 실패하면(위의 것도 실패하면), TURN 서버는 트래픽을 relay하는데 사용된다.
STUN(Session Traversal Utility for NAT)

공개 주소를 발견하거나 peer간의 직접 연결을 막는 등 라우터의 제한을 결정하는 ICE를 보완하는 프로토콜이다. 간단하게 말하면 STUN 서버는 해당 Peer의 공인(Public) IP 주소를 보내는 역할을 한다. STUN은 두 엔드 포인트 간의 연결을 확인하고 NAT 바인딩을 유지하기 위한 연결 유지 프로토콜로도 사용될 수 있다. 하지만 항상 효과적이지는 않다. 두 단말이 같은 NAT 환경에 있을 경우 또는 NAT 보완정책이 엄격한 경우 등에는 사용이 어려운 경우가 있다.
TURN(Traversal Using Relays around NAT)

STUN의 확장으로 NAT 환경에서 릴레이하여 통신을 하게 한다. NAT 보완정책이 너무 엄격하거나 NAT 순회를 하기 위해 필요한 NAT 바인딩을 성공적으로 생성할 수 없는 경우에 TURN을 사용한다. 이 서버는 인터넷망에 위치하고 각 Peer들이 Private IP 안에서 통신한다. 각 Peer들이 직접 통신하는 것이 아니라 릴레이 역할을 하는 TURN 서버를 사용하고 경유한다.

TURN은 이러한 릴레이로부터 IP주소와 포트를 클라이언트가 취득할 수 있는 릴레이 주소를 할당한다. 하지만 장점만 있는게 아니다. 클라이언트와의 연결을 거의 항상 제공하지만 STUN에 비해 리소스 낭비가 심하다. 때문에 ICE Candidate 과정에서 Local IP로 연결할 수 있는지, Public IP로 연결할 수 있는지 등 모든 후보군을 찾은 후 알아낸 최후의 수단으로 사용해야 한다.
ICE Candidate Gathering

Local Address, Server Reflexive Address, Relayed Address 등 통신 가능한 주소들을 모두 가져온다. 이 주소들 중 가장 최적의 경로를 찾아서 연결시켜준다.
SDP(Session Description Protocol)

세션 기술 프로토콜(Session Description Protocol, SDP)은 스트리밍 미디어의 초기화 인수를 기술하기 위한 포맷이다. SDP는 세션 공지, 세션 초대, 그리고 그 밖의 멀티미디어 세션 초기화를 위한 폼들을 목적으로 멀티미디어 세션들의 기술을 위해 작성되었다. SDP는 미디어 폼의 콘텐츠 그 자체를 위해서 제공된 것은 아니지만, 양 끝단 간에 미디어 타입과 포맷에 대해 협상할 수 있는 수단을 제공한다. 이로 인해서 SDP는 새롭게 추가되는 미디어 타입과 포맷을 지원할 수 있으며, 앞으로 나올 기술에 대한 호환성을 시스템적으로 지원할 수 있다.
UDP / TCP

TCP는 Transmission Control Protocol의 약자이고, UDP는 User Datagram Protocol의 약자이다. 두 프로토콜은 모두 패킷을 한 컴퓨터에서 다른 컴퓨터로 전달해주는 IP 프로토콜을 기반으로 구현되어 있지만, 서로 다른 특징을 가지고 있다.

TCP는 네트워크 계층 중 전송 계층에서 사용하는 프로토콜로서, 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 연결을 설정하여 신뢰성을 보장하는 연결형 서비스 이다. TCP는 네트워크에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟(데이터, 메세지, 세그먼트라는 블록 단위)를 안정적으로, 순서대로, 에러없이 교환할 수 있게 한다. 반면 UDP는 수신자가 데이터를 받는지 마는지 관심이 없기 때문이다. 즉, 신뢰성을 보장해주지 않지만 간단하고 속도가 빠른 것이 특징이다.