WebRTC 내용 정리

기존의 p2p방식은 Dirty P2P -> 너무  무거움

클라이언트들이 서버 없이, 클라이언트들끼리 연결되어 통신 -> 다른 클라이언트에 대한 정보 다 가지고 있어야 한다.

Client-Server : 중앙집중화된 역할 하는 서버 존재. 내가 채팅 친 것을 다른 애들한테 전달하는 걸 서버에 위임

p2p의 다른 형태를 가져가서 만든 것이 블록체인

• p2p방식을 기반으로 생성된 체인 형태의 연결고리 기반 분산 데이터 저장 환경에 저장하여 누구라도 임의로 수정할 수 없고 누구나 변경의 결과를 열람할 수 있는 분산 컴퓨팅 기술 기반의 원장 관리 기술임
• 지속적으로 변경되는 데이터를 모든 참여 노드에 기록한 변경 리스트. 분산 노드의 운영자에 의한 임의 조작이 불가능하도록 고안됨
• 누군가가 결제를 만들고 블록체인은 이 결제에 대한 파일을 뿌린다. 이 결제가 제대로 된 것인지에 대한 페이킹 검증을 하고 이에 대한 대가를 받는 것이 코인. 그 다음 블록이 블록체인에 추가됨.

Web RTC (Web Real Time Communication)

• 실시간 통신 기능을 어플리케이션에 추가
• 영상, 음성, 데이터를 피어간에 통신 가능하도록 만들어놨음.
• 목적
  • 웹 어플리케이션과 사이트가 중간자 없이 브라우저 간에 오디어나 영상 미디어를 스트림하고, 임의의 데이터를 교환할 수 있도록 하는 기술
  • WebRTC를 구성하는 일련의 표준들은 플러그인이나 제 3자 소프트웨어 설치 없이 종단 간 데이터 공유와 화상 회의를 가능하게함 → 이를 위하여 WebRTC는 상호 연관된 API와 프로토콜로 구성되어 함께 작동.

대표적인 3개의 API를 포함한 JavaScript API들로 이루어짐.

• RTCPeerConnection() - peer들 사이에서 오디오나 비디오 통신이 가능하도록함. peer-to-peer communication, 보안, codec handling 등 다함
• getUserMedia() - audio와 video media를 가져오는 api
• RTCDataChannel() - peer들 사이에서 임의의 데이터의 양방향 통신 allow해주는 api

ICE (Interactive Connectivity Establishment)

: 브라우저가 peer를 통한 연결이 가능하도록 해주는 프레임워크

• 인터넷 가로지를 때 문제점
  • 연결을 시도하는 방화벽을 통과해야 함. private ip가 방화벽 뚫고 나가기 어렵
  • 단말에 public ip가 없다면 유일한 주소 값을 할당해야 할 필요가 있음.
  • 나갈 때 본인은 자신의 public ip를 알지 못함.
  • 라우터가 peer간의 직접 연결을 허용하지 않을 때에는 데이터를 릴레이 해야할 경우도 있음.

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

• STUN(Session Traversal Utilities for NAT)
  • public ip 확인하거나 라우터가 통신에 제약두고 있는지 확인하기 위한 프로토콜
  • 클라이언트가 NAT뒤에 있는 경우에도 아이디 알 수 있게 해준다.
• but, 어떠한 라우터들은 NAT를 통한 네트워크 연결에 제한을 갖고 있음. → symmetric NAT방식을 지원하는 라우터는 이전에 연결한 적이 있는 연결들(혹은 미리 설정된 연결들) 에 대해서만 NAT를 지원.
• stun서버만으로 nat를 통과할 수 없다. → public ip를 알아내도 모두가 연결할 수 있는게 아님. 이를 위해 TURN이 필요함.
• TURN(Traversal Using Relays around NAT)
  • TURN서버와 연결하고 모든 정보를 그 서버에 전달해 Symmetric NAT제한을 우회한다.
  • 얘는 트래픽을 뚫는 대리자를 서버로 두는 것.
  • 모든 peer들에게 저 서버에 모든 패킷을 보내고 다시 나에게 전달해달라 한다 -> 연결 한 것으로 취급된다.
  • 하지만 TURN의 경우 명백히 오버헤드가 존재해서 다른 대안이 없을 경우만 사용.

SDP(Session Description Protocol) : 해상도나 형식, 코덱, 암호화 등의 멀티미디어 컨텐츠의 연결을 설명하기 위한 표준

SDP는 형태를 얘기하고 SIP를 해서 전화 음성을 주고 받을때 코덱을 SDP를 사용함. 실제로는 SIP와 SDP를 페어로 많이 쓰지만 문서에는 SDP로 나옴. 연결과 설정 부분은 알아서 구현하도록 되어있고 이거를 SIP로 하면 된다.

• 두 개의 peer가 다른 한쪽이 데이터가 전송되고 있다는 것을 알게 해준다.
• 기본적으로 미디어 컨텐츠 자체가 아닌 컨텐츠에 대한 메타 데이터 설명이 됨

WebRTC 동작

1. 동일 Private Zone내 peer 간 통신
2. a - Router1 - Router2 - B NAT 라우터에 연결된 peer간 통신 - 서로 다른 네트워크 상에 있는 컴퓨터 간 통신
3. WebRTC Peer & Server Full Configuration

• p2p원하지만 NAT문제로 stun 서버 사용한다. -> 자신의 public ip 받아온다. 해결 안되니 turn 서버가 받아서 릴레이 해준다. 트래픽 주고받아 서로 식별하게 된다.
• 나는 너에게 이런 미디어 보낼거야. 라고 하는게 signaling 서버 : 연결 설정하거나 해제하는 역할 한다.
• 이런 설정 과정 마친 이후에 실제 데이터를 주고 받는 것은 peer to peer 끼리 한다.
• but 1:N등 publish모델에서는 서버가 필요하다.
• 전체적으로 보자면 STUN서버를 통해 public ip를 얻어오고 TURN 서버를 통해 릴레이해서 NAT를 우회하여 최초로 등록을 하고 Signaling 서버로 연결 설정한 후 p2p방식으로 SDP를 보냄. (TURN 서버는 안쓸 수 도 있음.)

 

시그널링 서버에게 내가 누구와 통신하고 싶어요. 나는 어떤 해상도, 형태, 압축방식, 암호화방식

• 내가 누구와 대화하고 싶은데 이런 식으로 미디어 주고받고 싶어요 하고 시그널링 서버에게 전달
• 누구와 대화하고 싶고 어떤 형태의 미디어 타입이다 알려주면 시그널링 서버가 찾아서 대화하고 싶대~ 하고 전달해주고 이런 암호화 방식을 수용하겠어! 하고 알려주면 이걸 서버가 요청한 애한테 다시 전달. 이 과정 끝나면 오디오와 데이터는 직접적으로 주고받게 된다.

ICE라는 이름으로 묶어서 왼쪽과 오른쪽이 통신을 하기 위해서 stun 서버에게 가서 각자의 아이피를 물어서 가져온 후 시그널링 서버에게 아이피를 알려주면 연결 설정하는 과정, 응답하는 과정을 마치면 미디어나 오디오를 p2p로 보냄.

 

ip위에 tcp,udp 혼용해서 사용. udp 위에서 연결 설정하고 SDP를 주고 받는게 이 ICE에 대한 부분.. p2p 연결하는 api위에 올라가 있고 데이터 주고받는 datachannel위에 있음. 신뢰성 있는 데이터를 주고 받을려고 하면 tcp를 타고 websocket으로. websocket은 웹브라우저 위에서 소켓 통신할려고 만들어진 기술.

UDP위에서 한다 ⇒ 에러검출 및 복구를 SCTP 가 올라가서 데이터 교환한다.

SRTP : 오디오와 비디오 주고받을 수 있는 프로토콜. RTP이용해서 오디오와 비디오를 실어나른다. 가능하면 서버 경유하지 않고 데이터 전송하려 한다.

Web RTC 장점

• Near Real Time
  • RTP, udp based라서 latency 적다
  • 트래픽(data를)을 직접 주고 받으면 지연이 적음
• Inherently Low Latency
  • 내 카메라가 상대방의 화면에 전송될 때까지 500ms대가 걸린다. 상대방은 지연을 느낄 수 없다.
• Platform and Device Independence
  • 모든 주요 브라우저와 장치가 WebRTC지원. 전용 인프라 없이도 다양한 앱에 간편하게 통합 가능. 웹기술이어서 디바이스 독립이 생김.
  • HTML5 API 사용 -> 많은 기능 활용 가능
• Open Source and Standardized
  • 표준문서만 구현하면 누구든 연결 가능하다
• Adapts to Network Conditions
  • simulcasting을 이용해서 안좋은 네트워크 환경 속에서도 적절한 네트워크 인코딩을(적절한 해상도) 가지고 신뢰할 수 있는 영상을 보장받을 수 있음.
  • simulcasting : 보내는 쪽에서 480, 720, 1080 다 보낸다. bandwidth는 낭비될 수 있지만 단말이 최고의 품질 알아서 받을 수 있다. 스마트폰 - cpu 성능 딸리기 때문에 에어에서 아무리 빨라도 스마트폰에서 처리 힘들다. 받는 단말이 본인의 성능에 따라 선택 할 수 있다.

단점

• Scalability
  • 화상회의에 들어와있을 수 있는 유저의 수 제한될 수 밖에 없다.
  • 대충 50명…? 해결책으로 나온게 WebRTC 스트림을 프로토콜로 바꿀 수 있는 서버를 두는거.
• Broadcast Quality
  • webRTC의 비디오 퀄리티가 항상 지적이 됨. → but 카메라의 문제일 가능성이 큼! 이미 고화질로 전달할 수 있는 기술은 있음.