在Internet上,流（Streaming）的定義非常廣泛，主要是指通過網路傳輸多媒體資料的技術總稱。

一、流媒體的定義

流媒體包含廣義和狹義兩種內涵：
 . 廣義流媒體
   指的是使音訊和視訊形成穩定和連續的傳輸流和回放流的一系列技術、方法和協議的總稱，即流媒體技術；
 . 狹義流媒體
   是相對於傳統的下載-回放方式而言的，指的是一種從Internet上獲取音訊和視訊等多媒體資料的新方法，
   它能夠支援多媒體資料流的實時傳輸和實時播放。

通過運用流媒體技術，
伺服器能夠向客戶機發送穩定和連續的多媒體資料流，
客戶機在接收資料的同時以一個穩定的速率回放，而不用等資料全部下載完之後再進行回放。

流式傳輸有:
順序流式傳輸(Progressive Streaming)和實時流式傳輸(Realtime Streaming)兩種方式。
 . 實時流式傳輸(Realtime Streaming)是實時傳送，
   特別適合現場事件，實時流式傳輸必須匹配連線頻寬，這意味著影象質量會因網路速度降低而變差，以減少對傳輸頻寬的需求。
   "實時"的概念是指在一個應用中資料的交付必須與資料的產生保持精確的時間關係，這需要相應的協議支援，
   它包括的協議有：
      RTP, RTCP和RTSP

 . 順序流式傳輸(Progressive Streaming)
   順序流式傳輸是順序下載，順序流式傳輸不像實時流式傳輸那樣，可以在傳輸期間根據使用者連線的速度進行調整。
   它包括的協議比較多，有：
      RTMP， HTTP, MMS， 和HLS

二、RTP，RTCP和RTSP

2.1 RTP

參考文件 RFC3550/RFC3551
Real-time Transport Protocol)是用於Internet上針對多媒體資料流的一種傳輸層協議。
RTP協議詳細說明了在網際網路上傳遞音訊和視訊的標準資料包格式。
RTP協議常用於流媒體系統（配合RTCP協議），視訊會議和一鍵通（Push to Talk）系統（配合H.323或SIP），
使它成為IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一起使用，而且它是建立在UDP協議上的。 

RTP 本身並沒有提供按時傳送機制或其它服務質量（QoS）保證，它依賴於低層服務去實現這一過程。 
RTP 並不保證傳送或防止無序傳送，也不確定底層網路的可靠性。 
RTP 實行有序傳送， RTP 中的序列號允許接收方重組傳送方的包序列，同時序列號也能用於決定適當的包位置，

例如：在視訊解碼中，就不需要順序解碼。

RTP 由兩個緊密連結部分組成： 
  RTP ― 傳送具有實時屬性的資料；
  RTP 控制協議（RTCP） ― 監控服務質量並傳送正在進行的會話參與者的相關資訊。

2.2 RTCP

實時傳輸控制協議（Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP）
是實時傳輸協議（RTP）的一個姐妹協議。RTCP為RTP媒體流提供通道外（out-of-band）控制。
RTCP本身並不傳輸資料，但和RTP一起協作將多媒體資料打包和傳送。
RTCP定期在流多媒體會話參加者之間傳輸控制資料。RTCP的主要功能是為RTP所提供的服務質量（Quality of Service）提供反饋。

RTCP收集相關媒體連線的統計資訊，例如：傳輸位元組數，傳輸分組數，丟失分組數，jitter，單向和雙向網路延遲等等。
網路應用程式可以利用RTCP所提供的資訊試圖提高服務質量，比如限制資訊流量或改用壓縮比較小的編解碼器。
RTCP本身不提供資料加密或身份認證。SRTCP可以用於此類用途。

實現實時視訊流時，先用採集裝置，直接把視訊做成 H.264 的 NAL unit,而後通過 RTP打包，傳輸給客戶端
有一篇文就是介紹如何把 NALu 用RTP打包的
http://www.rosoo.net/a/201108/14896.html


圖1 基於RTP的H.264視訊傳輸

2.3 SRTP & SRTCP

參考文件 RFC3711
安全實時傳輸協議（Secure Real-time Transport Protocol或SRTP）
是在實時傳輸協議（Real-time Transport Protocol或RTP）基礎上所定義的一個協議，
旨在為單播和多播應用程式中的實時傳輸協議的資料提供加密、訊息認證、完整性保證和重放保護。
它是由David Oran（思科）和Rolf Blom（愛立信）開發的，並最早由IETF於2004年3月作為RFC3711釋出。

由於實時傳輸協議和可以被用來控制實時傳輸協議的會話的實時傳輸控制協議（RTP Control Protocol或RTCP）有著緊密的聯絡，
安全實時傳輸協議同樣也有一個伴生協議，它被稱為安全實時傳輸控制協議（Secure RTCP或SRTCP）；
安全實時傳輸控制協議為實時傳輸控制協議提供類似的與安全有關的特性，就像安全實時傳輸協議為實時傳輸協議提供的那些一樣。

在使用實時傳輸協議或實時傳輸控制協議時，使不使用安全實時傳輸協議或安全實時傳輸控制協議是可選的；
但即使使用了安全實時傳輸協議或安全實時傳輸控制協議，所有它們提供的特性（如加密和認證）也都是可選的，
這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協議時，必須要用到其訊息認證特性。

2.4 RTSP

參考文件 RFC2326
是由Real Networks和Netscape共同提出的。該協議定義了一對多應用程式如何有效地通過IP網路傳送多媒體資料。
RTSP提供了一個可擴充套件框架，使實時資料，如音訊與視訊的受控、點播成為可能。
資料來源包括現場資料與儲存在剪輯中的資料。

該協議目的在於控制多個數據傳送連線，為選擇傳送通道，如UDP、多播UDP與TCP提供途徑，併為選擇基於RTP上傳送機制提供方法。

RTSP（Real Time Streaming Protocol）是用來控制聲音或影像的多媒體串流協議，
並允許同時多個串流需求控制，傳輸時所用的網路通訊協定並不在其定義的範圍內，
伺服器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，
但並不特別強調時間同步，所以比較能容忍網路延遲。
而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低伺服器端的網路用量，
更進而支援多方視訊會議（Video Conference）。 
因為與HTTP1.1的運作方式相似，所以代理伺服器《Proxy》的快取功能《Cache》也同樣適用於RTSP，
並因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。

2.5 RTSP 和RTP的關係

RTP不象http和ftp可完整的下載整個影視檔案，它是以固定的資料率在網路上傳送資料，
客戶端也是按照這種速度觀看影視檔案，當影視畫面播放過後，就不可以再重複播放，除非重新向伺服器端要求資料。

RTSP與RTP最大的區別在於：
   RTSP是一種雙向實時資料傳輸協議，它允許客戶端向伺服器端傳送請求，如回放、快進、倒退等操作。

當然，RTSP可基於RTP來傳送資料，還可以選擇TCP、UDP、組播UDP等通道來發送資料，具有很好的擴充套件性。
它時一種類似與http協議的網路應用層協議。

​
圖2 RTP-RTCP-RTSP的關係
RTP：實時傳輸協議（Real-time Transport Protocol） 
     RTP/RTCP是實際傳輸資料的協議 
     RTP傳輸音訊/視訊資料，如果是PLAY，Server傳送到Client端，如果是RECORD，可以由Client傳送到Server 
     整個RTP協議由兩個密切相關的部分組成：RTP資料協議和RTP控制協議（即RTCP） 
RTCP：RTCP包括Sender Report和Receiver Report，用來進行音訊/視訊的同步以及其他用途，是一種控制協議

RTSP：實時流協議（Real Time Streaming Protocol，RTSP） 
     RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義可以知道起對話和控制作用 
     RTSP的對話過程中SETUP可以確定RTP/RTCP使用的埠，PLAY/PAUSE/TEARDOWN可以開始或者停止RTP的傳送，等等 

2.6 SDP

會話描述協議（SDP）為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。
會話目錄用於協助多媒體會議的通告，併為會話參與者傳送相關設定資訊。
SDP 即用於將這種資訊傳輸到接收端。
SDP 完全是一種會話描述格式 ― 它不屬於傳輸協議 ― 
它只使用不同的適當的傳輸協議，包括會話通知協議（SAP）、會話初始協議（SIP）、實時流協議（RTSP）、
MIME 擴充套件協議的電子郵件以及超文字傳輸協議（HTTP）。

SDP 的設計宗旨是通用性，它可以應用於大範圍的網路環境和應用程式，而不僅僅侷限於組播會話目錄，
但 SDP 不支援會話內容或媒體編碼的協商。

在因特網組播骨幹網（Mbone）中，會話目錄工具被用於通告多媒體會議，
併為參與者傳送會議地址和參與者所需的會議特定工具資訊，這由 SDP 完成。
SDP 連線好會話後，傳送足夠的資訊給會話參與者。
SDP 資訊傳送利用了會話通知協議（SAP），它週期性地組播通知資料包到已知組播地址和埠處。
這些資訊是 UDP 資料包，其中包含 SAP 協議頭和文字有效載荷（text payload）。
這裡文字有效載荷指的是 SDP 會話描述。此外資訊也可以通過電子郵件或 WWW （World Wide Web） 進行傳送。
SDP 文字資訊包括：
   會話名稱和意圖；
   會話持續時間；
   構成會話的媒體；
   有關接收媒體的資訊（地址等）。

協議結構
SDP 資訊是文字資訊，採用 UTF-8 編 碼中的 ISO 10646 字符集。SDP 會話描述如下：（標註 * 符號的表示可選欄位）：
v = （協議版本）
o = （所有者/建立者和會話識別符號）
s = （會話名稱）
i = * （會話資訊）
u = * （URI 描述）
e = * （Email 地址）
p = * （電話號碼）
c = * （連線資訊 ― 如果包含在所有媒體中，則不需要該欄位）
b = * （頻寬資訊）

一個或更多時間描述（如下所示）：
z = * （時間區域調整）
k = * （加密金鑰）
a = * （0 個或多個會話屬性行）
0個或多個媒體描述（如下所示）

時間描述
t = （會話活動時間）
r = * （0或多次重複次數）

媒體描述
m = （媒體名稱和傳輸地址）
i = * （媒體標題）
c = * （連線資訊 — 如果包含在會話層則該欄位可選）
b = * （頻寬資訊）
k = * （加密金鑰）
a = * （0 個或多個會話屬性行）

三、RTMP

3.1 RTMP(Real Time Messaging Protocol)實時訊息傳送協議
是Adobe Systems公司為Flash播放器和伺服器之間音訊、視訊和資料傳輸開發的開放協議。

它有三種變種：
1)工作在TCP之上的明文協議，使用埠1935；
2)RTMPT封裝在HTTP請求之中，可穿越防火牆；
3)RTMPS類似RTMPT，但使用的是HTTPS連線；
  RTMP協議(Real Time Messaging Protocol)是被Flash用於物件,視訊,音訊的傳輸.這個協議建立在TCP協議或者輪詢HTTP協議之上.
  RTMP協議就像一個用來裝資料包的容器,這些資料既可以是AMF格式的資料,也可以是FLV中的視/音訊資料.
  一個單一的連線可以通過不同的通道傳輸多路網路流.這些通道中的包都是按照固定大小的包傳輸的.

3.2 RTMP VS TCP&UDP  

 . TCP為點對點的協議，
   這意味著各個客戶需要分開客戶機/伺服器連結，因而無法在網路級實現對多個客戶機的資料廣播。
   如果有一個數據流必須同時被傳送到多個客戶機，伺服器必須傳送資料流的副本到各個客戶機，
   TCP能夠根據網路頻寬和擁擠程度動態地調節傳送速度並重新發送丟失的資料包，這樣雖然保證了資料傳輸的可靠性，
   但是對伺服器資源耗費較大，在資料流大的場合難以保證資料流傳輸的實時性。

 . UDP為不可靠傳輸協議，
   在傳送端，UDP傳送資料的速度僅僅是受應用程式生成資料的速度，計算機的能力和傳輸頻寬的限制；
   在接收端，UDP把每個訊息段放在佇列中，應用程式每次從佇列中讀一個訊息段。
   UDP協議不需要維護連線狀態，也不認為每個資料包都必須到達接受端，因此網路負荷比TCP小，傳輸速度也要比TCP快；
   但在網路越擁擠時，越有更多的資料包丟失。

 . RTMP協議是一個專門為高效傳輸視訊，音訊和資料而設計的協議。
   它通過建立一個二進位制TCP連線或者連線HTTP隧道實現實時的視訊和聲音傳輸。

共享物件是RTMP資料中一種比較重要的資料型別，任何客戶端改變資料時，共享物件能夠及時更新伺服器端的資料，
這樣，每個客戶端都能夠及時瞭解到資料的變化。

RTMP比傳統媒介伺服器流出的媒介協議支援更多。
它支援可能包含聲音，影像和指令碼資料從伺服器到客戶和從客戶到伺服器多條線路的動態傳輸。RTMP對聲音、影像和指令碼資料分別處理。

聲音和視訊資料被分開地緩衝在伺服器中。
如果聲音資料在聲音緩衝器中達到某一極限，所有在緩衝器中的資料將被丟掉，
並且最近到達的資料被允許開始收集在緩衝中並被送到各個客戶。
視訊資料被以相似的方式處理，不同是當新的關鍵幀到達時，緩衝器中資料才被清除。
在丟掉舊的幀資料時，如果發現客戶端的資料有誤，則將新舊兩個不同的幀進行擬合。

RTMP對資料給予不同的優先級別。
在實時交談中，聲音是最重要的，影像給予低優先順序，而指令碼資料被給予的優先權介於聲音和影像中間。

RTMP協議可以建立多個數據流，但是每個資料流只能有一個方向。
使用RTMP可以構建這樣的一個系統，客戶端可以同時與RTMP伺服器和應用伺服器進行互動，使得服務端的負荷得以分散，
雖然在這種改進的系統結構中，RTMP伺服器的效能要求比較高。

四、MMS

MMS (Microsoft Media Server Protocol)，中文“微軟媒體伺服器協議”，用
來訪問並流式接收 Windows Media 伺服器中 .asf 檔案的一種協議。
MMS 協議用於訪問 Windows Media 釋出點上的單播內容。

MMS 是連線 Windows Media 單播服務的預設方法。
若觀眾在 Windows Media Player 中鍵入一個 URL 以連線內容，而不是通過超級連結訪問內容，則他們必須使用MMS 協議引用該流。
MMS的預設埠（埠）是1755

當使用 MMS 協議連線到釋出點時，使用協議翻轉以獲得最佳連線。
“協議翻轉”始於試圖通過 MMSU 連線客戶端。 

MMSU 是 MMS 協議結合 UDP 資料傳送。如果 MMSU 連線不成功，則伺服器試圖使用 MMST。
MMST 是 MMS 協議結合 TCP 資料傳送。

如果連線到編入索引的 .asf 檔案，想要快進、後退、暫停、開始和停止流，則必須使用 MMS。
不能用 UNC 路徑快進或後退。若您從獨立的 Windows Media Player 連線到釋出點，則必須指定單播內容的 URL。
若內容在主釋出點點播發布，則 URL 由伺服器名和 .asf 檔名組成。例如：mms://windows_media_server/sample.asf。其中 
windows_media_server 是 Windows Media 伺服器名，sample.asf 是您想要使之轉化為流的 .asf 檔名。
若您有實時內容要通過廣播單播發布，則該 URL 由伺服器名和釋出點別名組成。
例如：mms://windows_media_server/LiveEvents。這裡 windows_media_server 是 Windows Media 伺服器名，
而 LiveEvents 是釋出點名

五、HTTP

由於標準的HTTP伺服器可傳送這種形式的檔案，也不需要其他特殊協議，因而它經常被稱作HTTP流式傳輸。
由於該檔案在播放前觀看的部分是無損下載的，最終播放質量較好，
因而特別適合質量較高、資料量較小、通過Modem釋出的短片段，如片頭、片尾、廣告等。
但使用者在觀看前必須經歷數秒的延遲，傳輸速度較慢時尤為明顯。
對通過調變解調器釋出的短片段，順序流式傳輸顯得很實用，它允許用比調變解調器更高的資料速率建立視訊片段。

儘管有延遲，畢竟可釋出較高質量的視訊片段。順序流式檔案是放在標準HTTP或FTP伺服器上，因而易於管理，基本上與防火牆無關。
順序流式傳輸不適合長片段和有隨機訪問要求的視訊，如講座、演說與演示，它也不支援現場廣播。
因此，嚴格地說來，它本質上是一種點播技術。

六、HLS

 HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議，
可實現流媒體的直播和點播，主要應用在iOS系統，為iOS裝置（如iPhone、iPad）提供音視訊直播和點播方案。
HLS點播，基本上就是常見的分段HTTP點播，不同在於，它的分段非常小。

相對於常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，
HLS直播最大的不同在於，直播客戶端獲取到的，並不是一個完整的資料流。
HLS協議在伺服器端將直播資料流儲存為連續的、很短時長的媒體檔案（MPEG-TS格式），
而客戶端則不斷的下載並播放這些小檔案，因為伺服器端總是會將最新的直播資料生成新的小檔案，
這樣客戶端只要不停的按順序播放從伺服器獲取到的檔案，就實現了直播。

由此可見，基本上可以認為，HLS是以點播的技術方式來實現直播。
由於資料通過HTTP協議傳輸，所以完全不用考慮防火牆或者代理的問題，而且分段檔案的時長很短，
客戶端可以很快的選擇和切換位元速率，以適應不同頻寬條件下的播放。

相關推薦