WebRTC와 미디어 서버

WebRTC는 비디오를 전송하는 프토토콜중 하나이다. 이 글에서는 스트리밍 유명 스트리밍 프로토콜에 대해 알아보고 WebRTC에 대해 더 자세히 알아본다.

스트리밍 프로토콜 알아보기

 

스트리밍 프로토콜

비디오를 chunks로 분할하고 재조립 하는데 사용하는 표준화된 방법.

다양한 조직에서 프로토콜들을 개발하였고 일반적으로 오픈소스.

유명한 스트리밍 프로토콜 예시

• RTMP,HLS,WebRTC

RTMP

• Real-Time Message Protocol의 약자.
• Adobe Flash 플레이어에 비디오 콘텐츠를 전달하는 데 사용된 스트리밍 프로토콜
• 대기 시간이 짧은 스트리밍 기능이 특장
• 저지연 스트리밍 가능.
• 무료 인코딩 소프트웨어가 많고 대부분의 최신 인코더와 함께 동작하기 때문에 접근성이 좋음.
• BUT, HTML5를 비롯한 최신 비디오 플레이어와 호환되지 않기 때문에 스트리밍 설정에서 더이상 전송에 사용되지 않음.

HLS

• Http Live Streaming의 약자
• HTML5 비디오 플레이어로 스트리밍 하기 위해 Apple에서 개발한 프로토콜
• HTML5 비디오 플레이어가 보편적으로 호환되는 유일한 프로토콜이므로 대부분의 최신 스트리밍 설정에서 절대적으로 필요
• 안전하고 고품질 스트리밍을 생성, 거의 모든 인터넷 지원 장치로 스트리밍 할 수 있는 호환성
• HLS는 스트리밍 전달과 수집에 모두 사용할 수 있지만 현재는 대부분 전달쪽으로 사용
• 전달과 수집을 나누어 하기 때문에 단독으로 사용할 경우 15-30초의 대기 시간 발생
  • 긴 대기 시간은 p2p 상호 작용, 회의 등과 관련된 많은 프로그램에서 사용 안됨.

WebRTC

• Web Real-Time Communication(WebRTC)의 약자
• 웹 회의 및 VoIP를 지원하기 위해 만들어진 스트리밍 프로젝트, Google에서 구입하여 추가로 개발
• 저지연의 peer-to-peer 스트리밍 가능
• 오픈소스 프로젝트로 개발자가 WebRTC를 사용하여 소프트웨어에 스트리밍을 통합할 수 있도록 함
• 현재는 Google Meet, Slack, Discord와 같은 화상 회의 기능이있는 곳에서 사용됨.
• SRTP(실시간 전송 보안 프토로콜) 및 기타 표준 보안 조치로 암호화 되어있어 매우 안전.
• 커스터마이징에 용이, 대부분의 브라우저 및 장치 유형으로 스트리밍 가능
• HLS와 더불어 Adaptive Bitrate Streaming 적용
  • Adaptive Bitrate Streaming(ABR)
  • 비디오 플레이어 클라이언트가 다운로드할 비트전송률 세그먼트를 결정하는 알고리즘
  • 사용자의 인터넷 연결과 장치의 처리 용량을 감지하여 실시간으로 비트 전송률을 증가시키기거나 감소시켜서 최상의 비디오 경험 제공

RTMP vs HLS vs WebRTC

공통점 : 실시간에 가까운 데이터를 전송하는데 도움

RTMP 수집을 통해 HLS로 전달하는 조합을 많이 사용중.

WebRTC 도 대중화 되고 있지만 인코더에서 널리 지원되지 않는 단점.

	RTMP	HLS	WebRTC
지연시간	2-5 초	20-30 초	<500 miliseconds
규묘	Limited due to persistent server-client connections. Needs special RTMP proxy to scale	수백만 명의 시청자	만명 이하의 시청자
품질	ABR을 사용하지 않음	ABR 사용	ABR 사용
호환	flash의 쇠퇴로 인해 존재하지 않음	모든 HTML5 플레이어와 호환	대부분의 최신 브라우저, IOS 및 안드로이드에서 지원

 

WebRTC 알아보기

 

WebRTC란 ?

• Web Real-Time Communication의 약자
• 웹,모바일에서 별 다른 소프트웨어 없이 카메라, 마이크 등을 사용해서 실시간 커뮤니케이션을 제공해주는 기술
• 화상회의를 구현할 수 있는 오픈소스
• UDP 기반의 P2P
• 웹브라우저간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계됨. javascript api를 통해 실행 가능

동작 과정

3가지 방식 존재

• P2P 기반의 Mesh, MCU, SFU방식 존재
• Mesh : 각각의 클라이언트가 모두 자신의 미디어 스트림을 나머지 피어들에게 직접 전달
• MCU,SFU : 여러 피어들이 자신의 미디어 스트림을 중앙 서버에 보내고 서버가 이를 처리하여 피어들에게 전달.

P2P기반 Mesh

• 중간 서버 없이 사용자와 사용자가 연결을 수립하고 데이터를 주고 받는다.
• 인터넷에서는 데이터를 주고받기 위해 HTTP프로토콜을 사용
• 브라우저가 서버에게 HTTP 요청 → 서버는 브라우저에 HTTP응답 메세지 보냄.
• HTTP는 서버의 응답후 연결 종료.
• 따라서 polling 기법으로 계속 서버에게 새 정보가 있는지 무한히 요청해야 함.
  • Long Polling 기법 : polling을 보완하기 위한 기법. HTTP 요청을 보내서 특정 이벤트 까지 계속 기다리다가 서버가 응답 해주면 다시 클라이언트가 HTTP 요청을 보냄.
• 웹 소켓
  • HTTP의 비연결지향을 극복하고자 등장한 기술.
  • http 요청, 응답 대신 connection을 가지며 open-close 여부 판단.
  • 브라우저가 웹소켓을 이용해 서버와 연결하면 연결 종료 까지 통신이 가능
  • 채팅 참여자들의 서버에 참여하고 서버는 모든 참여자들과 연결하고 정보를 제공해야 하므로 서버의 메모리 파워가 중요
• WebRTC
  • 서버의 부하를 극복하기 위해 등장.
  • 채팅의 참여자들이 서버에 접속하는것이 아니라 P2P로 브라우저끼리 연결됨.
  • 문자, 음성,영상들이 서버를 거치지 않고 전달되므로 더욱 빠름.
  • 하지만 1000명의 사용자가 접속한다면 컴퓨터는 999개의 데이터를 수신해야 하고 이로 인해 확장성의 제약이 발생
• 서버의 역할
  • 상대방과 통신하기 위해 상대방이 누구인지 파악하기 위해 사용자를 묶어주는 역할을 하는 Signaling Server 필요
  • 시그널링
    • 서로 다른 네트워크에 있는 2개의 디바이스가 통신 하기 위해서 IP를 알아야 하며, 미디어 포맷의 협의하는 과정
  • 시그널링 서버를 통한 동작 과정
    • 통신을 원하는 사용자는 상대 사용자에게 시그널링 서버를 통해 자신의 정보를 제공
    • 상대 사용자는 그 정보들에 대해 자신의 정보를 담아 답장.
  • 시그널링 서버의 한계
    • 클라이언트가 방화벽이나 NAT 뒤에 있는 경우가 대부분이므로 Public IP 주소를 알아내기 어려움이 있음. 이를 해결 하기 위해 STUN/TURN 서버를 이용함.
    • NAT : Network Address Translation
      • 공인 IP와 사설 IP를 매핑하기 위함.
    • STUN , TURN
      • 시그널링을 위해 사설 IP를 공인 IP로 변환하기 위해서 사용하는 서버
      • STUN : 공용 네트워크 망에서 동작 . NAT 뒤에 있는 공인 IP주소를 찾아 변ㄱ환
      • TURN : NAT 타입 또는 방화벽의 제한으로 P2P 연결이 실패했을 때 대안으로 사용

SFU( Selective Forwarding Unit) 서버

• 서버를 이용하여 클라이언트의 미디어 스트림을 중계하는 역할 수행. 상황에 따라 연결된 클라이언트 일부만 중계
• Mesh 기반에서 다수의 사용자들을 다루기 힘든 부분을 커버할 수 있음.
• p2p방식에서는 연결된 클라이언트 수 만큼의 업로드 트래픽 발생하지만 SFU는 중계 서버에만 업로드 트래픽이 1개 발생함.
• 중간 서버에는 별도의 미디어 가공 과정을 거치지 않고 그대로 각 사용자들에게 전달. 각 피어간에 연결 할당, 암호화 및 복호화 처리 비용 감수
• 비교적 서버에 부하가 적게 걸린다.

MCU

• 서버를 이용하여 업로드된 미디어 스트림을 하나로 합쳐서 클라이언트에 1개의 미디어 스트림을 내려주는 구조
• 한번에 모아서 믹싱하여 전달하므로 네트워크의 부담은 현저히 줄지만 CPU사용량이 매우 커짐.

WebRTC를 구현하기 위한 기술들

ICE

• Interactive Connectivity Establishment
• 브라우저가 peer를 통한 연결이 가능하도록 해주는 프레임워크
• peer간 단순 연결시 작동이 안되는 이유
  • 연결을 시도해야 하는 방화벽을 통과해야함.
  • 단말에 public ip가 없다면 유일한 주소값을 할당해야함.
  • 라우터가 peer간 직접 연결을 허용하지 않을 때 데이터를 릴레이 해야 하는 경우
• ICE는 위 작업을 수행하기 위해 STUN과 TURN 서버 둘 다 혹은 하나를 사용한다.

STUN

• Session Traversal Utilies for NAT
• 클라이언트는 자신의 Public Address(IP:PORT)를 알려준다
• peer간 직접 연결을 막는 등의 라우터의 제한을 결정하는 프로토콜 ( 현재 다른 peer가 접근 가능한지 여부 결정)
• 클라이언트는 인터넷을 통해 클라이언트의 public address와 라우터의 NAT 뒤에 있는 클라이언트가 접근 가능한지에 대한 답변을 STUN 서버에 요청
•  

NAT

• Network Address Transilation
• 단말에 공개 IP (public IP)주소를 할당하기 위해 사용한다.
• 라우터는 공개 IP주소를 갖고 있고 모든 단말들은 라우터에 연결되어 있으며 비공개 ip주소 (private ip 주소를 갖는다)
• 요청은 단말의 비공개 주소로부터 라우터의 공개 주소와 유일한 포트를 기반으로 번역
• 이 덕분에 각각의 단말이 유일한 공개 IP없이 인터넷 상에서 검색 가능.
• 몇몇 라우터는 Symmetric NAT이라고 불리우는 NET 사용.
  • peer들이 이전에 연결했던 경험이 있는 경우에만 연결 허용
  • STUN 서버에 의해 공개 IP주소를 발견한다고 해도 모두 연결가능한건 아님.
  • → 해결을 위해 TURN서버 필요

TURN

• Traversal Using Relays around NAT 서버
• TURN 서버와 연결하고 모든 정보를 그 서버에 전달하는 것으로 Symmetric NAT 제한을 우회하는 것
• 이를 위해 TURN 서버와 연결한 후 모든 peer들의 서버에 모든 패킷을 보내고 다시 TURN서버에 전달해달라고 해야함.
• 오버헤드가 발생하므로 대안이 없을 경우만 사용해야 함.
•  

SDP

• Session Description Protocol
• 해상도나 형식, 코덱, 암호화 등의 멀티미디어 컨텐츠의 연결성을 설명하기 위한 표준
• 두개의 peer가 다른 한쪽이 데이터가 전송되고 있다는 것을 알게 해줌
• 기본적으로 미디어 컨텐츠 자체가 아닌 컨텐츠에 대한 메타데이터 설명
• 프로토콜은 아님.

 

출처 : https://surprisecomputer.tistory.com/7?category=909008