2월 19일 여정 70일차이다.

오늘은 실전프로젝트에서 구현하게 될 Web RTC의 이론에 대해 간단하게 알아보고자 한다.

오늘의 Today I Learned

Web RTC

WebRTC(Web Real-Time Communication)란 웹 브라우저 환경 및 Android, IOS 애플리케이션에서도 사용 가능한 비디오, 음성 및 일반 데이터가 피어간에 실시간으로 전송되도록 지원하는 오픈 소스이다.

Web RTC 기술 및 프로토콜

ICE(Interactive Connectivity Establishment)

브라우저가 peer를 통한 연결이 가능하도록 해주는 프레임 워크이다.
peer간 단순 연결 시 작동하지 않는 이유들은 다음과 같다.

• 연결을 시도하는 방화벽을 통과해야 함

• 단말에 Public IP가 없다면 유일한 주소값을 할당해야 한다.

• 라우터가 peer간의 직접 연결을 허용하지 않을 때 데이터를 릴레이해야 하는 경우

ICE는 위의 작업들을 수행하기 위해 STUN과 TURN 서버 둘 다 혹은 하나의 서버를 사용한다.

STUN(Session Traversal Utilities for NAT) 서버

• 클라이언트 자신의 Public Address(IP:PORT)를 알려준다.

• peer간의 직접 연결을 막는 등의 라우터의 제한을 결정하는 프로토콜이다. (현재 다른 peer가 접근 가능하지 여부 결정)

• 클라이언트는 인터넷을 통해 클라이언트의 Public Address와 라우터의 NAT 뒤에 있는 클라이언트가 접근 가능한지에 대한 답변을 STUN서버에 요청한다.

NAT(Network Address Transilation)

• 단말기에 공개 주소 할당을 하기 위해 사용한다.

• 라우터는 공개 IP 주소를 갖고 있고 모든 단말들은 라우터에 연결되어 있으며 비공개 IP주소(Private IP Address)를 갖는다.

• 요청은 단말의 비공개 주소로부터 라우터의 공개 주소와 유일한 포트를 기반으로 번역한다. 이 덕분에, 각각의 단말이 유일한 공개 IP 없이 인터넷 상에서 검색 가능하다.

• 몇몇의 라우터들은 Symmetric NAT이라고 불리우는 제한을 위한 NAT을 채용한다. 즉, peer들이 오직 이전에 연결한 적 있는 연결들만 허용한다. 따라서 STUN서버에 의해 공개 IP주소를 발견한다고 해도 모두가 연결을 할수 있다는 것은 아니다. (위의 설명에서 STUN 서버에 다른 peer가 접근 가능한지 여부를 요청하는 이유)

• 이를 위해 TURN이 필요하다.

TURN(Traversal Using Relays around NAT) 서버

• TURN 서버와 연결하고 모든 정보를 그 서버에 전달하는 것으로 Symmetric NAT 제한을 우회하는 것을 의미한다.

• 이를 위해 TURN 서버와 연결을 한 후 모든 peer들에게 저 서버에 모든 패킷을 보내고 다시 나(TURN서버)에게 전달해달라고 해야 한다.

• 명백히 오버헤드가 발생하므로 이 방법은 다른 대안이 없을 경우만 사용해야 한다.

참고 자료 : https://millo-l.github.io/WebRTC-%EC%9D%B4%EB%A1%A0-%EC%A0%95%EB%A6%AC%ED%95%98%EA%B8%B0/

마지막으로

이론부터 무지막지한 녀석이다. 상당히 어려운 것을 알 수 있다...