原文在這里
RTP
參考文檔 RFC3550/RFC3551
??Real-time Transport Protocol)是用于Internet上針對(duì)多媒體數(shù)據(jù)流的一種傳輸層協(xié)議造垛。RTP協(xié)議詳細(xì)說(shuō)明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式签则。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTCP協(xié)議），視頻會(huì)議和一鍵通（Push to Talk）系統(tǒng)（配合H.323或SIP）外傅，使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎(chǔ)。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是建立在UDP協(xié)議上的。
??RTP 本身并沒(méi)有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證脚作，它依賴于低層服務(wù)去實(shí)現(xiàn)這一過(guò)程。 RTP 并不保證傳送或防止無(wú)序傳送犁河，也不確定底層網(wǎng)絡(luò)的可靠性鳖枕。 RTP 實(shí)行有序傳送魄梯， RTP 中的序列號(hào)允許接收方重組發(fā)送方的包序列桨螺，同時(shí)序列號(hào)也能用于決定適當(dāng)?shù)陌恢茫纾涸谝曨l解碼中酿秸，就不需要順序解碼灭翔。
??RTP 由兩個(gè)緊密鏈接部分組成： RTP ― 傳送具有實(shí)時(shí)屬性的數(shù)據(jù)；RTP 控制協(xié)議（RTCP） ― 監(jiān)控服務(wù)質(zhì)量并傳送正在進(jìn)行的會(huì)話參與者的相關(guān)信息。
RTCP
實(shí)時(shí)傳輸控制協(xié)議（Real-time Transport Control Protocol或RTP Control Protocol或簡(jiǎn)寫(xiě)RTCP）是實(shí)時(shí)傳輸協(xié)議（RTP）的一個(gè)姐妹協(xié)議肝箱。RTCP為RTP媒體流提供信道外（out-of-band）控制哄褒。RTCP本身并不傳輸數(shù)據(jù)，但和RTP一起協(xié)作將多媒體數(shù)據(jù)打包和發(fā)送煌张。RTCP定期在流多媒體會(huì)話參加者之間傳輸控制數(shù)據(jù)呐赡。RTCP的主要功能是為RTP所提供的服務(wù)質(zhì)量（Quality of Service）提供反饋。 RTCP收集相關(guān)媒體連接的統(tǒng)計(jì)信息骏融，例如：傳輸字節(jié)數(shù)链嘀，傳輸分組數(shù)，丟失分組數(shù)档玻，jitter怀泊，單向和雙向網(wǎng)絡(luò)延遲等等。網(wǎng)絡(luò)應(yīng)用程序可以利用RTCP所提供的信息試圖提高服務(wù)質(zhì)量误趴，比如限制信息流量或改用壓縮比較小的編解碼器霹琼。RTCP本身不提供數(shù)據(jù)加密或身份認(rèn)證。SRTCP可以用于此類用途凉当。
SRTP & SRTCP
參考文檔 RFC3711
??安全實(shí)時(shí)傳輸協(xié)議（Secure Real-time Transport Protocol或SRTP）是在實(shí)時(shí)傳輸協(xié)議（Real-time Transport Protocol或RTP）基礎(chǔ)上所定義的一個(gè)協(xié)議枣申，旨在為單播和多播應(yīng)用程序中的實(shí)時(shí)傳輸協(xié)議的數(shù)據(jù)提供加密、消息認(rèn)證看杭、完整性保證和重放保護(hù)糯而。它是由David Oran（思科）和Rolf Blom（愛(ài)立信）開(kāi)發(fā)的，并最早由IETF于2004年3月作為RFC3711發(fā)布泊窘。
??由于實(shí)時(shí)傳輸協(xié)議和可以被用來(lái)控制實(shí)時(shí)傳輸協(xié)議的會(huì)話的實(shí)時(shí)傳輸控制協(xié)議（RTP Control Protocol或RTCP）有著緊密的聯(lián)系熄驼，安全實(shí)時(shí)傳輸協(xié)議同樣也有一個(gè)伴生協(xié)議，它被稱為安全實(shí)時(shí)傳輸控制協(xié)議（Secure RTCP或SRTCP）烘豹；安全實(shí)時(shí)傳輸控制協(xié)議為實(shí)時(shí)傳輸控制協(xié)議提供類似的與安全有關(guān)的特性瓜贾，就像安全實(shí)時(shí)傳輸協(xié)議為實(shí)時(shí)傳輸協(xié)議提供的那些一樣。
??在使用實(shí)時(shí)傳輸協(xié)議或?qū)崟r(shí)傳輸控制協(xié)議時(shí)携悯，使不使用安全實(shí)時(shí)傳輸協(xié)議或安全實(shí)時(shí)傳輸控制協(xié)議是可選的祭芦；但即使使用了安全實(shí)時(shí)傳輸協(xié)議或安全實(shí)時(shí)傳輸控制協(xié)議，所有它們提供的特性（如加密和認(rèn)證）也都是可選的憔鬼，這些特性可以被獨(dú)立地使用或禁用龟劲。唯一的例外是在使用安全實(shí)時(shí)傳輸控制協(xié)議時(shí)，必須要用到其消息認(rèn)證特性轴或。
RTSP
參考文檔 RFC2326
??是由Real Networks和Netscape共同提出的昌跌。該協(xié)議定義了一對(duì)多應(yīng)用程序如何有效地通過(guò)IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP提供了一個(gè)可擴(kuò)展框架照雁，使實(shí)時(shí)數(shù)據(jù)蚕愤，如音頻與視頻的受控、點(diǎn)播成為可能。數(shù)據(jù)源包括現(xiàn)場(chǎng)數(shù)據(jù)與存儲(chǔ)在剪輯中的數(shù)據(jù)萍诱。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接悬嗓，為選擇發(fā)送通道，如UDP裕坊、多播UDP與TCP提供途徑包竹，并為選擇基于RTP上發(fā)送機(jī)制提供方法。
??RTSP（Real Time Streaming Protocol）是用來(lái)控制聲音或影像的多媒體串流協(xié)議籍凝，并允許同時(shí)多個(gè)串流需求控制映企，傳輸時(shí)所用的網(wǎng)絡(luò)通訊協(xié)定并不在其定義的范圍內(nèi)，服務(wù)器端可以自行選擇使用TCP或UDP來(lái)傳送串流內(nèi)容静浴，它的語(yǔ)法和運(yùn)作跟HTTP 1.1類似堰氓，但并不特別強(qiáng)調(diào)時(shí)間同步，所以比較能容忍網(wǎng)絡(luò)延遲苹享。而前面提到的允許同時(shí)多個(gè)串流需求控制（Multicast）双絮，除了可以降低服務(wù)器端的網(wǎng)絡(luò)用量，更進(jìn)而支持多方視訊會(huì)議（Video Conference）得问。 因?yàn)榕cHTTP1.1的運(yùn)作方式相似囤攀，所以代理服務(wù)器《Proxy》的快取功能《Cache》也同樣適用于RTSP，并因RTSP具有重新導(dǎo)向功能宫纬，可視實(shí)際負(fù)載情況來(lái)轉(zhuǎn)換提供服務(wù)的服務(wù)器焚挠，以避免過(guò)大的負(fù)載集中于同一服務(wù)器而造成延遲。
RTSP 和RTP的關(guān)系
RTP不象http和ftp可完整的下載整個(gè)影視文件漓骚，它是以固定的數(shù)據(jù)率在網(wǎng)絡(luò)上發(fā)送數(shù)據(jù)蝌衔，客戶端也是按照這種速度觀看影視文件，當(dāng)影視畫(huà)面播放過(guò)后蝌蹂，就不可以再重復(fù)播放噩斟，除非重新向服務(wù)器端要求數(shù)據(jù)。
??RTSP與RTP最大的區(qū)別在于：RTSP是一種雙向?qū)崟r(shí)數(shù)據(jù)傳輸協(xié)議孤个，它允許客戶端向服務(wù)器端發(fā)送請(qǐng)求剃允，如回放、快進(jìn)齐鲤、倒退等操作斥废。當(dāng)然，RTSP可基于RTP來(lái)傳送數(shù)據(jù)给郊，還可以選擇TCP牡肉、UDP、組播UDP等通道來(lái)發(fā)送數(shù)據(jù)丑罪，具有很好的擴(kuò)展性荚板。它時(shí)一種類似與http協(xié)議的網(wǎng)絡(luò)應(yīng)用層協(xié)議凤壁。目前碰到的一個(gè)應(yīng)用：服務(wù)器端實(shí)時(shí)采集吩屹、編碼并發(fā)送兩路視頻跪另，客戶端接收并顯示兩路視頻。由于客戶端不必對(duì)視頻數(shù)據(jù)做任何回放煤搜、倒退等操作免绿，可直接采用UDP+RTP+組播實(shí)現(xiàn)。
RTP：實(shí)時(shí)傳輸協(xié)議（Real-time Transport Protocol）
RTP/RTCP是實(shí)際傳輸數(shù)據(jù)的協(xié)議 RTP傳輸音頻/視頻數(shù)據(jù)擦盾，如果是PLAY嘲驾，Server發(fā)送到Client端，如果是RECORD迹卢，可以由Client發(fā)送到Server 整個(gè)RTP協(xié)議由兩個(gè)密切相關(guān)的部分組成：RTP數(shù)據(jù)協(xié)議和RTP控制協(xié)議（即RTCP）
RTSP：實(shí)時(shí)流協(xié)議（Real Time Streaming Protocol辽故，RTSP）
RTSP的請(qǐng)求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義可以知道起對(duì)話和控制作用 RTSP的對(duì)話過(guò)程中SETUP可以確定RTP/RTCP使用的端口腐碱，PLAY/PAUSE/TEARDOWN可以開(kāi)始或者停止RTP的發(fā)送誊垢，等等
RTCP： RTP/RTCP是實(shí)際傳輸數(shù)據(jù)的協(xié)議 RTCP包括Sender Report和Receiver Report，用來(lái)進(jìn)行音頻/視頻的同步以及其他用途症见，是一種控制協(xié)議
SDP
會(huì)話描述協(xié)議（SDP）為會(huì)話通知喂走、會(huì)話邀請(qǐng)和其它形式的多媒體會(huì)話初始化等目的提供了多媒體會(huì)話描述。
??會(huì)話目錄用于協(xié)助多媒體會(huì)議的通告谋作，并為會(huì)話參與者傳送相關(guān)設(shè)置信息芋肠。SDP 即用于將這種信息傳輸?shù)浇邮斩恕DP 完全是一種會(huì)話描述格式 ― 它不屬于傳輸協(xié)議 ― 它只使用不同的適當(dāng)?shù)膫鬏攨f(xié)議遵蚜，包括會(huì)話通知協(xié)議（SAP）帖池、會(huì)話初始協(xié)議（SIP）、實(shí)時(shí)流協(xié)議（RTSP）吭净、MIME 擴(kuò)展協(xié)議的電子郵件以及超文本傳輸協(xié)議（HTTP）碘裕。
??SDP 的設(shè)計(jì)宗旨是通用性，它可以應(yīng)用于大范圍的網(wǎng)絡(luò)環(huán)境和應(yīng)用程序攒钳，而不僅僅局限于組播會(huì)話目錄帮孔，但 SDP 不支持會(huì)話內(nèi)容或媒體編碼的協(xié)商。
??在因特網(wǎng)組播骨干網(wǎng)（Mbone）中不撑，會(huì)話目錄工具被用于通告多媒體會(huì)議文兢，并為參與者傳送會(huì)議地址和參與者所需的會(huì)議特定工具信息，這由 SDP 完成焕檬。SDP 連接好會(huì)話后姆坚，傳送足夠的信息給會(huì)話參與者。SDP 信息發(fā)送利用了會(huì)話通知協(xié)議（SAP）实愚，它周期性地組播通知數(shù)據(jù)包到已知組播地址和端口處兼呵。這些信息是 UDP 數(shù)據(jù)包兔辅，其中包含 SAP 協(xié)議頭和文本有效載荷（text payload）。這里文本有效載荷指的是 SDP 會(huì)話描述击喂。此外信息也可以通過(guò)電子郵件或 WWW （World Wide Web） 進(jìn)行發(fā)送维苔。
SDP 文本信息包括：
- 會(huì)話名稱和意圖；
- 會(huì)話持續(xù)時(shí)間懂昂；
- 構(gòu)成會(huì)話的媒體介时；
- 有關(guān)接收媒體的信息（地址等）。
- 協(xié)議結(jié)構(gòu)
SDP 信息是文本信息凌彬，采用 UTF-8 編 碼中的 ISO 10646 字符集沸柔。SDP 會(huì)話描述如下：（標(biāo)注 * 符號(hào)的表示可選字段）：
v = （協(xié)議版本）
o = （所有者/創(chuàng)建者和會(huì)話標(biāo)識(shí)符）
s = （會(huì)話名稱）
i = * （會(huì)話信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （電話號(hào)碼）
c = * （連接信息 ― 如果包含在所有媒體中，則不需要該字段）
b = * （帶寬信息）
一個(gè)或更多時(shí)間描述（如下所示）：
z = * （時(shí)間區(qū)域調(diào)整）
k = * （加密密鑰）
a = * （0 個(gè)或多個(gè)會(huì)話屬性行）
0個(gè)或多個(gè)媒體描述（如下所示）：
時(shí)間描述：
t = （會(huì)話活動(dòng)時(shí)間）
r = * （0或多次重復(fù)次數(shù)）
媒體描述：
m = （媒體名稱和傳輸?shù)刂罚?i = * （媒體標(biāo)題）
c = * （連接信息 — 如果包含在會(huì)話層則該字段可選）
b = * （帶寬信息）k = * （加密密鑰）
a = * （0 個(gè)或多個(gè)會(huì)話屬性行）
RTMP/RTMPS
RTMP(Real Time Messaging Protocol)實(shí)時(shí)消息傳送協(xié)議是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻铲敛、視頻和數(shù)據(jù)傳輸 開(kāi)發(fā)的開(kāi)放協(xié)議褐澎。它有三種變種：
- 工作在TCP之上的明文協(xié)議，使用端口1935伐蒋；
- RTMPT封裝在HTTP請(qǐng)求之中工三，可穿越防火墻；
- RTMPS類似RTMPT咽弦，但使用的是HTTPS連接徒蟆；
RTMP協(xié)議(Real Time Messaging Protocol)是被Flash用于對(duì)象,視頻,音頻的傳輸.這個(gè)協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上. RTMP協(xié)議就像一個(gè)用來(lái)裝數(shù)據(jù)包的容器,這些數(shù)據(jù)既可以是AMF格式的數(shù)據(jù),也可以是FLV中的視/音頻數(shù)據(jù).一個(gè)單一的連接可以通過(guò)不同的通道傳輸多路網(wǎng)絡(luò)流.這些通道中的包都是按照固定大小的包傳輸?shù)?
MMS
MMS (Microsoft Media Server Protocol)，中文“微軟媒體服務(wù)器協(xié)議”型型，用來(lái)訪問(wèn)并流式接收 Windows Media 服務(wù)器中 .asf 文件的一種協(xié)議段审。MMS 協(xié)議用于訪問(wèn) Windows Media 發(fā)布點(diǎn)上的單播內(nèi)容。MMS 是連接 Windows Media 單播服務(wù)的默認(rèn)方法闹蒜。若觀眾在 Windows Media Player 中鍵入一個(gè) URL 以連接內(nèi)容寺枉，而不是通過(guò)超級(jí)鏈接訪問(wèn)內(nèi)容，則他們必須使用MMS 協(xié)議引用該流绷落。MMS的預(yù)設(shè)埠（端口）是1755姥闪。
??當(dāng)使用 MMS 協(xié)議連接到發(fā)布點(diǎn)時(shí)，使用協(xié)議翻轉(zhuǎn)以獲得最佳連接砌烁】鹪“協(xié)議翻轉(zhuǎn)”始于試圖通過(guò) MMSU 連接客戶端。 MMSU 是 MMS 協(xié)議結(jié)合 UDP 數(shù)據(jù)傳送函喉。如果 MMSU 連接不成功避归，則服務(wù)器試圖使用 MMST。MMST 是 MMS 協(xié)議結(jié)合 TCP 數(shù)據(jù)傳送管呵。
??如果連接到編入索引的 .asf 文件梳毙，想要快進(jìn)、后退捐下、暫停账锹、開(kāi)始和停止流萌业，則必須使用 MMS。不能用 UNC 路徑快進(jìn)或后退奸柬。若您從獨(dú)立的 Windows Media Player 連接到發(fā)布點(diǎn)生年，則必須指定單播內(nèi)容的 URL。若內(nèi)容在主發(fā)布點(diǎn)點(diǎn)播發(fā)布鸟缕，則 URL 由服務(wù)器名和 .asf 文件名組成晶框。例如：mms://windows_media_server/sample.asf排抬。其中 windows_media_server 是 Windows Media 服務(wù)器名懂从，sample.asf 是您想要使之轉(zhuǎn)化為流的 .asf 文件名。若您有實(shí)時(shí)內(nèi)容要通過(guò)廣播單播發(fā)布蹲蒲，則該 URL 由服務(wù)器名和發(fā)布點(diǎn)別名組成番甩。例如：mms://windows_media_server/LiveEvents。這里 windows_media_server 是 Windows Media 服務(wù)器名届搁，而 LiveEvents 是發(fā)布點(diǎn)名缘薛。
HLS
HTTP Live Streaming（HLS）是蘋(píng)果公司(Apple Inc.)實(shí)現(xiàn)的基于HTTP的流媒體傳輸協(xié)議，可實(shí)現(xiàn)流媒體的直播和點(diǎn)播卡睦，主要應(yīng)用在iOS系統(tǒng)宴胧，為iOS設(shè)備（如iPhone、iPad）提供音視頻直播和點(diǎn)播方案表锻。HLS點(diǎn)播恕齐，基本上就是常見(jiàn)的分段HTTP點(diǎn)播，不同在于瞬逊，它的分段非常小显歧。
??相對(duì)于常見(jiàn)的流媒體直播協(xié)議，例如RTMP協(xié)議确镊、RTSP協(xié)議士骤、MMS協(xié)議等，HLS直播最大的不同在于蕾域，直播客戶端獲取到的拷肌，并不是一個(gè)完整的數(shù)據(jù)流。HLS協(xié)議在服務(wù)器端將直播數(shù)據(jù)流存儲(chǔ)為連續(xù)的旨巷、很短時(shí)長(zhǎng)的媒體文件（MPEG-TS格式）巨缘，而客戶端則不斷的下載并播放這些小文件，因?yàn)榉?wù)器端總是會(huì)將最新的直播數(shù)據(jù)生成新的小文件契沫，這樣客戶端只要不停的按順序播放從服務(wù)器獲取到的文件带猴，就實(shí)現(xiàn)了直播。由此可見(jiàn)懈万，基本上可以認(rèn)為拴清，HLS是以點(diǎn)播的技術(shù)方式來(lái)實(shí)現(xiàn)直播靶病。由于數(shù)據(jù)通過(guò)HTTP協(xié)議傳輸，所以完全不用考慮防火墻或者代理的問(wèn)題口予，而且分段文件的時(shí)長(zhǎng)很短娄周，客戶端可以很快的選擇和切換碼率，以適應(yīng)不同帶寬條件下的播放沪停。不過(guò)HLS的這種技術(shù)特點(diǎn)煤辨，決定了它的延遲一般總是會(huì)高于普通的流媒體直播協(xié)議∧菊牛
??根據(jù)以上的了解要實(shí)現(xiàn)HTTP Live Streaming直播众辨，需要研究并實(shí)現(xiàn)以下技術(shù)關(guān)鍵點(diǎn)：
- 采集視頻源和音頻源的數(shù)據(jù)
- 對(duì)原始數(shù)據(jù)進(jìn)行H264編碼和AAC編碼
- 視頻和音頻數(shù)據(jù)封裝為MPEG-TS包
- HLS分段生成策略及m3u8索引文件
- HTTP傳輸協(xié)議
