HTTP应用流媒体分析
严格意义上,基于HTTP的VOD不算是真的流媒体,英文称为“progressive downloading”或者“pseudo streaming”,为什么这样呢?因为HTTP缺乏流媒体基本的流控,由此基于HTTP协议很难实现媒体播放的快进,快退,暂停。那么,通常的媒体播放器又是如何利用HTTP来实现这样的功能呢?
我们都知道,不管媒体文件有多大,HTTP都只是视它为一个HTTP的元素,可以只需要发送一个HTTP请求,WEB Server就会源源不断地将媒体流推送给客户端,而不管客户端是否接受,这就是HTTP协议本身没有流控的原因,那这样会带来什么后果呢?
如果服务器的推流速度和客户端同步, 那么基本不会出现什么大问题;如果小于客户端的接收流的速度,那么播放就会一卡一卡的;如果大于或者远大于客户端的接收速度,那又会是怎么样的结果呢?很不幸,在我们所有的ISTV项目中,只要是基于HTTP的VOD,都无一例外是第三种情况。因为我们VOD是基于局域网的,大家都知道,局域网的带宽资源是很丰富的,服务器的推流的速度肯定大于播放器的播放速度,那么在这么速度极端不协调的情况下,服务器的推流速度究竟由谁来限制呢?
答案是:TCP协议栈。我们的VOD点播是基于TCP的HTTP协议。TCP是安全的,可靠的,包肯定不会丢,服务器检测到客户端的接收缓冲区满了,就会减小发送数据滑动窗口的大小。所以 HTTP的流控是通过TCP协议栈来调节的&#
严格意义上,基于HTTP的VOD不算是真的流媒体,英文称为“progressive downloading”或者“pseudo streaming”,为什么这样呢?因为HTTP缺乏流媒体基本的流控,由此基于HTTP协议很难实现媒体播放的快进,快退,暂停。那么,通常的媒体播放器又是如何利用HTTP来实现这样的功能呢?
我们都知道,不管媒体文件有多大,HTTP都只是视它为一个HTTP的元素,可以只需要发送一个HTTP请求,WEB Server就会源源不断地将媒体流推送给客户端,而不管客户端是否接受,这就是HTTP协议本身没有流控的原因,那这样会带来什么后果呢?
如果服务器的推流速度和客户端同步, 那么基本不会出现什么大问题;如果小于客户端的接收流的速度,那么播放就会一卡一卡的;如果大于或者远大于客户端的接收速度,那又会是怎么样的结果呢?很不幸,在我们所有的ISTV项目中,只要是基于HTTP的VOD,都无一例外是第三种情况。因为我们VOD是基于局域网的,大家都知道,局域网的带宽资源是很丰富的,服务器的推流的速度肯定大于播放器的播放速度,那么在这么速度极端不协调的情况下,服务器的推流速度究竟由谁来限制呢?
答案是:TCP协议栈。我们的VOD点播是基于TCP的HTTP协议。TCP是安全的,可靠的,包肯定不会丢,服务器检测到客户端的接收缓冲区满了,就会减小发送数据滑动窗口的大小。所以 HTTP的流控是通过TCP协议栈来调节的&#