P2P(peer-to-peer) vs Client-Server

P2P network

• 서버 없이 클라이언트들끼리 상대방과 통신하는 네크워크로, 중앙 집중화된 서버가 존재하지 않는다. (모두가 클라이언트)
• 따라서 상대방과 통신을 하고 싶다면 연결된 모든 줄을 통해 모두 메시지를 전송해야 한다. (각 클라이언트가 소켓을 모두 뚫고 직접 관리해야 함)

Client-Server

• Client-server 모델을 기반으로하는 네트워크로, 각각의 클라이언트들이 중앙 집중화된 서버에게 요청을 보낸다.

P2P와 블록체인

• 블록체인은 관리 대상 데이터를 '블록'이라고 하는 소규모 데이터들이 P2P 방식을 기반으로 생성된 체인 형태의 연결고리 기반 분산 데이터 저장 환경에 저장하여 누구라도 임의로 수정할 수 없고 누구나 변경의 결과를 열람할 수 있는 분산 컴퓨팅 기술 기반의 원장 관리 기술이다.
• 근본적으로 분산 데이터 저장기술의 한 형태로, 지속적으로 변경되는 데이터를 모든 참여 노드에 기록한 변경 리스트로서 분산 노드의 운영자에 의한 임의 조작이 불가능하도록 고안되었다.
• 블록체인 기술은 비트코인을 비롯한 대부분의 암호화폐 거래에 사용되며, 암호화폐의 거래과정은 탈중앙화된 전자장부에 쓰이기 때문에 블록체인 소프트웨어를 실행하는 많은 사용자들의 각 컴퓨터에서 서버가 운영되어, 중앙에 존재하는 은행 없이 개인 간의 자유로운 거래가 가능하다.
  

WebRTC

WebRTC

• Original author(s): Justin Uberti & Peter Thatcher
  • 구글이 2010년 인수한 GIPS사 소속 개발자
  • 구글은 2011년 WebRTC로 개명후 오픈소스로 공개하였다.
  • IETF를 통한 표준화 및 W3C를 통한 브라우저 API가 이루어졌다.
• Initial release: 2011
• Repository: webrtc.googlesource.com
• Written in: C++, JavaScript
• License: BSD license
• Support: 데스크탑 및 모바일 브라우저에서 대부분 지원한다.

WebRTC API의 목적

• WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 스트림할 수 있으며, 임의의 데이터도 교환할 수 있도록 하는 기술이다.
• WebRTC를 구성하는 일련의 표준들은 플러그인이나 제 3자 소프트웨어 설치 없이 종단 간 데이터 공유와 화상 회의를 가능하게 한다.
• 이를 위하여 WebRTC는 상호 연관된 API와 프로토콜로 구성되어 함께 작동한다.

대표적인 API

• RCTPeerConnection() : peer간에 오디오와 영상 통신이 가능하도록 연결하는 API
• getUserMedia() : 디바이스의 카메라나 마이크 등에 접근하여 오디오와 영상 등을 캡처해서 가져오는 API
• RTCDataChannel() : peer간에 데이터를 주고 받을 수 있도록 해주는 API

WebRTC 기술

ICE (Interactive Connectivity Establishment)

• ICE는 브라우저가 peer를 통한 연결이 가능할 수 있게 해주는 프레임워크이다.
• Peer A에서 Peer B까지 단순하게 연결하는 것으로는 작동하지 않는 이유들:
  • 연결을 시도하는 방화벽을 통과해야 할 수 있다.
  • 단말에 Public IP가 없다면 유일한 주소 값을 할당해야 할 필요도 있다.
  • 라우터가 peer간의 직접 연결을 허용하지 않을 때에는 데이터를 릴레이해야 할 경우도 있다
• ICE는 이러한 작업을 수행하기 위해 STUN 서버와 TURN 서버를 사용한다.

STUN (Session Traversal Utilities for NAT)

• STUN은 통신 요청자(본인)의 Public IP를 확인하거나 본인의 라우터가 peer 간의 직접 통신에 제약을 두고 있는지를 확인하기 위한 프로토콜이다.
• 클라이언트로부터 요청을 받은 인터넷 상의 STUN 서버는 클라이언트의 Public IP 주소와 함께 해당 클라이언트가 라우터의 NAT 뒤에 위치한 상황에서 통신을 위한 접근의 가능 여부를 알려준다.
  

NAT (Network Address Translation)

• NAT는 Private IP를 사용하는 클라이언트가 Public IP를 사용할 수 있도록 하는 기술로, 송수신되는 메시지의 Private IP 주소 값과 Public IP 주소 값을 실시간으로 매핑/번역한다.
• 특정 라우터들은 NAT을 통한 네트워크 연결에 제한을 가지고 있다.
  예) symmetric NAT 방식을 지원하는 라우터는 이전에 연결한 적이 있는 연결들(혹은 미리 설정된 연결들)에 대해서만 NAT을 지원한다.
• 그러므로 STUN 서버에 의해 Public IP 주소를 알게 되더라도 모두가 연결할 수 이는 것은 아니다. => TURN이 필요하다.

TURN (Traversal Using Relays around NAT)

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

SDP (Session Description Protocol)

• SDP는 해상도나 형식, 코덱, 암호화등의 멀티미디어 컨텐츠의 연결을 설명하기 위한 표준이다.
• 디바이스간의 미디어 공유를 위한 연결을 설명할 때 사용된다.

WebRTC 동작 구성

P2P라고 하더라도 제어 과정(NAT 통과를 위한 STUN, TURN 서버)과 연결 설정(Signaling을 위한 Signaling server)에서는 서버가 사용된다. 그러나 데이터(음성, 오디오, 영상 등)는 Peer끼리 직접 주고 받는다.

WebRTC는 UDP 기반으로 돌아가며, 그 위에 SRTP(오디오, 영상 등의 전송을 위한 실시간성O), SCTP(데이터 전송)를 올려서 오류 검출 및 복구가 수행되도록 한다.

WebRTC의 장단점

WebRTC의 장점

• Near Real-time : WebRTC는 UDP 기반으로, 화상 회의가 가능하도록 만들어진 것이기 때문에 실시간성에 가깝다고 볼 수 있다.
• Inherently Low Latency : WebRTC를 사용할 경우 지연시간이 짧다. WebRTC를 이용하여 카메라로 영상을 포착하여 상대방의 모니터에 보이기까지(glass-to-glass latency) 약 500ms가 소요된다. 음성일 경우에는 약 100ms가 소요된다.
• Platform and Device Independence : WebRTC는 웹 브라우저 기반으로 돌아가기 때문에 플랫폼과 장치의 종류는 상관이 없다.
• Open Source and Standardized : WebRTC는 표준화가 되어있기 때문에 표준 문서대로만 구현하면 누구든 연결할 수 있으며, 오픈 소스이기 때문에 다양하게 활용할 수 있다.
• Adapts to Network Conditions : WebRTC는 simulcasting(비디오 전송 방식 중 하나로 특정 해상도의 영상을 보내는 것이 아니라, 모든 해상도의 영상을 보내서 클라이언트가 원하는 해상도를 선택하여 받을 수 있는 방식)이라는 전송 방식을 사용하여 네트워크 상황에 맞춰 원하는 해상도의 영상을 받을 수 있도록 한다.

WebRTC의 단점

• Scalability : WebRTC에서 데이터는 상대방과 직접 연결을 해서 전송되기 때문에 데이터를 직접 보낼 수 있는 유저의 수(연결 개수)는 제한된다. (최대 50개의 연결까지 유지하도록 권고됨)
  • Solution : Live streaming이나 세미나 등으로 일방적인 발화의 상황이 진행되는 경우에는 HLS(HTTP Live Streaming)과 같이 서버를 두고 그 서버에서 분산해서 제공하는 방식을 사용하면 연결의 수를 늘릴 수 있다.
• Broadcast Quality : WebRTC를 사용하는 경우에는 비트레이트 제한으로 인해 화질이 좋지 않다는 오해가 있으나, 네트워크와 카메라 사양 등의 문제로 인한 것이지 WebRTC로 인해 발생하는 문제는 아니다.