protocol_2주차(1) WebRTC

** WebRTC 들어가기 전에

Q. HTTP Streaming 방식에서 latency는 왜 발생하는가?

스트리머가 영상을 송출할때 MPD or m3u8 파일을 생성한다.

MPEG-DASH의 MPD파일이나 HLS의 m3u8파일을 만들때 그 파일안에 segment파일(데이터 영상을 조각으로 나눈 파일)을 만들게 되는데,

segment파일은 재생시간이 존재한다(ex.3초). 

만약 스트리머가 9초동안 찍은 영상을 송출한다면 그 9초짜리를 MPD or m3u8파일로 만드는데 최소 9초를 기다려야 한다. 그 9초가 latency 이다.

# 참고 (애플 HLS 공식문서 중)

15. Is this a real-time delivery system?

    No. It has inherent latency corresponding to the size and duration of the media files containing stream segments. At least one segment must fully download before it can be viewed by the client, and two may be required to ensure seamless transitions between segments. In addition, the encoder and segmenter must create a file from the input; the duration of this file is the minimum latency before media is available for download. Typical latency with recommended settings is in the neighborhood of 30 seconds.

Q. 그럼 segment 파일의 재생시간을 줄이면 latency가 짧아지는거 아닌가?

=> 답 해야함 

#. chunk파일 당 duration, index file안에 들어갈 chunk파일의 적합한 갯수는?

1. What duration should media files be?

   The main point to consider is that shorter segments result in more frequent refreshes of the index file, which might create unnecessary network overhead for the client. Longer segments will extend the inherent latency of the broadcast and initial startup time. A duration of 10 seconds of media per file seems to strike a reasonable balance for most broadcast content.

2. How many files should be listed in the index file during a continuous, ongoing session?

   The normal recommendation is 3, but the optimum number may be larger.

   The important point to consider when choosing the optimum number is that the number of files available during a live session constrains the client's behavior when doing play/pause and seeking operations. The more files in the list, the longer the client can be paused without losing its place in the broadcast, the further back in the broadcast a new client begins when joining the stream, and the wider the time range

   
   

   within which the client can seek. The trade-off is that a longer index file adds to network overhead—during live broadcasts, the clients are all refreshing the index file regularly, so it does add up, even though the index file is typically small.

5. What data rates are supported?

   The data rate that a content provider chooses for a stream is most influenced by the target client platform and the expected network topology. The streaming protocol itself places no limitations on the data rates that can be used. The current implementation has been tested using audio-video streams with data rates as low as 64 Kbps and as high as 3 Mbps to iPhone. Audio-only streams at 64 Kbps are recommended as alternates for delivery over slow cellular connections.

   For recommended data rates, see “Preparing Media for Delivery to iOS-Based Devices” (page 21).

   Note Ifthedatarateexceedstheavailablebandwidth,thereismorelatencybeforestartupand the client may have to pause to buffer more data periodically. If a broadcast uses an index file that provides a moving window into the content, the client will eventually fall behind in such cases, causing one or more segments to be dropped. In the case of VOD, no segments are lost, but inadequate bandwidth does cause slower startup and periodic stalling while data buffers.

   
   

   # .ts와 .m3u8은 뭐지?

   
   

6. What is a .ts file?

   A .ts file contains an MPEG-2 Transport Stream. This is a file format that encapsulates a series of encoded media samples—typically audio and video. The file format supports a variety of compression formats, including MP3 audio, AAC audio, H.264 video, and so on. Not all compression formats are currently supported in the Apple HTTP Live Streaming implementation, however. (For a list of currently supported formats, see “Media Encoder” (page 10).

   MPEG-2 Transport Streams are containers, and should not be confused with MPEG-2 compression.

   
   

7. What is an .M3U8 file?

   An .M3U8 file is a extensible playlist file format. It is an m3u playlist containing UTF-8 encoded text. The m3u file format is a de facto standard playlist format suitable for carrying lists of media file URLs. This is the format used as the index file for HTTP Live Streaming. For details, see IETF Internet-Draft of the HTTP Live Streaming specification.

1. WebRTC란?

웹에서 별도의 플러그인 없이 실시간 통신(RTC) 기능을 하기 위한 공개(open) API.

국제 표준화 기구인 W3C에서 제정. webRTC는 HTML5와 자바스크립트 API를 사용하여 웹상에서 플러그인 없이 브라우저를 기반으로 실시간 음성 통화, 비디오 채팅 및 파일 공유 등을 할 수 있게 한다.

2. 플러그인이 없어도 브라우저에서 실행할 수 있는 이유는?

# 플러그인이란

기존 응용 소프트웨어에서 특정 기능을 추가하기 위한 소프트웨어 요소.

웹 브라우저에서 제3자가 만든 소프트웨어를 이용하여 웹 브라우저가 표시할 수 없는 각종 형식의 파일을 웹 브라우저의 윈도창 내에 표시되도록 하는 구조. 인라인 플러그인 이라 한다. 

웹 브라우저와 일체로 동작하므로 별도의 응용 윈도를 열지 않아도 마치 웹 브라우저 자체가 그 파일 표시 기능을 가지고 있는 것 같이 동작한다.

A. 이유는 ~~~~

3. WebRTC가 나오게 된 배경은?

웹에서 남은 주요 도전 과제 중에 남은 하나는 영상과 음성을 통한 인간의 의사소통 - 실시간 대화(Real Time Communication, RTC) 가능하게 하는 것 입니다. 실시간 대화는 문자 입력란에 문자를 입력하는 것처럼 웹 어플리케이션에서 자연스러워야 하는 것입니다. 그렇지 않다면 사람들과 소통하는 새로운 방식들을 혁신하고 개발하는 능력을 우리는 한정 지어버리게 됩니다.

역사적으로 실시간 대화는 집에서 사용하기에 어려웠고, 비싼 음성/영상 기술들이 필요했습니다. 이미 존재하는 콘텐츠와 데이터 서비스들과 함께 실시간 대화 기술을 융합하는 것은 매우 어렵고 시간이 많이 드는 일이었습니다. 특히 웹에서.

Gmail의 영상채팅은 2008년에 출시되었고, 2011년에는 Google Talk 서비스를 (Gamil에서 처럼)사용한 행아웃이 소개되었습니다. 구글은 코덱, Echo cancellation 등의 실시간 통신에 필요한 많은 기술을 개발한 회사인 GIPS를 삽니다. 구글은 GIPS에서 개발한 기술들을 오픈 소스화하면서 업계의 합의를 얻기위한 IETF와 W3C에서 해당 기술과 관련된 표준들의 중심으 뛰어듭니다. 2011년 5월, Ericsson이 첫번째 WebRTC 데모를 개발합니다.

WebRTC는 현재 실시간, 플러그인 필요없는 영상과 음성, data 통신에 대한 공개 표준들을 구현했습니다. 현실의 요구들입니다:

• 많은 웹서비스들은 이미 실시간 통신을 사용하고 있습니다. 하지만 네이티브 앱이나 플러그인들의 다운로드가 필요합니다. Skype, (Skype를 사용하는)Facebook (Google Talk 플러그인을 사용하는)Google Hangouts등이 그렇습니다.
• 다운로딩, 설치 그리고 플러그인들을 업데이트 하는 것들은 복잡할 수 있고 애러를 발생시키며 귀찮은 일입니다.
• 플러그인들을 배포하고, 디버깅하고 문제잡고 테스트하고 유지하는 것은 힘든 일입니다. 그리고 아마도 복잡하고 비싼 기술들에 대한 라이센스나 구현이 필요할 수 도 있습니다. 사용자들에게 플러그인 첫 설치를 독려하는 것은 정말 어려운 일입니다!

WebRTC 프로젝트의 API들은 오픈소스이고, 무료이고, 표준화되어야하고 웹브라우저 안에서 만들어져야고, 이전의 기술들보다 효율적이어야한다는 것이 WebRTC 프로젝트의 안내 지침 입니다.

# 용어 설명

# ICE(Interactive Connectivity Establishment)

웹 브라우저를 동료와 연결할 수있게 해주는 프레임 워크입니다. 피어 A에서 피어 B까지 연결이 제대로 작동하지 않는 이유는 여러 가지가 있습니다. 연결을 열지 못하게하는 방화벽을 우회해야하며 대부분의 경우 장치에 공용 IP 주소가없는 경우 고유 한 주소를 부여하고 라우터가 동료와 직접 연결할 수 없으면 서버를 통해 데이터를 릴레이해야합니다. . ICE는 이를 위해 아래에 설명 된 기술 중 일부를 사용합니다.

# STUN

Session Traversal NAT (STUN) 는 public address를 검색하고 라우터에서 피어와의 직접 연결을 방지하는 제한 사항을 결정하는 프로토콜입니다.

클라이언트는 인터넷의 STUN 서버에 클라이언트의 public address로 회신 할 요청을 보내고 클라이언트가 라우터의 NAT 뒤에 액세스 할 수 있는지 여부를 결정합니다.

# NAT

NAT (Network Address Translation)는 장치에 공용 IP 주소를 제공하는 데 사용됩니다. 라우터에는 공용 IP 주소가 있으며 라우터에 연결된 모든 장치에는 개인 IP 주소가 있습니다. 요청은 장치의 개인 IP에서 고유 한 포트를 사용하여 라우터의 공용 IP로 변환됩니다. 그렇게하면 각 장치마다 고유 한 공개 IP가 필요하지 않지만 인터넷에서 여전히 발견 할 수 있습니다.

일부 라우터는 누가 네트워크의 장치에 연결할 수 있는지에 대한 제한을 가집니다. 이것은 우리가 STUN 서버에 의해 발견 된 공인 IP 주소를 가지고 있다고하더라도 누구도 연결을 만들 수 없다는 것을 의미합니다. 이 상황에서 우리는 선회로 돌아 가야합니다.

# TURN

NAT를 사용하는 일부 라우터는 'Symmetric NAT'라는 제한을 사용합니다. 즉, 라우터는 이전에 연결 한 동료의 연결 만 수락합니다.

순회 NAT를 사용한 릴레이 (TURN)는 TURN 서버와의 연결을 열고 해당 서버를 통해 모든 정보를 중계함으로써 대칭 NAT 제한을 우회합니다. TURN 서버와의 연결을 만들고 모든 피어에게 서버에 패킷을 보내도록 요청한 다음 전달합니다. 이것은 분명히 약간의 오버 헤드가 있기 때문에 다른 대안이없는 경우에만 사용됩니다.

# SDP

세션 설명 프로토콜 (SDP)은 해상도, 형식, 코덱, 암호화 등과 같은 연결의 멀티미디어 콘텐츠를 설명하여 데이터가 전송되면 두 피어가 서로를 이해할 수 있도록하는 표준입니다. 이것은 본질적으로 미디어 콘텐츠 자체가 아니라 콘텐츠를 설명하는 메타 데이터입니다.

참고 : https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols

# NAT(Network Address Translation)

사설 IP주소를 공인 IP주소로 바꿔주는데 사용하는 통신망의 주소 변환기이다.

NAT를 사용하는 목적에는 2가지가 있는데, 첫째는 인터넷의 공인 IP주소를 절약할 수 있다는 점이고 둘째는 인터넷이란 공공망과 연결되는 사용자들의 고유한 사설망을 침입자들로부터 보호할 수 있다는 점이다.

인터넷의 공인 IP주소는 한정되어 있기 때문에 가급적 이를 공유할 수 있도록 하는 것이 필요한데 NAT를 이용하면 사설 IP주소를 사용하면서 이를 공인 IP주소와 상호변환할 수 있도록 하여 공인 IP주소를 다수가 함께 사용할 수 있도록 함으로써 이를 절약할 수 있는 것이다.

공개된 인터넷과 사설망 사이에 방화벽(Firewall)을 설치하여 외부 공격으로부터 사용자의 통신망을 보호하는 기본적인 수단으로 활용할 수 있다. 이때 외부 통신망 즉 인터넷망과 연결하는 장비인 라우터에 NAT를 설정할 경우 라우터는 자신에게 할당된 공인 IP주소만 외부로 알려지게 하고, 내부에서는 사설 IP주소만 사용하도록 하여 필요시에 이를 서로 변환시켜 준다. 따라서 외부 침입자가 공격하기 위해서는 사설망의 내부 사설 IP주소를 알아야 하기 때문에 공격이 불가능해지므로 내부 네트워크를 보호할 수 있다.

[네이버 지식백과] NAT [Network Address Translation] (두산백과)

# 공인 IP 주소

단어 그대로, 공인기관에서 인증한 공개형(public) IP 주소다. 인터넷 유무선 공유기를 사용하지 않는 한 컴퓨터 등에서 사용하는 대부분의 IP 주소는 공인 IP 주소다. 우편물로 치면 우체국에서 배달하는 실제 주소인 셈이다. 이 주소는 외부로 공개되어 누구라도 그 주소로 우편물을 보낼 수 있는 것처럼, 공인 IP 주소도 외부에 공개되어 있어 다른 컴퓨터 등에서 검색, 접근이 가능하다. 예를 들어, 내 컴퓨터의 IP 주소가 100.100.100.100이라면 인터넷에 연결된 어떤 사용자(혹은 컴퓨터)라도 이 IP 주소를 토대로 내 컴퓨터에 (1차) 접근이 가능하다. 따라서 공인 IP 주소를 사용하려면 보안 장비(방화벽 등)가 반드시 필요하다. 다만 가정에서는 가입한 인터넷 서비스 회사(ISP, KT, SK브로드밴드, LG유플러스 등)에서 보안 서비스를 제공하고 있기에 크게 걱정할 필요는 없다.

# 사설 IP 주소

공인 IP 주소가 공개형이라면 가상(private) IP 주소(혹은 사설 IP주소라고도 함)는 폐쇄형이다. 공인되지 않은IP 주소라는 의미 때문이다. 즉, 이 가상 IP 주소는 외부에 공개되지 않아 외부에서 검색, 접근이 근본적으로 불가능하다. 가상 IP주소는 주소 대역이 3개로 고정되어 있다. 이를 테면, '192.168.xxx.xxx'와 '172.10.xxx.xxx', 그리고 '10.xxx.xxx.xxx' 대역이다. 이러한 가상 IP 주소는 인터넷 유무선 공유기를 사용할 때 흔히 접하게 되는데, 하나의 공인 IP 주소를 공유하여 여러 대의 컴퓨터가 인터넷에 접속하게 하려면 가상 IP 주소가 필요하기 때문이다.

예를 들어, 그 동안 컴퓨터 한 대를 100.100.100.100라는 공인 IP 주소로 설정해 인터넷에 접속하다가 유무선 인터넷 공유기를 설치해 연결했다면, 이후로는 공유기 IP 주소가 100.100.100.100이 되고 공유기에 연결된 해당 컴퓨터에는 192.168.0.10 등과 같은 가상 IP 주소가 할당된다. 이러한 가상IP 주소를 사용하는 이유는 두 가지다.

하나는 위에서 언급한 대로 IP 주소를 공유하기 위함이다. 이는 IPv4 체계의IP 주소 부족 문제를 해결할 수 있는 방안이기도 하다. 공유기가 없다면 사무실에 있는 10대의 컴퓨터 각각에 모두 공인 IP 주소를 부여해야 하지만, 공유기가 있으면 1개 공인 IP 주소만 공유기에 할당하고, 10대의 컴퓨터는 가상 IP 주소를 각각 할당 받아 인터넷에 접속할 수 있게 된다.

또 하나의 이유는 보안 때문이다. 가상 IP 주소가 할당된 컴퓨터 등은 외부에서 검색, 접근이 기본적으로 불가능하다. 일반적으로 인터넷 공유기가 그러한 보안 장비의 역할(네트워크 방화벽)도 수행하고 있다.

4. WebRTC 주요 API의 특징은?

• GetUserMedia
  사용자의 카메라와 마이크 접근을 담당.
• MediaStream API는 미디어의 동기화된 스트림들을 말합니다. 예를 들어, 카메라와 마이크의 입력에서 받아온 스트림은 오디오와 비디오 트랙들로 동기화 됩니다. (MediaStream의 트랙을 완전히 다른의미의 <track> 요소와 헷갈리면 안됩니다.)
• RTCPeerConnection
  Peer간의 연결을 생성하고, 오디오와 비디오 통신에 사용.
  (생성시 STUN 서버 요청)

• RTCPeerConnection은 Peer들 간의 데이터를 안정적이고 효율적으로 통신하게 처리하는 WebRTC 컴포넌트입니다.

  

  JavaScript 측면에서 보면, 이 다이어그램을 통해 알 수 있는 중요한 점은 RTCPeerConnection이 뒤에 숨겨진 매우 복잡한 것들을 웹개발자로부터 지켜주고 있다는 것 입니다. WebRTC에서 사용되는 코덱들과 프로토콜들은 불안정한 네트워크 위에서도 실시간 통신이 가능하게 하기위해 엄청난 양의 일들을 하고 있습니다: 

  • packet loss concealment
  • echo cancellation
  • bandwidth adaptivity
  • dynamic jitter buffering
  • automatic gain control
  • noise reduction and suppression
  • image 'cleaning'.

  위에 나온 W3C 코드는 Signaling 측면에서 WebRTC의 간소화된 예를 보여줍니다. 다음은 현재 동작하고 있는 두가지 WebRTC 어플리케이션 입니다: 첫 번째는 단순한 RTCPeerConnection의 데모 예제이고, 두번째는 온전히 동작하는 화상채팅 클라이언트 입니다.
  

• RTCDataChannel
  Peer간의 Data를 주고 받을 수 있는 Tunnel API
  (WebSocket과 유사하지만, P2P라 속도가 보다 빠름)

오디오와 비디오처럼, WebRTC는 실시간으로 다른 형태의 데이터 통신도 지원합니다.

RTCDataChannel API는 피어와 피어간 임의의 데이터 교환을 빠른 반응속도와 높은 처리량으로 가능하게 합니다. 여기 단순한 '단일 페이지' 데모 simpl.info/dc가 있습니다.

이 API에 대한 많은 잠재적 사용 예가 있습니다:

• 게임
• 원격 데스크탑 어플리케이션
• 실시간 문자 채팅
• 파일 전송
• 분산 네트워크

이 API는 RTCPeerConnection의 대부분의 기능들을 활용하여 강력하고 유연한 P2P통신을 가능하게 하는 몇가지 기능을 가지고 있습니다:

• RTCPeerConnection 세션 설정의 레버리징.
• 우선순위가 있는 여러개의 동시 채널
• 신뢰/비신뢰 전달 시멘틱.
• 빌트인 보안(DTLS) 과 혼잡 제어.
• 오디오 또는 비디오 유/무 사용.

5. 연결된 session 간 데이터 전송을 위한 피어링 기술을 활용한다? 피어링 기술이 뭐지?

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

내가 이 프로토콜을 써야하는 100가지 상황 생각해보기 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

http://www.rtc-conference.com/2017/wp-content/uploads/gravity_forms/2-2f7a537445fa703985ab4d2372ac42ca/2017/09/Lee_The-Architecture-of-WebRTC-MCU-on-the-distributed-processing.pdf(webrtc mcu 설명)

https://www.html5rocks.com/ko/tutorials/webrtc/basics/#toc-rtcdatachannel(webrtc 전체적인 설명)

https://www.wowza.com/blog/the-role-of-webrtc-in-low-latency-media-streaming( 와우자 webRTC설명)