標籤：流媒體 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請求一次只請求一個分區的大小，暫停播放後，就不在發送分區請求了。這樣可以保證讓伺服器啟動並執行時間長一些，播放器暫停理論上可以無限長了。
HTTP應用流媒體分析
