스트리밍 프로토콜 정리

스트리밍 프로토콜은 인터넷에서 어떤 디바이스 또는 시스템이 데이터 통신하는 방식을 정의 하는 일련의 규칙이다.
스트리밍 프로토콜은 더 쉽게 전송하기 위해 비디오 스트림을 작은 단위로 분할하는 방법을 표준화하였다.

HLS (HTTP Live Streaming)

HLS 는 요즘 가장 인기있는 스트리밍 프로토콜로, 애플에서 iPhone 에서 flash 를 걷어내기 위해 처음 내놓은 스트리밍 프로토콜이다.
거의 모든 기기에서 사용되고 있습니다. 데스크탑 브라우저, 스마트 TV, 셋탑 박스, 모바일 디바이스 뿐만 아니라 HTML5 비디오 플레이어에서 사용된다.

장점

1. 높은 호환성 : HLS 프로토콜은 거의 모든 인터넷 기반 디바이스와 OS에서 거의 완벽하게 호환된다.

2. 안정성 : HLS 프로토콜은 매우 안전한 스트리밍 방식이다.

3. 퀄리티 : HLS 프로토콜은 ABR (Adaptive bitrate streaming) 기술을 통해 매우 훌륭한 퀄리티를 제공한다.

단점

1. 낮은 대기 시간 : HLS 프로토콜은 다른 타 프로토콜과 다르게 낮은 대기 시간을 유지할 수 없습니다.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP)

MPEG-DASH 는 Moving Pictures Expert Group (MPEG) 에서 HLS 를 발전시킨 오픈소스 모델이다.
모든 오디오 또는 비디오 코덱에 맞게 사용자 정의가 가능하며, HLS 와 마찬가지로 최고의 퀄리티를 자랑한다.

장점

1. 적응성 : MPEG-DASH 프로토콜은 ABR을 활용하여 다양한 인터넷 속도 및 조건에서 높은 비디오 품질로 스트리밍한다.

2. 사용자 정의 : MPEG-DASH 프로토콜은 오픈 소스이므로 사용자가 고유한 스트리밍 요구 사항에 맞게 맞춤 설정할 수 있다.

단점

1. 제한된 호환성 : MPEG-DASH 프로토콜은 애플 장치/iOS와 호환되지 않으므로 방송 범위가 크게 제한된다.

2. 노후화 : MPEG-DASH 프로토콜은 한때 매우 인기가 있었지만 제한 사항으로 인해 다양한 다른 고급 프로토콜 옵션과 공정하게 경쟁하기가 어렵다.

WebRTC

WebRTC는 실시간 대기 시간으로 시청자에게 비디오 스트림을 제공하는 오픈 소스 프로젝트이다.
WebRTC 프로토콜은 P2P(Peer-to-Peer Streaming)에 의존하는 대기 시간이 짧은 스트리밍 솔루션이다.
Google Meet, Discord, Houseparty, WhatsApp 및 Facebook Messenger와 같이 가장 많이 사용되는 앱에서 활용된다.

장점

1. 유연성 : WebRTC는 오픈 소스이므로 개발자가 특정 스트리밍 요구 사항에 맞게 사용자 정의할 수 있을 만큼 충분히 유연하다.

2. 실시간 대기 시간 : WebRTC는 실시간 대기 시간이 있는 스트리밍을 지원한다. 즉, 방송된 비디오가 높은 비디오 품질로 실시간으로 시청자의 화면으로 이동한다는 의미이다.

단점

1. 제한된 지원 : WebRTC 비디오 스트리밍 프로토콜은 최근에야 웹 표준으로 채택되었습니다. 시장은 적응할 시간이 많지 않았기 때문에 엔지니어는 이 스트리밍 설정과 호환성 문제에 직면할 수 있다.

SRT (Secure Reliable Transport)

SRT 프로토콜은 스트리밍 기술 제공업체인 Haivision이 개발한 오픈 소스 표준이다.
보안, 신뢰성, 호환성 및 짧은 대기 시간 스트리밍으로 잘 알려진 이 프로토콜은 SRT Alliance 회원이 선호하는 프로토콜이다.
이 프로토콜은 단일 코덱에 의존하지 않으므로 개발자는 원하는 오디오 및 비디오 코덱과 페어링할 수 있다.

장점

1. 보안 : 이 프로토콜은 방송사가 스트리밍 콘텐츠를 안심하고 시청자를 안전하게 보호할 수 있는 최고 수준의 보안 및 개인 정보 보호 도구를 갖추고 있다.

2. 호환성 : SRT는 장치 및 운영 체제에 구애받지 않으므로 호환성이 뛰어나고 대부분의 인터넷 지원 장치에 스트림을 전달할 수 있다.

3. 낮은 대기 시간 : SRT 스트리밍 프로토콜은 오류 수정 기술의 지원 덕분에 낮은 대기 시간 스트리밍을 제공한다.

단점

1. 제한된 지원 : WebRTC와 유사하게 SRT는 여전히 미래 지향적인 것으로 간주되며, 대규모 스트리밍 산업에서는 이 비디오 프로토콜이 표준화되기 전에 발전하는 데 시간이 좀 필요할 것이다.

RTMP (Real-Time Messaging Protocol)

RTMP는 스트리밍 서버와 Adobe Flash Player 간에 오디오 및 비디오 파일을 전송하기 위해 Adobe에서 개발한 레거시 프로토콜이다.
Flash가 단계적으로 폐지됨에 따라 기본 사용 사례가 시청자 대상 콘텐츠 전달에서 RTMP 지원 인코더를 통한 라이브 스트림 수집으로 전환되었다. 이는 인코더의 비디오 피드가 일반적인 HLS 프로토콜을 통해 최종 사용자에게 전달되기 전에 RTMP 프로토콜을 통해 스트리밍 플랫폼으로 전송된다는 것을 의미한다.

장점

1. 낮은 대기 시간 : RTMP는 인터넷 연결이 불안정한 경우에도 라이브 비디오 스트림이 시청자를 위한 안정적인 연결을 유지하도록 보장한다. 또한 인터넷 연결이 안정되면 스트림을 쉽게 재개할 수 있다.

2. 적응성 : 이 프로토콜 스트림 피드는 적응형이며 RTMP 서버에서 호스팅된다. 즉, 시청자는 피드의 일부를 건너뛰거나 되감거나 시작된 후 라이브 스트림에 참여할 수 있다.

3. 유연성 : 개발자는 RTMP 프로토콜을 사용하여 오디오, 비디오, 텍스트와 같은 다양한 비디오 형식을 하나의 응집력 있는 패키지로 통합할 수 있다. 또한 오디오의 경우 MP3 및 AAC, 비디오의 경우 MP4, FLV 및 F4V로 스트리밍하여 여러 미디어 채널을 활용할 수도 있다.

단점

1. 제한된 지원 : Flash는 HTML5 플레이어가 대신하면서 빠르게 쓸모없어지는 형식이다. Flash는 현재 RTMP를 지원하며 이 프로토콜은 HTTP 기반 비디오 프로토콜과 같은 변환기 없이는 HTML5 플레이어에서 재생할 수 없다.

2. 낮은 대역폭 : RTMP 스트림은 대역폭 문제에 취약하여 UX에 부정적인 영향을 미치는 빈번하고 실망스러운 라이브 스트림 중단을 유발한다.

RTSP (Real-Time Streaming Protocol)

RTSP는 원래 엔터테인먼트를 염두에 두고 개발된 레거시 프로토콜이며, 주요 용도는 엔드포인트 간에 TV 및 영화와 같은 미디어 세션을 설정하고 제어하는 것이다.
이 프로토콜은 HLS와 유사하며 라이브 스트리밍 데이터만 전송할 수 없으며 스트리밍 작업을 수행하려면 RTSP 서버가 RTP 및 기타 프로토콜과 함께 작동해야 한다.
RTSP 프로토콜은 짧은 대기 시간 스트리밍을 지원하지만 대부분의 장치 및 브라우저와 호환되지 않는다.
전용 서버에서 선택된 소수의 청중에게 저지연 스트리밍을 제공할 수 있어 영상 감시 및 CCTV 시스템의 표준이 되었다.

장점

1. 세그먼트 스트리밍 : 시청자는 시청하기 전에 전체 비디오를 다운로드할 필요가 없으며, RTSP 스트림을 사용하면 다운로드가 완료되기 전에 콘텐츠를 시청할 수 있다.

2. 고도로 사용자 정의 가능 : TCP(전송 제어 프로토콜) 및 UDP(사용자 데이터그램 프로토콜)와 같은 다른 프로토콜을 활용하여 자신만의 비디오 스트리밍 애플리케이션을 만들 수 있다.

단점

1. 낮은 인기도 : 대부분의 비디오 플레이어와 스트리밍 서비스는 RTSP 스트리밍을 지원하지 않기 때문에 RTSP는 다른 프로토콜보다 인기가 있지 않다.

2. HTTP 비호환 : HTTP를 통해 RTSP를 직접 스트리밍할 수 없다. 즉, 웹 브라우저에서 RTSP를 스트리밍하는 쉬운 방법이 없다.
   RTSP는 기업 내 보안 카메라와 같은 개인 네트워크에서 비디오를 스트리밍하도록 설계되었지만 개발자는 이 프로토콜로 스트리밍하기 위해 추가 소프트웨어를 웹 사이트에 내장할 수 있다.