HTTP RTSP RTMP RTP 協議簡說 流媒體學習（一）

    HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。HTTP基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。全部的www文件都必須遵照這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收html頁面的方法。1960年美國人Ted Nelson構思了一種經過計算機處理文本信息的方法，並稱之爲超文本（hypertext）,這成爲了HTTP超文本傳輸協議標準架構的發展根基。

    RTSP（Real Time Streaming Protocol）,是一種實時流傳輸協議，是TCP/IP協議體系中的一個應用層協議。做爲一個應用層協議，RTSP提供了一個可供擴展的框架，它的意義在於使得實時流媒體數據的受控和點播變得可能。總的說來，RTSP是一個流媒體表示協議，主要用來控制具備實時特性的數據發送，但它自己並不傳輸數據，而是必須依賴於下層傳輸協議所提供的某些服務。RTSP能夠對流媒體提供諸如播放、暫 停、快進等操做，它負責定義具體的控制消息、操做方法、狀態碼等，此外還描述了與RTP間的交互操做（RFC2326）。

    RTMP協議是Real Time Message Protocol(實時信息傳輸協議)的縮寫，它是由Adobe公司提出的一種應用層的協議，用來解決多媒體數據傳輸流的多路複用（Multiplexing）和分包（packetizing）的問題。特色以下：

1. 適合長時間播放：由於RTMP支持的很完善，因此能作到flash播放RTMP流長時間不斷流，當時測試是100萬秒，即10天多能夠連續播放。
2. 對於商用流媒體應用，客戶端的穩定性固然也是必須的，不然最終用戶看不了還怎麼玩？我就知道有個教育客戶，最初使用播放器播放http流，須要播放不一樣的文件，結果就總出問題， 若是換成服務器端將不一樣的文件轉換成RTMP流，客戶端就能夠一直播放；該客戶走RTMP方案後，通過CDN分發，沒據說客戶端出問題了。
3. 延遲較低：比起YY的那種UDP私有協議，RTMP算延遲大的（延遲在1-3秒），比起HTTP流的延時（通常在10秒以上）RTMP算低延時。通常的直播應用，只要不是電話類對話的那種要求，RTMP延遲是能夠接受的。在通常的視頻會議應用中，RTMP延時也能接受，緣由是別人在說話的時候咱們通常在聽，實際上1秒延時沒有關係，咱們也要思考（話說有些人的CPU處理速度尚未這麼快）。
4. 有累積延遲：技術必定要知道弱點，RTMP有個弱點就是累積偏差，緣由是RTMP基於TCP不會丟包。 因此當網絡狀態差時，服務器會將包緩存起來，致使累積的延遲；待網絡情況好了，就一塊兒發給客戶端。這個的對策就是，當客戶端的緩衝區很大，就斷開重連。

    RTP數據協議負責對流媒體數據進行封包並實現媒體流的實時傳輸，每個RTP數據報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個字節的含義是固定的，而負載則能夠是音頻或者視頻數據。RTP用到的地方就是 PLAY ，服務器往客戶端傳輸數據用UDP協議，RTP是在傳輸數據的前面加了個12字節的頭(描述信息)。RTP載荷封裝設計本文的網絡傳輸是基於IP協議，因此最大傳輸單元(MTU)最大爲1500字節，在使用IP／UDP／RTP的協議層次結構的時候，這 其中包括至少20字節的IP頭，8字節的UDP頭，以及12字節的RTP頭。這樣，頭信息至少要佔用40個字節，那麼RTP載荷的最大尺寸爲1460字 節。以H264 爲例，若是一幀數據大於1460，則須要分片打包，而後到接收端再拆包，組合成一幀數據，進行解碼播放。

    RTCP控制協議須要與RTP數據協議一塊兒配合使用，當應用程序啓動一個RTP會話時將同時佔用兩個端口，分別供RTP和RTCP使用。RTP自己並 不能爲按序傳輸數據包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。一般RTCP會採用與RTP相同的分發機制，向會話中的 全部成員週期性地發送控制信息，應用程序經過接收這些數據，從中獲取會話參與者的相關資料，以及網絡情況、分組丟失機率等反饋信息，從而可以對服務質量進 行控制或者對網絡情況進行診斷。

    RTCP協議的功能是經過不一樣的RTCP數據報來實現的，主要有以下幾種類型：

• SR：發送端報告，所謂發送端是指發出RTP數據報的應用程序或者終端，發送端同時也能夠是接收端。(SERVER定時間發送給CLIENT)。
• RR：接收端報告，所謂接收端是指僅接收但不發送RTP數據報的應用程序或者終端。(SERVER接收CLIENT端發送過來的響應)。
• SDES：源描述，主要功能是做爲會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具備向會話成員傳達會話控制信息的功能。
• BYE：通知離開，主要功能是指示某一個或者幾個源再也不有效，即通知會話中的其餘成員本身將退出會話。
• APP：由應用程序本身定義，解決了RTCP的擴展性問題，而且爲協議的實現者提供了很大的靈活性。

簡單來講：

1. HTTP:  即超文本傳送協議(ftp即文件傳輸協議)。
2. RTSP: （Real Time Streaming Protocol），實時流傳輸協議。
3. RTMP: 全稱Routing Table Maintenance Protocol（路由選擇表維護協議）。

HTTP將全部的數據做爲文件作處理。http協議不是流媒體協議。RTMP和RTSP協議是流媒體協議。

 

這裏再提一下於流媒體有關的知識：

GOP-Cache

什麼是GOP？就是視頻流中兩個I幀的時間距離。
GOP有什麼影響？
Flash（解碼器）只有拿到GOP才能開始解碼播放。
也就是說，服務器通常先給一個I幀給Flash。
惋惜問題來了，假設GOP是10秒，也就是每隔10秒纔有關鍵幀，
若是用戶在第5秒時開始播放，會怎麼樣？
第一種方案：等待下一個I幀，
也就是說，再等5秒纔開始給客戶端數據。
這樣延遲就很低了，老是實時的流。
問題是：等待的這5秒，會黑屏，現象就是播放器卡在那裏，什麼也沒有，
有些用戶可能覺得死掉了，就會刷新頁面。
總之，某些客戶會認爲等待關鍵幀是個不可饒恕的錯誤，延時有什麼關係？
我就但願能快速啓動和播放視頻，最好打開就能放！

第二種方案：立刻開始放，
放什麼呢？
你確定知道了，放前一個I幀。
也就是說，服務器須要老是cache一個gop，
這樣客戶端上來就從前一個I幀開始播放，就能夠快速啓動了。
問題是：延遲天然就大了。

有沒有好的方案？
有！至少有兩種：
編碼器調低GOP，譬如0.5秒一個GOP，這樣延遲也很低，也不用等待。
壞處是編碼器壓縮率會下降，圖像質量沒有那麼好。