HTTP应用流媒体分析

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本身。试想，这样对服务器造成的压力有多大！！！
    下面就分析基于HTTP协议如何实现SEEK，PAUSE等操作。
    1）SEEK（快进和快退）
    先关闭之前的tcp连接，重新连接，发送http请求，该请求带了媒体的偏移位置。由此可见，每一次的快进和快退，都等于是重新开始播放，只是每次开始播放的位置不一样。
   2）PAUSE
    该操作就更有意思了，客户端暂停了播放，也就是不从缓冲区读取数据了，但是服务器不知道客户端停止了播放，依然不停地发送数据给客户端，直到客户端的接收缓冲区已满，然后服务器的数据发送不出去了，理论上是服务器端的滑动窗口的大小估计就是0了，然后协议栈还在不停在尝试发送数据，因为是基于tcp，这些数据还不能丢。nnd，这种方式实现暂停，协议栈都哭了。很不幸，MPLAYER就是这么干的。所以暂停的时间长了，就容易出现问题。
    虽然HTTP没有PAUSE的支持，但是针对PAUSE是可以优化的，优化的方法是，将媒体文件分片，分片的大小以稍小于TCP协议栈的缓冲区大小为宜。HTTP请求一次只请求一个分片的大小，暂停播放后，就不在发送分片请求了。这样可以保证让服务器运行的时间长一些，播放器暂停理论上可以无限长了。