월드컵 라이브 스트리밍을 지탱하는 기술, HLS 프로토콜에 대해

메시의 첫 월드컵 우승을 기원하며 2022년 12월 19일 오전 12시 15분에 작성된 글입니다.

HLS 프로토콜, 그기 돈이 됩니까?
우리 쑨양 월드컵 스트리밍에 도움이 됩니까?

사진 출처 : 나무위키

발단

@broccolism님의 포스트를 보며 실시간 동영상 스트리밍 서비스들이 어떻게 동작할까? 의문점을 품게 되어 인터넷 세상을 뒤적이다 보니 흥미로운 포인트들이 몇 개 있었다.

아래 캡쳐는 네이버 스포츠에서 제공되는 12월 19일 00시에 진행된 프랑스 - 아르헨티나 경기를 개발자 도구로 열어 어떤 일이 일어나는지를 일부 발췌한 것이다.

흥미로운 내용이 나온다.
폴링 방식으로는 : 현재 진행 중인 경기의 통계 정보를 받아오는 것처럼 보인다.
특정 주소로 계속 요청하는 내용을 보니 : #EXTM3U 부터, 시간별로 정확히 2초(2000ms) 마다 재생될 동영상을 명시적으로 나타내는 것처럼 보인다. 그리고 좀 더 찾아보니..

HLS 프로토콜

HLS 프로토콜 위키 백과
RFC 8216

HLS 프로토콜은 애플이 개발한 HTTP 기반 라이브 스트리밍을 위한 'adaptive bitrate streaming' 프로토콜이다.

HLS 프로토콜은 HTTP 프로토콜을 기반으로,
1. 실시간으로 이어지는 동영상들을
2. 몇 초 단위로 작게 잘려진 영상으로
3. 계속해서 요청하고 다운로드 받는 방식으로 동작한다.

또 HLS는 RFC 8216에서도 기술되었듯이 근미래에 제공될 작은 영상들의 목록을 확인하고 관리하기 위해서 바로 아래에 기술될 M3U 프로토콜을 사용한다.
작게 잘린 동영상들은 .ts으로 끝나는 동영상 포맷으로 제공되고 있었다.
HLS 프로토콜에 대한 자세한 내용은 이 곳에 잘 설명되어 있었다. 2012년에 작성된 포스트이지만 10년이 지난 오늘날에도 그 기조는 유지한 채로 발전해 온 역시 깊은 스트리밍 방식이라는 생각이 든다.

M3U 프로토콜

M3U (MP3 URL[1][2] or Moving Picture Experts Group Audio Layer 3 Uniform Resource Locator[3] in full) is a computer file format for a multimedia playlist. One common use of the M3U file format is creating a single-entry playlist file pointing to a stream on the Internet. The created file provides easy access to that stream and is often used in downloads from a website, for emailing, and for listening to Internet radio.
Although originally designed for audio files, such as MP3, it is commonly used to point media players to audio and video sources, including online sources. M3U was originally developed by Fraunhofer for use with their Winplay3 software,[4] but numerous media players and software applications now support the format.
Careless handling of M3U playlists has been the cause of vulnerabilities in many music players such as VLC media player,[5] iTunes,[6] Winamp,[7] and many others.[8]

M3U 프로토콜 위키 백과

M3U 프로토콜은 '멀티미디어 재생목록'을 표현하는 프로토콜이다.
즉 전송에 직접 사용되는 프로토콜이 아닌, HLS을 서빙하기 위해 잘게 자른 동영상들을 실시간으로 스트리밍할 수 있도록 보조하는 프로토콜에 가깝다.
개발자 도구에서 볼 수 있었던 #EXTM3U 관련한 내용들은 바로 이 M3U 프로토콜로 교환되고 있었던 정보들이다.
M3U 프로토콜을 UTF-8 인코딩하여 사용하는 것을 M3U8 프로토콜이라고 부른다.

HLS의 특징

HLS는 'adaptive' 비트레이트 스트리밍 프로토콜이다.
클라이언트의 네트워크 품질이 좋지 못하다면 기존 720p로 제공되는 스트리밍을 480p, 360p로도 제공할 수 있다는 의미이다.
또한 클라이언트가 위치한 region에 따라 다른 오디오 리소스를 제공하는 기술도 제공할 수 있다.
웹 상에서 점차 다양해지는 클라이언트의 요구를 충족시키기 위한 최적의 프로토콜이라는 생각이 든다.

그런데 왜 하필 HLS를 사용할까?

그런데, 왜 UDP를 사용하지 않고 TCP 상에서 동작하는 HLS를 사용할까?

TCP는 1) 연결 지향형 프로토콜이고 2) UDP보다 연결을 맺고 유지하는데 리소스를 사용하기에 다소 무겁지만 3) 전송된 데이터가 전달됨을 보장하고 4) 순서에 맞게 데이터를 송수신 할 수 있다는 장점이 있다.

기억을 더듬어 봐도 분명 학부 네트워크 수업 시간에서는 실시간 멀티미디어 재생과 같이 오버헤드가 적은 빠른 통신을 위해서는 UDP가 적합하다고 배웠었는데 뭔가 이상하지 않은가?

왜 대규모 동영상 스트리밍 서비스에서 TCP 위에서 동작하는 HTTP 기반 프로토콜을 사용할까?

나름 이유를 곰곰히 생각해서 정리해본 결과는 아래와 같다.

이유 1. 동영상 스트리밍 서비스만을 위해 타 프로토콜을 사용하는 환경을 구축하는데에는 비용이 많이 든다.

전 세계의 수많은 서비스들이 이미 HTTP를 통해 제공되고 있다. 설사 다른 프로토콜이 기존에 없던 방법을 새롭게 고안해서 4k 동영상 스트리밍을 극도로 실시간에 가깝게 제공할 수 있다고 해도, 그 방법을 적용하기 위해 추가적인 비용이 드는 것이라면 서비스를 제공해 이윤을 내야 하는 기업 입장에서는 그저 고려해 볼 만한 옵션 1이 된다.

출처 : Image by pch.vector on Freepik

하지만 HLS는 HTTP를 기반으로 하는 프로토콜이다 보니, 기업 입장에서는 적용하는데 별다른 비용이 들지 않는다. 심지어 실시간 동영상 스트리밍 성능도 다른 프로토콜과 비교해 보았을 때 그렇게 나쁘지 않다.
연구 목적으로 위성에서 쏴주는 동영상 신호를 손실 없이 받는 것이 무척 중요하다면 HLS가 아닌 특수한 프로토콜을 사용해야 하는 것이 맞을 것이다. 하지만 '적당히 실시간에 가까운' 동영상을 사람들이 가장 많이 사용하는 환경인 '웹에서' 제공하는 것이 목적이라면 구태여 리스크를 감내하며 다른 프로토콜을 사용할 이유가 하나도 없다는 뜻이다.

이유 2. 대규모 서비스에 몰리는 HTTP 트래픽을 캐싱을 통해 처리할 수 있기 때문이다.

일반적으로 많은 사람들이 인터넷 상의 동일한 리소스를 요청하게 되면 트래픽을 감당하기 무척 어렵다. 대기업에서 제공되는 서비스들이 항상 불규칙한 트래픽 피크를 염두에 두고 아키텍쳐와 서비스를 설계하는 이유이기도 하다. 안정적으로 서비스가 되어야 하니까!

HTTP 서비스의 트래픽을 줄인다는 방면에서 가장 효과적인 방법은 캐싱이다. CDN 서버를 사용하여 여러 사람들이 원할 것으로 예상되는 리소스를 분산시키는 방법은 대량의 트래픽이 본 서비스의 서버로 들어오지 않도록 하는 가장 효과적인 방법이다.

HLS를 사용할 경우 캐싱을 효과적으로 사용할 수 있다. 어차피 많은 사람들이 요구하는 영상은 10분 전이나 30분 전 영상이 아니다. 실시간 동영상 스트리밍 서비스를 사용하는 사용자들은 현재에서 몇 초 정도 차이나는, 실시간에 가까운 영상을 원하는 것이기 때문에 캐싱 전략의 효율을 극대화할 수 있다. 특히 월드컵 같이 전 세계 사용자가 지켜보는 특수한 이벤트라면 더더욱 트래픽에 민감할 수 밖에 없고 따라서 캐싱을 효율적으로 사용하도록 강제될 수 밖에 없는 환경일 것이다.

이유 3. 기존 HTTP 환경의 장점을 이용할 수 있다.

동영상 스트리밍 서비스는 보통 다른 부가 기능과 함께 제공되는 경우가 많다.
예시로 네이버에서 중계하는 응원톡 서비스는 월드컵 경기를 보는 여러 사람들과 함께 실시간에 가까운 채팅 기능을 사용할 수 있도록 해주는 서비스이다.
이런 서비스를 제공하기 위해서는 일반적으로 기존 환경에서 로그인을 통한 인증과 인가를 검증한 후에 이뤄지고, 이 사용자 인증과 인가는 별도의 서비스를 따로 구축할 필요 없이 기존 환경에서 이뤄지던 것을 사용하는 것이 경제적으로 합리적이다.

또, HTTP의 특성상 NAT 환경이나 네트워크 이동이 되는 환경에서도 클라이언트가 아무런 문제 없이 스트리밍을 할 수 있다는 점 역시 매력적이다.

다른 실시간 스트리밍 서비스에서는 어떤 프로토콜을 사용할까?

IF-KAKAO 라이브 스트리밍에서도 HLS 프로토콜을 사용하는 것을 볼 수 있었다. 이 세션을 라이브로 봤었는데, 지금은 유튜브 링크로 대체되어 스크린샷은 따로 남아있지 않다 ㅠ

Youtube 라이브 스트리밍에서는 아래와 같이 DASH 프로토콜을 사용하는 것을 볼 수 있었는데,

찾아보니 다른 프로토콜도 사용하는 것 같다.. 유튜브 라이브 스트리밍 프로토콜 종류에 대해
DASH 프로토콜은 HLS와 유사하게 라이브 영상을 작은 길이의 동영상들로 잘라서 HTTP 위에서 서빙한다는 점은 동일하나 지원하는 코덱과 같은 세부 스펙에서는 조금 차이가 있는 것으로 보인다. 비교 자료

좀 더 latency가 작은 RTSP와 같은 프로토콜에서는 UDP도 섞어서 사용하기도 하는 것 같다.

저희는 월드컵을 인터넷/IPTV가 아니라 지상파/케이블 TV로 보고 있어요

생각해보면 내가 어렸을 때에는 월드컵 경기를 볼 때 텔레비전 앞에 옹기종기 앉아 봤었던 기억이 난다.
수십년이 지난 지금이야 많이 IPTV로 바뀌는 추세이지만 그 전에는 어땠을까?

https://en.wikipedia.org/wiki/Cable_television
https://www.geeksforgeeks.org/cable-tv-networks/

우리나라에서 케이블 TV는 그동안 계속 RF로만 신호를 브로드캐스팅 해오고 있었다. 예전 TV는 RF 단자로 받은 신호 데이터를 바로 TV로 쐈었고, 케이블 TV의 경우 그 신호를 중간의 셋톱박스로 전달하여 다시 음성 및 영상 데이터로 변환하여 TV에 연결하여 볼 수 있었던 기억이 난다.
그러나 최근 관련 법이 개정되면서 케이블 TV에서 IP로도 보낼 수 있도록 변경되는 추세가 되는 것 같다.

이번에 알고자 했지만 알지 못했던 것

네이버 스포츠에서는 다양한 화질의 동영상을 제공한다. 상대적으로 트래픽이 더 몰리는 우리나라 경기에서는 찾을 수 없었지만, 우리나라 경기가 아닌 상대적으로 인기가 덜한 타 국가의 조별 경기에서는 1080p 화질을 선택하여 시청할 수 있었다. 그리고 HD 마크가 붙은 720p나 1080p 화질을 선택하여 스트리밍 할 경우 네이버에서 제공하는 크롬 익스텐션인 네이버 동영상 플러그인을 사용하여 작은 길이의 동영상을 네이버의 캐시 서버로 바로 요청하는 것이 아니라 localhost로 요청하는 것을 볼 수 있었다.

480p 화질을 선택했을 때에는

1080p 화질을 선택했을 때에는

상기처럼 localhost의 17080포트로 요청을 보내는 것을 볼 수 있었다. exp = 1671407818 부분은 아마도 timestamp로 추정되고, 여러 번의 새로고침 끝에 네이버의 스포츠 스트리밍 서비스로 접속 개시한 시각을 가르키고 있었다.

또 실험을 해보니, 아래 링크는 컴퓨터가 아닌 모바일 데이터망으로도 접속했을 때 네이버의 중계 서비스를 거치지 않고 480p로 바로 스트리밍을 할 수 있었다. 이미 종료된 경기의 경우 400 HTTP 코드를 반환하는 것을 볼 수 있었다.

https://livecloud.pstatic.net/sports/lip2_kr/anmssgpu0005/UiOA1cAUvKFZDTaq_2pZoxv-eiTNU-ScV4lBZA4DnM96WrRiL8MF4j6ouvDO_g3k4OWk2r_1sxE0boeN/hdntl=exp=1671408193~acl=*%2FUiOA1cAUvKFZDTaq_2pZoxv-eiTNU-ScV4lBZA4DnM96WrRiL8MF4j6ouvDO_g3k4OWk2r_1sxE0boeN%2F*~data=hdntl~hmac=2df911aa3542d0c435983b6c7872ffca5e91235f1d8dbdd750939944021eee75/chunklist_480.stream.m3u8

하지만 이번에는 궁금했던 내용 중 하나인 왜 바로 캐시 서버로 요청하는 것이 아니라 별도의 크롬 익스텐션을 사용하여 한번 로컬 환경을 거치는지?에 대한 이유를 찾지 못했다. 로컬에서 무슨 작업을 하고 있는 걸까? wireshark를 열어서 보려 해도 잘 찾지 못했다..

안타깝지만 카타르 월드컵 경기가 오늘로 마지막이다. 이 내용은 4년 뒤의 나에게 맡겨 보는 과제로 남겨두는 것으로..

사진 출처 : 손흥민 선수 인스타그램

3줄 요약 (TL;DR)

1. HTTP는 전세계에서 가장 많이 사용되고 있는 프로토콜이고, 성능 향상을 위해 그동안 많은 노력을 기울여 온 프로토콜이다.
2. 안정적으로 스트리밍 서비스를 제공해야 하는 기업 입장에서는 HTTP에 기반한 HLS 프로토콜을 사용해서 얻을 수 있는 비용적 이점이 크다.
3. 따라서 오늘날의 많은 실시간 동영상 스트리밍 서비스들은 HLS 프로토콜을 사용하여 서비스를 제공하고 있다.