RTP

參考文檔 RFC3550/RFC3551

Real-time Transport Protocol)是用于Internet上針對多媒體數據流的一種傳輸層協(xié)議卓舵。RTP協(xié)議詳細說明了在互聯(lián)網上傳遞音頻和視頻的標準數據包格式瘸右。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTCP協(xié)議），視頻會議和一鍵通（Push to Talk）系統(tǒng)（配合H.323或SIP）纯赎，使它成為IP電話產業(yè)的技術基礎。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是建立在UDP協(xié)議上的羹应。

RTP 本身并沒有提供按時發(fā)送機制或其它服務質量（QoS）保證，它依賴于低層服務去實現(xiàn)這一過程散休。 RTP 并不保證傳送或防止無序傳送媒楼，也不確定底層網絡的可靠性。 RTP 實行有序傳送戚丸， RTP 中的序列號允許接收方重組發(fā)送方的包序列划址，同時序列號也能用于決定適當的包位置扔嵌，例如：在視頻解碼中，就不需要順序解碼夺颤。

RTP 由兩個緊密鏈接部分組成： RTP ― 傳送具有實時屬性的數據痢缎；RTP 控制協(xié)議（RTCP） ― 監(jiān)控服務質量并傳送正在進行的會話參與者的相關信息。

RTCP

實時傳輸控制協(xié)議（Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP）是實時傳輸協(xié)議（RTP）的一個姐妹協(xié)議世澜。RTCP為RTP媒體流提供信道外（out-of-band）控制独旷。RTCP本身并不傳輸數據，但和RTP一起協(xié)作將多媒體數據打包和發(fā)送寥裂。RTCP定期在流多媒體會話參加者之間傳輸控制數據嵌洼。RTCP的主要功能是為RTP所提供的服務質量（Quality of Service）提供反饋。

RTCP收集相關媒體連接的統(tǒng)計信息封恰，例如：傳輸字節(jié)數麻养，傳輸分組數，丟失分組數诺舔，jitter鳖昌，單向和雙向網絡延遲等等。網絡應用程序可以利用RTCP所提供的信息試圖提高服務質量低飒，比如限制信息流量或改用壓縮比較小的編解碼器许昨。RTCP本身不提供數據加密或身份認證。SRTCP可以用于此類用途逸嘀。

SRTP & SRTCP

參考文檔 RFC3711

安全實時傳輸協(xié)議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協(xié)議（Real-time Transport Protocol或RTP）基礎上所定義的一個協(xié)議车要，旨在為單播和多播應用程序中的實時傳輸協(xié)議的數據提供加密、消息認證崭倘、完整性保證和重放保護翼岁。它是由David Oran（思科）和Rolf Blom（愛立信）開發(fā)的，并最早由IETF于2004年3月作為RFC3711發(fā)布司光。

由于實時傳輸協(xié)議和可以被用來控制實時傳輸協(xié)議的會話的實時傳輸控制協(xié)議（RTP Control Protocol或RTCP）有著緊密的聯(lián)系琅坡，安全實時傳輸協(xié)議同樣也有一個伴生協(xié)議，它被稱為安全實時傳輸控制協(xié)議（Secure RTCP或SRTCP）残家；安全實時傳輸控制協(xié)議為實時傳輸控制協(xié)議提供類似的與安全有關的特性榆俺，就像安全實時傳輸協(xié)議為實時傳輸協(xié)議提供的那些一樣。

在使用實時傳輸協(xié)議或實時傳輸控制協(xié)議時坞淮，使不使用安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議是可選的茴晋；但即使使用了安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議，所有它們提供的特性（如加密和認證）也都是可選的回窘，這些特性可以被獨立地使用或禁用诺擅。唯一的例外是在使用安全實時傳輸控制協(xié)議時，必須要用到其消息認證特性啡直。

RTSP

參考文檔 RFC2326

是由Real Networks和Netscape共同提出的烁涌。該協(xié)議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據苍碟。RTSP提供了一個可擴展框架，使實時數據撮执，如音頻與視頻的受控微峰、點播成為可能。數據源包括現(xiàn)場數據與存儲在剪輯中的數據抒钱。該協(xié)議目的在于控制多個數據發(fā)送連接蜓肆，為選擇發(fā)送通道，如UDP继效、多播UDP與TCP提供途徑症杏，并為選擇基于RTP上發(fā)送機制提供方法。

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

RTSP 和RTP的關系

RTP不象http和ftp可完整的下載整個影視文件武翎，它是以固定的數據率在網絡上發(fā)送數據烈炭，客戶端也是按照這種速度觀看影視文件，當影視畫面播放過后宝恶，就不可以再重復播放符隙，除非重新向服務器端要求數據。

RTSP與RTP最大的區(qū)別在于：RTSP是一種雙向實時數據傳輸協(xié)議垫毙，它允許客戶端向服務器端發(fā)送請求霹疫，如回放、快進综芥、倒退等操作更米。當然，RTSP可基于RTP來傳送數據毫痕，還可以選擇TCP征峦、UDP、組播UDP等通道來發(fā)送數據消请，具有很好的擴展性栏笆。它時一種類似與http協(xié)議的網絡應用層協(xié)議。目前碰到的一個應用：服務器端實時采集臊泰、編碼并發(fā)送兩路視頻蛉加，客戶端接收并顯示兩路視頻。由于客戶端不必對視頻數據做任何回放缸逃、倒退等操作针饥，可直接采用UDP+RTP+組播實現(xiàn)。

RTP：實時傳輸協(xié)議（Real-time Transport Protocol）

RTP/RTCP是實際傳輸數據的協(xié)議

RTP傳輸音頻/視頻數據需频，如果是PLAY丁眼，Server發(fā)送到Client端，如果是RECORD昭殉，可以由Client發(fā)送到Server

整個RTP協(xié)議由兩個密切相關的部分組成：RTP數據協(xié)議和RTP控制協(xié)議（即RTCP）

RTSP：實時流協(xié)議（Real Time Streaming Protocol苞七，RTSP）

RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義可以知道起對話和控制作用

RTSP的對話過程中SETUP可以確定RTP/RTCP使用的端口挪丢，PLAY/PAUSE/TEARDOWN可以開始或者停止RTP的發(fā)送蹂风，等等

RTCP：

RTP/RTCP是實際傳輸數據的協(xié)議

RTCP包括Sender Report和Receiver Report，用來進行音頻/視頻的同步以及其他用途乾蓬，是一種控制協(xié)議

SDP

會話描述協(xié)議（SDP）為會話通知惠啄、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。

會話目錄用于協(xié)助多媒體會議的通告任内，并為會話參與者傳送相關設置信息撵渡。SDP 即用于將這種信息傳輸到接收端。SDP 完全是一種會話描述格式 ― 它不屬于傳輸協(xié)議 ― 它只使用不同的適當的傳輸協(xié)議族奢，包括會話通知協(xié)議（SAP）姥闭、會話初始協(xié)議（SIP）、實時流協(xié)議（RTSP）越走、MIME 擴展協(xié)議的電子郵件以及超文本傳輸協(xié)議（HTTP）棚品。

SDP 的設計宗旨是通用性，它可以應用于大范圍的網絡環(huán)境和應用程序廊敌，而不僅僅局限于組播會話目錄铜跑，但 SDP 不支持會話內容或媒體編碼的協(xié)商。

在因特網組播骨干網（Mbone）中骡澈，會話目錄工具被用于通告多媒體會議锅纺，并為參與者傳送會議地址和參與者所需的會議特定工具信息，這由 SDP 完成肋殴。SDP 連接好會話后囤锉，傳送足夠的信息給會話參與者坦弟。SDP 信息發(fā)送利用了會話通知協(xié)議（SAP），它周期性地組播通知數據包到已知組播地址和端口處官地。這些信息是 UDP 數據包酿傍，其中包含 SAP 協(xié)議頭和文本有效載荷（text payload）。這里文本有效載荷指的是 SDP 會話描述驱入。此外信息也可以通過電子郵件或 WWW （World Wide Web） 進行發(fā)送赤炒。

SDP 文本信息包括：

會話名稱和意圖；

會話持續(xù)時間亏较；

構成會話的媒體莺褒；

有關接收媒體的信息（地址等）。

協(xié)議結構

SDP 信息是文本信息雪情，采用 UTF-8 編 碼中的 ISO 10646 字符集遵岩。SDP 會話描述如下：（標注 * 符號的表示可選字段）：

v = （協(xié)議版本）

o = （所有者/創(chuàng)建者和會話標識符）

s = （會話名稱）

i = * （會話信息）

u = * （URI 描述）

e = * （Email 地址）

p = * （電話號碼）

c = * （連接信息 ― 如果包含在所有媒體中，則不需要該字段）

b = * （帶寬信息）

一個或更多時間描述（如下所示）：

z = * （時間區(qū)域調整）

k = * （加密密鑰）

a = * （0 個或多個會話屬性行）

0個或多個媒體描述（如下所示）

時間描述

t = （會話活動時間）

r = * （0或多次重復次數）

媒體描述

m = （媒體名稱和傳輸地址）

i = * （媒體標題）

c = * （連接信息 — 如果包含在會話層則該字段可選）

b = * （帶寬信息）

k = * （加密密鑰）

a = * （0 個或多個會話屬性行）

RTMP/RTMPS

RTMP(Real Time Messaging Protocol)實時消息傳送協(xié)議是Adobe Systems公司為Flash播放器和服務器之間音頻旺罢、視頻和數據傳輸 開發(fā)的開放協(xié)議旷余。

它有三種變種：

1)工作在TCP之上的明文協(xié)議，使用端口1935扁达；

2)RTMPT封裝在HTTP請求之中正卧，可穿越防火墻；

3)RTMPS類似RTMPT跪解，但使用的是HTTPS連接炉旷；

RTMP協(xié)議(Real Time Messaging Protocol)是被Flash用于對象,視頻,音頻的傳輸.這個協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上.

RTMP協(xié)議就像一個用來裝數據包的容器,這些數據既可以是AMF格式的數據,也可以是FLV中的視/音頻數據.一個單一的連接可以通過不同的通道傳輸多路網絡流.這些通道中的包都是按照固定大小的包傳輸的.

mms

MMS (Microsoft Media Server Protocol)，中文“微軟媒體服務器協(xié)議”叉讥，用來訪問并流式接收 Windows Media 服務器中 .asf 文件的一種協(xié)議窘行。MMS 協(xié)議用于訪問 Windows Media 發(fā)布點上的單播內容。MMS 是連接 Windows Media 單播服務的默認方法图仓。若觀眾在 Windows Media Player 中鍵入一個 URL 以連接內容罐盔，而不是通過超級鏈接訪問內容，則他們必須使用MMS 協(xié)議引用該流救崔。MMS的預設埠（端口）是1755

當使用 MMS 協(xié)議連接到發(fā)布點時惶看，使用協(xié)議翻轉以獲得最佳連接×酰“協(xié)議翻轉”始于試圖通過 MMSU 連接客戶端纬黎。 MMSU 是 MMS 協(xié)議結合 UDP 數據傳送。如果 MMSU 連接不成功劫窒，則服務器試圖使用 MMST本今。MMST 是 MMS 協(xié)議結合 TCP 數據傳送。

如果連接到編入索引的 .asf 文件，想要快進冠息、后退挪凑、暫停、開始和停止流铐达，則必須使用 MMS岖赋。不能用 UNC 路徑快進或后退。若您從獨立的 Windows Media Player 連接到發(fā)布點瓮孙，則必須指定單播內容的 URL。若內容在主發(fā)布點點播發(fā)布选脊，則 URL 由服務器名和 .asf 文件名組成杭抠。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服務器名恳啥，sample.asf 是您想要使之轉化為流的 .asf 文件名偏灿。

若您有實時內容要通過廣播單播發(fā)布，則該 URL 由服務器名和發(fā)布點別名組成钝的。例如：mms://windows_media_server/LiveEvents翁垂。這里 windows_media_server 是 Windows Media 服務器名，而 LiveEvents 是發(fā)布點名

HLS

HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現(xiàn)的基于HTTP的流媒體傳輸協(xié)議硝桩，可實現(xiàn)流媒體的直播和點播沿猜，主要應用在iOS系統(tǒng)，為iOS設備（如iPhone碗脊、iPad）提供音視頻直播和點播方案啼肩。HLS點播，基本上就是常見的分段HTTP點播衙伶，不同在于祈坠，它的分段非常小。

相對于常見的流媒體直播協(xié)議矢劲，例如RTMP協(xié)議赦拘、RTSP協(xié)議、MMS協(xié)議等芬沉，HLS直播最大的不同在于躺同，直播客戶端獲取到的，并不是一個完整的數據流花嘶。HLS協(xié)議在服務器端將直播數據流存儲為連續(xù)的笋籽、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載并播放這些小文件椭员，因為服務器端總是會將最新的直播數據生成新的小文件车海，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現(xiàn)了直播。由此可見侍芝，基本上可以認為研铆，HLS是以點播的技術方式來實現(xiàn)直播。由于數據通過HTTP協(xié)議傳輸州叠，所以完全不用考慮防火墻或者代理的問題棵红，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率咧栗，以適應不同帶寬條件下的播放逆甜。不過HLS的這種技術特點，決定了它的延遲一般總是會高于普通的流媒體直播協(xié)議致板。

根據以上的了解要實現(xiàn)HTTP Live Streaming直播交煞，需要研究并實現(xiàn)以下技術關鍵點

采集視頻源和音頻源的數據

對原始數據進行H264編碼和AAC編碼

視頻和音頻數據封裝為MPEG-TS包

HLS分段生成策略及m3u8索引文件

HTTP傳輸協(xié)議