스트리밍 미디어의 역동적인 환경에서 최적의 프로토콜을 선택하는 것은 원활한 시청 환경을 제공하는 데 중요합니다. 사용 가능한 프로토콜 중에서 HTTP-FLV(Flash Video over HTTP)가 파장을 일으키고 있으며, 더 확립된 HLS(HTTP Live Streaming)보다 인기를 얻고 있습니다. 이 블로그에서는 HTTP-FLV를 살펴보고, 그 기능, 성능, HLS에 비해 인기가 높아지는 이유를 파헤칩니다.
스트리밍 프로토콜 소개: 알아야 할 기본 사항
미디어 전문가라면 Apple 생태계에서 널리 채택된 HLS(HTTP Live Streaming)에 익숙할 수 있습니다. HLS는 인터넷을 통해 시청자에게 온라인 비디오 및 오디오 미디어를 스트리밍하는 주요 표준 중 하나입니다. 버드.티비HLS는 현재 전 세계적으로 스트리밍 프로토콜 사용 측면에서 최상위를 차지하고 있습니다.
그러나 네트워크 기술의 지속적인 발전과 고품질 라이브 방송에 대한 수요 증가로 이러한 프로토콜의 순위는 변경될 수 있습니다. 예를 들어 HTTP-FLV는 종종 간과되는 스트리밍 프로토콜입니다. Douyin, TikTok 등을 포함하되 이에 국한되지 않는 많은 미디어 거대 기업이 대화형 엔터테인먼트 세그먼트에 필수적인 초저지연 경험을 위해 HTTP-FLV를 채택하고 있다는 것은 설득력 있는 사실입니다.
이러한 변화가 일어나는 이유를 더 잘 이해하려면 라이브 스트리밍 품질을 향상하는 측면에서 HTTP-FLV와 HLS의 주요 차이점을 살펴봐야 합니다.
HLS(HTTP 라이브 스트리밍)란 무엇인가요?
HLS 또는 HTTP Live Streaming은 Apple에서 개발하여 2009년에 도입한 프로토콜입니다. QuickTime Streaming Server를 대체하고 RTMP와 같은 기존 프로토콜의 일부 한계를 해결하기 위해 만들어졌습니다. HLS는 그 이후로 적응형 비트레이트 비디오 스트리밍을 위한 가장 널리 채택된 표준이 되었으며, 다양한 네트워크 조건에 적응하고 크로스 디바이스 호환성을 보장하여 안정적이고 원활한 시청 환경을 제공합니다.
HLS는 당시 사용 가능한 인터넷 속도로 인해 발생한 성능 문제를 해결해야 할 필요성에서 탄생했습니다. 여기에는 다양한 네트워크 및 장치 조건과 높은 신뢰성과 호환성을 갖춘 프로토콜이 필요했습니다. 이를 달성하기 위해 HLS는 짧은 연결을 사용하여 비디오 콘텐츠를 전송함으로써 라이브 스트리밍 프로세스를 수정했습니다.
간단히 말해서, HLS는 콘텐츠를 더 작은 부분으로 분할한 다음 각 세그먼트에 대한 요청을 생성하여 순차적으로 재생합니다. 큰 세그먼트로 인해 전송 시간이 길어지는 것을 방지하기 위해 HLS는 이러한 세그먼트를 더 작은 청크로 분할한 다음 재생 목록 파일(M3U8 형식)로 패키징하여 클라이언트로 전송하여 구문 분석합니다. 클라이언트는 재생 목록을 사용하여 개별 청크를 요청하고 재생합니다.
M3U8 파일에 패키징된 모든 TS 파일(전송 스트림 세그먼트)이 전송되면 서버는 계속해서 다가오는 미디어 콘텐츠를 슬라이스하고 패키징한 다음 클라이언트가 새 미디어 콘텐츠를 요청할 때까지 기다립니다.
짧은 연결이 제공하는 안정성과 적응성 외에도, 적응형 비트레이트 비디오 스트리밍을 위한 널리 채택된 표준인 HLS는 장치 간 호환성과 확장성 면에서도 뛰어납니다.
- 교차 장치 호환성 – HLS는 호환되는 비디오 플레이어(예: HTML5)를 실행하는 모든 클라이언트 기기에서 콘텐츠를 재생할 수 있음을 보장합니다. 즉, HLS는 iOS, Android, 스마트 TV 및 대부분의 웹 브라우저를 포함한 광범위한 기기에서 지원됩니다. 이러한 광범위한 호환성으로 스트리밍을 위한 다재다능한 선택이 됩니다.
- 확장성 – HLS는 표준 HTTP 서버에서 작동하며 콘텐츠 전송 네트워크(CDN)와 쉽게 통합되어 전 세계적으로 콘텐츠를 배포하고, 바이러스성 시청률 급증과 대규모 라이브 시청자를 수용할 수 있습니다.
짧은 연결이 HLS에 가져다주는 이점에도 불구하고, 이 접근 방식과 관련된 몇 가지 단점이 여전히 있습니다. 청크 또는 세그먼트가 일반적으로 2~6초 길이이고 한 번에 여러 개의 작은 세그먼트를 버퍼링해야 하기 때문에 지연 시간은 궁극적으로 수십 초에 이를 수 있습니다. 여기서 새로운 연결 방법인 지속적 연결이 작용합니다.
HTTP-FLV란 무엇인가요?
HTTP-FLV 전송은 연결을 한 번 설정한 다음 유지하는 것을 포함하며, 그 동안 서버는 클라이언트에 작은 크기의 파일을 지속적으로 전송합니다. 이 프로세스는 클라이언트나 서버가 연결을 끊을 때까지 계속됩니다. HTTP-FLV 라이브 스트리밍 프로토콜은 작은 크기의 FLV 파일을 활용하여 중단 없는 네트워크 연결을 통해 비디오 콘텐츠를 전송하여 클라이언트가 항상 재생할 콘텐츠를 보유할 수 있도록 합니다.
본질적으로 HTTP-FLV는 저지연 스트리밍을 제공하도록 설계되어 지연이 중요한 요소인 실시간 애플리케이션에 이상적입니다. 이는 즉각적인 피드백이 중요한 라이브 이벤트, 온라인 게임 및 대화형 스트림에 특히 중요합니다.
그러나 지연 시간은 라이브 스트리밍의 유일한 요소는 아닙니다. 라이브 스트리밍에서 궁극적인 사용자 경험은 초기 로드 시간, 지연 시간, 버퍼링이라는 세 가지 주요 지표에 의해 결정됩니다. 따라서 이 두 가지 다른 라이브 스트리밍 프로토콜이 이 세 가지 측면에 어떤 영향을 미치는지 비교하는 데 중점을 둘 것입니다.
라이브 스트리밍에서 HLS와 HTTP-FLV의 성능 비교
비교를 시작하기에 앞서, 라이브 스트리밍 중 사용자 경험에 큰 영향을 미치는 몇 가지 핵심 요소를 정의해 보겠습니다.
초기 로드 시간: 라이브 스트림을 요청한 후 클라이언트 화면에 첫 번째 비디오 프레임이 나타나는 데 걸리는 시간입니다. 이 시간을 줄이면 대기 시간이 최소화되어 사용자 경험이 향상됩니다.
숨어 있음: 라이브 이벤트의 실제 발생과 클라이언트 화면에 표시되는 시간 사이의 지연입니다. 즉, 콘텐츠를 캡처한 시간과 청중이 보는 시간 사이의 시간 차이입니다. 실시간 상호작용에는 더 낮은 지연 시간이 중요합니다.
버퍼링: 클라이언트가 버퍼링된 콘텐츠를 모두 소진하여 재생이 중단되거나 일시 중지되는 경우. 이러한 중단의 빈도와 지속 시간은 스트리밍 품질의 중요한 지표입니다.
이제 이러한 요소를 기준으로 HLS와 HTTP-FLV를 비교해 보겠습니다.
초기 로드 시간
HLS: HLS는 세그먼트화된 특성으로 인해 클라이언트가 재생을 시작하기 전에 여러 세그먼트를 다운로드하고 버퍼링해야 합니다. 이로 인해 특히 대역폭이 낮은 시나리오에서 초기 로드 시간이 길어질 수 있습니다. 일반적으로 요청 중에 오류가 발생하면 초기 버퍼링 및 지연이 발생할 수 있습니다.
HTTP-FLV: HTTP-FLV는 서버와 단일 연결만 설정하면 되고, 그 후 서버는 클라이언트에 지속적으로 콘텐츠를 전송합니다. 클라이언트는 서버에 요청을 반복적으로 전송하지 않고도 콘텐츠를 수신하고 재생하기만 하면 됩니다. 이렇게 하면 클라이언트가 연결이 설정된 직후에 비디오를 수신하고 재생하기 시작하므로 초기 로드 시간이 더 빨라집니다.
지연 시간
HLS: 전송 계층에서 HLS는 비디오를 분할하고 패키징해야 합니다. 패키징이 완료된 후 재생을 위해 실제 비디오 콘텐츠를 수신하려면 두 개의 추가 요청이 필요합니다. HLS는 초기 프레임 시간을 줄이기 위해 최적화되었지만, 고유한 이중 요청 메커니즘은 여전히 HTTP-FLV의 단일 요청 시간과 일치할 수 없습니다.
HTTP-FLV: HTTP-FLV를 사용하면 단일 연결이 설정되고 유지되므로 서버가 클라이언트에 비디오 콘텐츠를 지속적으로 스트리밍할 수 있습니다. 이 지속적인 연결은 지연 시간을 크게 줄여 즉각적인 피드백이 중요한 실시간 방송에 이상적입니다.
버퍼링
HLS: 비디오 콘텐츠를 분할하고 패키징하는 프로세스에는 본질적으로 추가 시간이 필요합니다. 전송 단계에서 각 세그먼트(일반적으로 2-3세그먼트 시간)를 처리하고 패키징해야 합니다. 또한 클라이언트는 TS 세그먼트를 요청하기 전에 먼저 M3U8 플레이리스트를 수신해야 합니다. 또한 CDN 계층에서 M3U8 파일을 캐싱해야 하므로 추가 시간 오버헤드가 발생합니다. 전반적으로 HLS는 라이브 콘텐츠를 처리하고 전송하는 데 추가 전송 및 캐싱 시간이 발생합니다.
HTTP-FLV: FLV의 작은 파일 크기와 단일 지속적 네트워크 연결로 인해 HTTP-FLV는 전송을 위한 시간 오버헤드로 단일 연결의 지연 시간만 필요합니다. 이를 통해 비디오 콘텐츠를 가능한 최소 전송 시간 내에 전송할 수 있습니다.
전반적인 사용자 경험에 영향을 미치는 주요 지표를 분석하면 HLS의 초기 전송 논리가 다소 오래되어 전송 프로세스 중에 많은 시간 비용이 발생한다는 것이 분명해집니다. HTTP-FLV는 초기 로드 시간, 대기 시간, 버퍼링의 세 가지 지표에서 HLS보다 성능이 뛰어납니다.
HTTP-FLV의 장점에 대한 전제 조건 및 제한 사항
HTTP-FLV는 라이브 스트리밍 경험에서 분명한 이점을 제공하지만 다음과 같은 특정 전제 조건과 제한 사항이 있습니다.
- CDN 아키텍처 수정: HTTP-FLV는 많은 CDN에서 HTTP를 통해 기본적으로 지원되지 않으므로 최적의 성능을 보장하기 위해 CDN 아키텍처를 수정해야 합니다. 예를 들어 CDNetworks는 이미 이러한 아키텍처 조정을 했습니다.
- 교차 장치 호환성: HTTP-FLV는 HLS만큼 강력한 크로스 디바이스 호환성을 제공하지 않습니다. 지연 시간을 줄이는 데 뛰어나지만, 이 이점은 제한된 디바이스 지원이라는 대가를 치릅니다. 그러나 HTTP-FLV의 낮은 지연 시간은 특히 즉각적인 피드백이 사용자 경험을 향상시키는 애플리케이션에서 사용자 유지 및 수익성에 대한 새로운 기회를 제공합니다.
하지만 이러한 한계에도 불구하고 HTTP-FLV가 제공하는 낮은 지연 시간 덕분에 시청자 참여에 최소한의 지연이 중요한 엔터테인먼트 라이브 스트리밍 시나리오에서 매우 인기가 있다는 점은 인정해야 합니다.
스트리밍 프로토콜의 미래 동향
라이브 스트리밍에서 실시간 상호작용과 즉각적인 피드백에 대한 수요가 증가함에 따라 저지연 프로토콜의 지속적인 진화가 촉진되고 있습니다. 지속적인 연결 메커니즘을 갖춘 HTTP-FLV는 이미 강력한 경쟁자입니다.
그러나 오늘 논의한 두 가지 프로토콜은 CDNetworks에서 지원하는 저지연 프로토콜의 하위 집합일 뿐이라는 점을 알아두는 것이 중요합니다. 이벤트 등급 저지연 라이브 스트리밍 기술이 필요한 미디어 회사의 경우, CDNetworks의 저지연 스트리밍 솔루션, WebRTC를 활용하는 것이 더 나은 선택일 수 있습니다. 반면, OTT 산업에 관해서는 HLS의 크로스 디바이스 호환성이 상당한 이점을 제공합니다.
이는 중요한 점을 강조합니다. "최고의" 프로토콜은 없으며, 귀하의 특정 요구 사항에 가장 잘 맞는 프로토콜만 있습니다. 비용과 혜택, 기업 브랜딩 및 사용자 경험의 균형을 맞추는 것이 가장 적합한 프로토콜을 선택하는 데 중요합니다.
그럼에도 불구하고, 신뢰할 수 있고 견고한 스트리밍 서비스 제공자를 선택하는 것이 미디어 산업에 가장 편리한 옵션입니다. 예를 들어 CDNetworks를 살펴보겠습니다. 광범위한 라이브 프로토콜을 지원하는 것 외에도 CDNetworks는 2,800개가 넘는 CDN을 자랑합니다. 아저씨 (Points of Presence) 글로벌, 뛰어난 성과, 뛰어난 고객 서비스. 이러한 속성으로 인해 CDNetworks는 시장에서 경쟁 우위를 유지하려는 미디어 회사의 매력적인 장기 파트너가 되었습니다.
이 심층 분석을 통해 스트리밍 미디어 분야에서 HTTP-FLV와 HLS의 응용 프로그램, 장점 및 단점을 살펴보았고, 이를 통해 귀하의 요구 사항에 맞는 스트리밍 프로토콜을 더 잘 이해하고 선택할 수 있도록 도왔습니다. 이 블로그가 귀중한 통찰력을 제공했기를 바랍니다. 추가 질문이나 추가 논의가 필요한 경우 언제든지 문의하세요. 서비스 문의하기 우리를.
