Streaming

Stream이란 데이터의 "흐름"입니다.

일반적으로 동영상을 HTTP를 통해 다운받게 되면 전부 다운로드 받을 때까지 재생하지 못합니다.

하지만 동영상을 "스트리밍"해 다운로드하면(Streaming over HTTP), 여러 조각(chunk)로 나눠서 전송하기 때문에 디스크에 저장하지 않고도 다운로드와 동시에 재생할 수 있습니다.

스트리밍을 사용하면...

동영상 대기 시간을 줄일 수 있습니다.
Adaptive streaming이라고 해서, bandwidth나 video size, network condition에 따라 어떻게 보낼 것인지 결정할 수 있는 유연성을 갖는 방식도 있습니다.
HTTP-based delivery는 대부분 클라이언트에서 지원하므로 신경쓸 필요가 없지만, HLS, DASH와 같은 스트리밍 프로토콜은 플러그인이나 라이브러리를 깔아야 할 수 있습니다.
- DASH는 넷플릭스에서 사용하고 있다고 하네요. (Streaming Over HTTP)

가장 많이 사용되는 방식입니다. YouTube 등 서비스에서 사용합니다. 가장 구현하기 쉬운 방식이며, 웹 서버에 동영상을 올려 두면 해당 영상의 주소만 알고 있다면 접근할 수 있습니다.

URL을 통해 플레이어로 접근하면 파일을 다운로드하고, 다운로드 된 부분을 재생합니다.
단점은 사용자가 실제 보는 만큼이 아닌 다운로드한 만큼 데이터가 소비된다는 것입니다.
인터넷 속도에 따라 원활한 서비스를 제공 받지 못할 수 있는데, YouTube를 시청하다가 재생이 멈추고 대기하는 경우가 이런 경우입니다.
동영상의 화질을 조절할 수 없습니다. YouTube 재생 도중 화질을 변경하면 처음부터 다시 다운로드하게 됩니다. 이는 YouTube가 화질을 변경하면 변경된 화질로 이어서 불러오는 것이 아니라 화질 별로 여러 개의 동영상을 올려 놓고 제공하기 때문입니다.

위의 Progressive download와 달리 데이터를 미리 받아오지 않고, 사용자가 현재 "시청"하고 있는 영상의 프레임만을 전송하며, 이미 시청한 데이터는 버립니다.

프로토콜은 다음 두 개를 사용합니다.

RTMP(Real Time Messaging Protocol)
- 플래시를 위한 스트리밍 프로토콜이며, 대부분 CDN이 지원하는 프로토콜이라고 하네요. (플래시 지원이 거의 끊기고 유지보수도 중단되어서...)
RTSP(Real Time Streaming Protocol)
- 스트리밍 서버나 CDN에서 많이 지원하지 않는다고 합니다.

특징으로는,

위의 두 방식 - progressive download와 RTMP, RTSP streaming의 장점을 결합한 방식입니다.

서버에서는 몇 초 단위의 비디오를 갖고 스트리밍하며, 이 조각을 연속된 스트림으로 클라이언트에서 연결시킵니다.

표준 웹 서버를 활용할 수 있기 때문에 CDN 업체들이 지원하고 있습니다.

Transport layer에서 사용되는 프로토콜인 TCP와 UDP 중 스트리밍에서 사용되는 프로토콜은 어떤 것일까요?

일부 스트리밍 방식에서는 UDP, 일부에서는 TCP가 사용된다고 합니다.

스트리밍의 경우 안정성보다 속도가 더 중요한 경우도 있습니다.

화상 회의에 참석하는 사람들은 모든 데이터가 전달될 때까지 기다리는 것보다 다른 회의 참석자들과 실시간으로 상호 작용하는 것을 선호합니다. 따라서 데이터 패킷 몇 개가 손실되는 것은 큰 문제가 아니므로 UDP를 사용해야 합니다.

물론 안정성이 더 중요한 경우도 있습니다.

HTTP 라이브 스트리밍 (HLS), MPEG-DASH 모두 전송에 TCP를 사용하고 있는데, 많은 주문형 비디오 서비스에서 TCP가 사용됩니다.

스트리밍 미디어 플레이어는 연결이 잠시 중단되더라도 비디오나 오디오가 계속 재생될 수 있도록 스트림의 몇 초 분량을 미리 로드하는데, 이를 버퍼링이라고 합니다.

스트리밍에 대한 많은 정보를 아래 출처에서 담아 왔습니다.

Last updated 1 year ago