HTTP 기반 어댑티브 스트리밍

전통적인 스트리밍

전통적인 스트리밍 프로토콜의 대표적인 예는 RTSP(Real-Time Streaming Protocol)이다.

서버는 클라이언트와의 접속이 이루어지면 세션을 생성한다. 이 세션은 클라이언트의 재생 상태를 유지하는데 사용한다. 클라이언트의 명령(시작, 일시정지, 정지 등)에 따라서 이러한 상태를 변경한다.

세션이 살아있는 동안 서버는 작은 패킷으로 미디어 데이타를 전송한다. 서버는 재생 속도에 따라서 적절한 양의 패킷을 전송하는 흐름 제어의 역활까지 한다. 특히 전송 프로토콜이 UDP 상에서 동작할 경우는 필수적이다.

프로그레시브 다운로드

미디어 파일을 받으면서, 다시말하면 전체 파일을 모두 받기 전에, 재생하는 방식이다. 아직 받지 않은 지점으로 이동하려면 서버와 클라이언트가 HTTP 1.1 스펙을 지원해야 한다.

보통은 대역폭이 허용하는 만큼 최대한 파일을 받기 때문에 시청한 부분을 훨씬 초과해서 받는 경우가 대부분이다.

RTSP가 클라이언트의 상태를 관리하고 유지하는 프로토콜이라면, HTTP는 클라이언트의 상태에 대해서 신경을 쓰지 않는다. 하나의 요청이 독립된 일회성 세션으로 처리된다.

위에 두 방식의 단점

전통적인 스트리밍

• 세션의 관리와 흐름 제어로 인한 개발의 복잡도가 증가한다.
• 위에 작업을 수행함으로 서버의 부하가 발생한다.
• 방화벽이나 라우터에서 막히는 경우가 많다.
  

프로그레시브 다운로드

• 파일의 유출 가능성이 높다. 미디어 파일은 상대적으로 크기 때문에 파일의 캐싱이 메인 메모리가 아닌 로컬 저장소에 이루어지는 경우가 많다.
• 시청하는 부분을 훨씬 초과해서 받아서 네트워크 자원의 낭비가 발생할 수 있다. 예를 들면, 10초만 시청하고 종료했어도 1분 이상 파일을 받았을 수 있다.^[각주:1]
  

HTTP 기반 어댑티브 스트리밍

기존의 고전적인 스트리밍 방식과 HTTP 다운로드 방식의 결합이다. 간략히 설명하면 컨텐츠는 조각^[각주:2]으로 분리되어 있고, 각각의 조각을 HTTP로 전송한다. 고전적인 스트리밍의 개념으로 생각하면 패킷은 컨텐츠 조각이 되고, 데이타 전송의 하위 프로토콜인 TCP 자리에 HTTP가 있는 셈이다.

HTTP 기반 어댑티브 스트리밍 장점

• 스트리밍 세션을 유지하고 관리하지 않아도 된다. 따라서 구현이 쉽고, 서버의 부하가 적다.
• 보통 HTTP는 방화벽이나 라우터의 문제점으로부터 자유롭다.
• HTTP를 위한 인프라(프록시, 캐시 등)를 그대로 사용할 수 있다.
• 네트워크 상태에 따라서 동적으로 적합한 조각을 받을 수 있다.
• 불필요하게 많은 양을 데이타를 받지 않는다.
  

HTTP 기반 어댑티브 스트리밍을 구성하는 두가지 요소

• 인코딩된 비디오/오디오 스트림 자체
• 스트림을 명시한 Manifest 파일

대표적인 HTTP 기반 어댑티브 스트리밍

• HTTP Live Streaming (애플)
• Smooth Streaming (마이크로소프트)
• HTTP Dynamic Streaming (어도비)
• Dynamic Adaptive Streaming over HTTP (ISO Standard)
  

1. 일부 HTTP 서버는 미디어의 비트율에 따라서 적절한 양을 전송하는 기능을 제공한다. [본문으로]
2. 청크(chunk)나 세그먼트(segment)로 불린다. [본문으로]