Streaming 通訊協定 RTP RTCP RTSP RTMP HLS 介紹

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）；安全即時傳輸控制協定為即時傳輸控制協定提供類似的與安全有關的特性，就像安全即時傳輸協定為即時傳輸協定提供的那些一樣。

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

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具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。

RTSP 和RTP的關係

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

RTSP與RTP最大的區別在於：RTSP是一種雙向即時資料傳輸協定，它允許用戶端向伺服器端發送請求，如重播、快進、倒退等操作。當然，RTSP可基於RTP來傳送資料，還可以選擇TCP、UDP、組播UDP等通道來發送資料，具有很好的擴展性。它時一種類似與http協定的網路應用層協定。

目前碰到的一個應用：伺服器端即時採集、編碼並發送兩路視頻，用戶端接收並顯示兩路視頻。由於用戶端不必對視頻資料做任何重播、倒退等操作，可直接採用UDP+RTP+組播實現。

RTP：即時傳輸協議（Real-time Transport Protocol）

RTP/RTCP是實際傳輸資料的協定 RTP傳輸音訊/視頻資料，如果是PLAY，Server發送到Client端，如果是RECORD，可以由Client發送到Server 整個RTP協定由兩個密切相關的部分組成：RTP資料協定和RTP控制協定（即RTCP） RTSP：即時資料流通訊協定（Real Time Streaming Protocol，RTSP） RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義可以知道起對話和控制作用 RTSP的對話過程中SETUP可以確定RTP/RTCP使用的埠，PLAY/PAUSE/TEARDOWN可以開始或者停止RTP的發送，等等

RTCP： RTP/RTCP是實際傳輸資料的協定 RTCP包括Sender Report和Receiver Report，用來進行音訊/視頻的同步以及其他用途，是一種控制協議

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 文本資訊包括：

1.會話名稱和意圖；
2.會話持續時間；
3.構成會話的媒體；
4.有關接收媒體的資訊（位址等）。
5.協定結構
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/RTMPS

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中的視/音訊資料.一個單一的連接可以通過不同的通道傳輸多路網路流.這些通道中的包都是按照固定大小的包傳輸的

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 是發佈點名

HLS

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

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

由於資料通過HTTP協定傳輸，所以完全不用考慮防火牆或者代理的問題，而且分段檔的時長很短，用戶端可以很快的選擇和切換碼率，以適應不同頻寬條件下的播放。不過HLS的這種技術特點，決定了它的延遲一般總是會高於普通的流媒體直播協定。　

根據以上的瞭解要實現HTTP Live Streaming直播，需要研究並實現以下技術關鍵點

1.採集視頻源和音訊源的資料
2.對原始資料進行H264編碼和AAC編碼
3.視頻和音訊資料封裝為MPEG-TS包
4.HLS分段生成策略及m3u8索引檔
5.HTTP傳輸協議