用一句簡單的話總結(jié)：RTSP發(fā)起/終結(jié)流媒體、RTP傳輸流媒體數(shù)據(jù) 、RTCP對RTP進行控制，同步。
之所以以前對這幾個有點分不清，是因為CTC標準里沒有對RTCP進行要求，因此在標準RTSP的代碼中沒有看到相關(guān)的部分。而在私有RTSP的代碼中，有關(guān)控制、同步等，是在RTP Header中做擴展定義實現(xiàn)的。
另外，RFC3550可以看作是RFC1889的升級文檔，只看RFC3550即可。
RTP
Real-time Transport Protocol)是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸層協(xié)議。RTP協(xié)議詳細說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標準數(shù)據(jù)包格式。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTCP協(xié)議），視頻會議和一鍵通（Push to Talk）系統(tǒng)（配合H.323或SIP），使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎(chǔ)。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是建立在UDP協(xié)議上的。
RTP 本身并沒有提供按時發(fā)送機制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實現(xiàn)這一過程。 RTP 并不保證傳送或防止無序傳送，也不確定底層網(wǎng)絡(luò)的可靠性。 RTP 實行有序傳送， RTP 中的序列號允許接收方重組發(fā)送方的包序列，同時序列號也能用于決定適當?shù)陌恢茫纾涸谝曨l解碼中，就不需要順序解碼。
RTP 由兩個緊密鏈接部分組成： RTP ― 傳送具有實時屬性的數(shù)據(jù)；RTP 控制協(xié)議（RTCP） ― 監(jiān)控服務(wù)質(zhì)量并傳送正在進行的會話參與者的相關(guān)信息。
RTCP
實時傳輸控制協(xié)議（Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP）是實時傳輸協(xié)議（RTP）的一個姐妹協(xié)議。RTCP為RTP媒體流提供信道外（out-of-band）控制。RTCP本身并不傳輸數(shù)據(jù)，但和RTP一起協(xié)作將多媒體數(shù)據(jù)打包和發(fā)送。RTCP定期在流多媒體會話參加者之間傳輸控制數(shù)據(jù)。RTCP的主要功能是為RTP所提供的服務(wù)質(zhì)量（Quality of Service）提供反饋。
RTCP收集相關(guān)媒體連接的統(tǒng)計信息，例如：傳輸字節(jié)數(shù)，傳輸分組數(shù)，丟失分組數(shù)，jitter，單向和雙向網(wǎng)絡(luò)延遲等等。網(wǎng)絡(luò)應(yīng)用程序可以利用RTCP所提供的信息試圖提高服務(wù)質(zhì)量，比如限制信息流量或改用壓縮比較小的編解碼器。RTCP本身不提供數(shù)據(jù)加密或身份認證。SRTCP可以用于此類用途。
SRTP & SRTCP
安全實時傳輸協(xié)議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協(xié)議（Real-time Transport Protocol或RTP）基礎(chǔ)上所定義的一個協(xié)議，旨在為單播和多播應(yīng)用程序中的實時傳輸協(xié)議的數(shù)據(jù)提供加密、消息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發(fā)的，并最早由IETF于2004年3月作為RFC 3711發(fā)布。
由于實時傳輸協(xié)議和可以被用來控制實時傳輸協(xié)議的會話的實時傳輸控制協(xié)議（RTP Control Protocol或RTCP）有著緊密的聯(lián)系，安全實時傳輸協(xié)議同樣也有一個伴生協(xié)議，它被稱為安全實時傳輸控制協(xié)議（Secure RTCP或SRTCP）；安全實時傳輸控制協(xié)議為實時傳輸控制協(xié)議提供類似的與安全有關(guān)的特性，就像安全實時傳輸協(xié)議為實時傳輸協(xié)議提供的那些一樣。
在使用實時傳輸協(xié)議或?qū)崟r傳輸控制協(xié)議時，使不使用安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議是可選的；但即使使用了安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議，所有它們提供的特性（如加密和認證）也都是可選的，這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協(xié)議時，必須要用到其消息認證特性。
RTSP
RTSP（Real Time Streaming Protocol）是用來控制聲音或影像的多媒體串流協(xié)議，并允許同時多個串流需求控制，傳輸時所用的網(wǎng)絡(luò)通訊協(xié)定并不在其定義的范圍內(nèi)，服務(wù)器端可以自行選擇使用TCP或UDP來傳送串流內(nèi)容，它的語法和運作跟HTTP 1.1類似，但并不特別強調(diào)時間同步，所以比較能容忍網(wǎng)絡(luò)延遲。而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低服務(wù)器端的網(wǎng)絡(luò)用量，更進而支持多方視訊會議（Video Conference）。 因為與HTTP1.1的運作方式相似，所以代理服務(wù)器《Proxy》的快取功能《Cache》也同樣適用于RTSP，并因RTSP具有重新導(dǎo)向功能，可視實際負載情況來轉(zhuǎn)換提供服務(wù)的服務(wù)器，以避免過大的負載集中于同一服務(wù)器而造成延遲。
RTSP 和RTP的關(guān)系
________________________________________________________________________________
RTP：實時傳輸協(xié)議（Real-time Transport Protocol）
RTP/RTCP是實際傳輸數(shù)據(jù)的協(xié)議
RTP傳輸音頻/視頻數(shù)據(jù)，如果是PLAY，Server發(fā)送到Client端，如果是RECORD，可以由Client發(fā)送到Server
整個RTP協(xié)議由兩個密切相關(guān)的部分組成：RTP數(shù)據(jù)協(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是實際傳輸數(shù)據(jù)的協(xié)議
RTCP包括Sender Report和Receiver Report，用來進行音頻/視頻的同步以及其他用途，是一種控制協(xié)議
以下是每個協(xié)議的概要介紹：
一、RTP數(shù)據(jù)協(xié)議
RTP數(shù)據(jù)協(xié)議負責(zé)對流媒體數(shù)據(jù)進行封包并實現(xiàn)媒體流的實時傳輸，每一個RTP數(shù)據(jù)報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個字節(jié)的含義是固定的，而負載則可以是音頻或者視頻數(shù)據(jù)。RTP數(shù)據(jù)報的頭部格式如圖1所示：
其中比較重要的幾個域及其意義如下：
CSRC記數(shù)（CC）：表示CSRC標識的數(shù)目。CSRC標識緊跟在RTP固定頭部之后，用來表示RTP數(shù)據(jù)報的來源，RTP協(xié)議允許在同一個會話中存在多個數(shù)據(jù)源，它們可以通過RTP混合器合并為一個數(shù)據(jù)源。例如，可以產(chǎn)生一個CSRC列表來表示一個電話會議，該會議通過一個RTP混合器將所有講話者的語音數(shù)據(jù)組合為一個RTP數(shù)據(jù)源。
負載類型（PT）：標明RTP負載的格式，包括所采用的編碼算法、采樣頻率、承載通道等。例如，類型2表明該RTP數(shù)據(jù)包中承載的是用ITU G.721算法編碼的語音數(shù)據(jù)，采樣頻率為8000Hz，并且采用單聲道。
序列號：用來為接收方提供探測數(shù)據(jù)丟失的方法，但如何處理丟失的數(shù)據(jù)則是應(yīng)用程序自己的事情，RTP協(xié)議本身并不負責(zé)數(shù)據(jù)的重傳。
時間戳：記錄了負載中第一個字節(jié)的采樣時間，接收方能夠時間戳能夠確定數(shù)據(jù)的到達是否受到了延遲抖動的影響，但具體如何來補償延遲抖動則是應(yīng)用程序自己的事情。
從RTP數(shù)據(jù)報的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數(shù)據(jù)等信息，這些都為實時的流媒體傳輸提供了相應(yīng)的基礎(chǔ)。RTP協(xié)議的目的是提供實時數(shù)據(jù)（如交互式的音頻和視頻）的端到端傳輸服務(wù)，因此在RTP中沒有連接的概念，它可以建立在底層的面向連接或面向非連接的傳輸協(xié)議之上；RTP也不依賴于特別的網(wǎng)絡(luò)地址格式，而僅僅只需要底層傳輸協(xié)議支持組幀（Framing）和分段（Segmentation）就足夠了；另外RTP本身還不提供任何可靠性機制，這些都要由傳輸協(xié)議或者應(yīng)用程序自己來保證。在典型的應(yīng)用場合下，RTP一般是在傳輸協(xié)議之上作為應(yīng)用程序的一部分加以實現(xiàn)的，如圖2所示：
二、RTCP控制協(xié)議
RTCP控制協(xié)議需要與RTP數(shù)據(jù)協(xié)議一起配合使用，當應(yīng)用程序啟動一個RTP會話時將同時占用兩個端口，分別供RTP和RTCP使用。RTP本身并不能為按序傳輸數(shù)據(jù)包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責(zé)完成。通常RTCP會采用與RTP相同的分發(fā)機制，向會話中的所有成員周期性地發(fā)送控制信息，應(yīng)用程序通過接收這些數(shù)據(jù)，從中獲取會話參與者的相關(guān)資料，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息，從而能夠?qū)Ψ?wù)質(zhì)量進行控制或者對網(wǎng)絡(luò)狀況進行診斷。
RTCP協(xié)議的功能是通過不同的RTCP數(shù)據(jù)報來實現(xiàn)的，主要有如下幾種類型：
SR：發(fā)送端報告，所謂發(fā)送端是指發(fā)出RTP數(shù)據(jù)報的應(yīng)用程序或者終端，發(fā)送端同時也可以是接收端。
RR：接收端報告，所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報的應(yīng)用程序或者終端。
SDES：源描述，主要功能是作為會話成員有關(guān)標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。
BYE：通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。
APP：由應(yīng)用程序自己定義，解決了RTCP的擴展性問題，并且為協(xié)議的實現(xiàn)者提供了很大的靈活性。
RTCP數(shù)據(jù)報攜帶有服務(wù)質(zhì)量監(jiān)控的必要信息，能夠?qū)Ψ?wù)質(zhì)量進行動態(tài)的調(diào)整，并能夠?qū)W(wǎng)絡(luò)擁塞進行有效的控制。由于RTCP數(shù)據(jù)報采用的是多播方式，因此會話中的所有成員都可以通過RTCP數(shù)據(jù)報返回的控制信息，來了解其他參與者的當前情況。
在一個典型的應(yīng)用場合下，發(fā)送媒體流的應(yīng)用程序?qū)⒅芷谛缘禺a(chǎn)生發(fā)送端報告SR，該RTCP數(shù)據(jù)報含有不同媒體流間的同步信息，以及已經(jīng)發(fā)送的數(shù)據(jù)報和字節(jié)的計數(shù)，接收端根據(jù)這些信息可以估計出實際的數(shù)據(jù)傳輸速率。另一方面，接收端會向所有已知的發(fā)送端發(fā)送接收端報告RR，該RTCP數(shù)據(jù)報含有已接收數(shù)據(jù)報的最大序列號、丟失的數(shù)據(jù)報數(shù)目、延時抖動和時間戳等重要信息，發(fā)送端應(yīng)用根據(jù)這些信息可以估計出往返時延，并且可以根據(jù)數(shù)據(jù)報丟失概率和時延抖動情況動態(tài)調(diào)整發(fā)送速率，以改善網(wǎng)絡(luò)擁塞狀況，或者根據(jù)網(wǎng)絡(luò)狀況平滑地調(diào)整應(yīng)用程序的服務(wù)質(zhì)量。
三、RTSP實時流協(xié)議
作為一個應(yīng)用層協(xié)議，RTSP提供了一個可供擴展的框架，它的意義在于使得實時流媒體數(shù)據(jù)的受控和點播變得可能?？偟恼f來，RTSP是一個流媒體表示協(xié)議，主要用來控制具有實時特性的數(shù)據(jù)發(fā)送，但它本身并不傳輸數(shù)據(jù)，而是必須依賴于下層傳輸協(xié)議所提供的某些服務(wù)。RTSP可以對流媒體提供諸如播放、暫停、快進等操作，它負責(zé)定義具體的控制消息、操作方法、狀態(tài)碼等，此外還描述了與RTP間的交互操作（RFC2326）。
RTSP在制定時較多地參考了HTTP/1.1協(xié)議，甚至許多描述與HTTP/1.1完全相同。RTSP之所以特意使用與HTTP/1.1類似的語法和操作，在很大程度上是為了兼容現(xiàn)有的Web基礎(chǔ)結(jié)構(gòu)，正因如此，HTTP/1.1的擴展機制大都可以直接引入到RTSP中。
由RTSP控制的媒體流集合可以用表示描述（Presentation Description）來定義，所謂表示是指流媒體服務(wù)器提供給客戶機的一個或者多個媒體流的集合，而表示描述則包含了一個表示中各個媒體流的相關(guān)信息，如數(shù)據(jù)編碼/解碼算法、網(wǎng)絡(luò)地址、媒體流的內(nèi)容等。
雖然RTSP服務(wù)器同樣也使用標識符來區(qū)別每一流連接會話（Session），但RTSP連接并沒有被綁定到傳輸層連接（如TCP等），也就是說在整個RTSP連接期間，RTSP用戶可打開或者關(guān)閉多個對RTSP服務(wù)器的可靠傳輸連接以發(fā)出RTSP 請求。此外，RTSP連接也可以基于面向無連接的傳輸協(xié)議（如UDP等）。
RTSP協(xié)議目前支持以下操作：
檢索媒體：允許用戶通過HTTP或者其它方法向媒體服務(wù)器提交一個表示描述。如表示是組播的，則表示描述就包含用于該媒體流的組播地址和端口號；如果表示是單播的，為了安全在表示描述中應(yīng)該只提供目的地址。
邀請加入：媒體服務(wù)器可以被邀請參加正在進行的會議，或者在表示中回放媒體，或者在表示中錄制全部媒體或其子集，非常適合于分布式教學(xué)。
添加媒體：通知用戶新加入的可利用媒體流，這對現(xiàn)場講座來講顯得尤其有用。與HTTP/1.1類似，RTSP請求也可以交由代理、通道或者緩存來進行處理。
RTMP VS TCP&UDP
(2011-08-30 10:57:53)
轉(zhuǎn)載▼標簽：
雜談分類：
音視頻1， TCP為點對點的協(xié)議，這意味著各個客戶需要分開客戶機/服務(wù)器鏈接，因而無法在網(wǎng)絡(luò)級實現(xiàn)對多個客戶機的數(shù)據(jù)廣播。如果有一個數(shù)據(jù)流必須同時被傳送到多個客戶機，服務(wù)器必須傳送數(shù)據(jù)流的副本到各個客戶機，TCP能夠根據(jù)網(wǎng)絡(luò)帶寬和擁擠程度動態(tài)地調(diào)節(jié)傳送速度并重新發(fā)送丟失的數(shù)據(jù)包，這樣雖然保證了數(shù)據(jù)傳輸?shù)目煽啃?，但是對服?wù)器資源耗費較大，在數(shù)據(jù)流大的場合難以保證數(shù)據(jù)流傳輸?shù)膶崟r性。
2， UDP為不可靠傳輸協(xié)議，在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應(yīng)用程序生成數(shù)據(jù)的速度，計算機的能力和傳輸帶寬的限制；在接收端，uDP把每個消息段放在隊列中，應(yīng)用程序每次從隊列中讀一個消息段。
UDP協(xié)議不需要維護連接狀態(tài)，也不認為每個數(shù)據(jù)包都必須到達接受端，因此網(wǎng)絡(luò)負荷比TCP小，傳輸速度也要比TCP快；但在網(wǎng)絡(luò)越擁擠時，越有更多的數(shù)據(jù)包丟失。
3， RTMP協(xié)議是一個專門為高效傳輸視頻，音頻和數(shù)據(jù)而設(shè)計的協(xié)議。它通過建立一個二進制TCP連接或者連接HTTP隧道實現(xiàn)實時的視頻和聲音傳輸。
共享對象是RTMP數(shù)據(jù)中一種比較重要的數(shù)據(jù)類型，任何客戶端改變數(shù)據(jù)時，共享對象能夠及時更新服務(wù)器端的數(shù)據(jù)，這樣，每個客戶端都能夠及時了解到數(shù)據(jù)的變化。
RTMP比傳統(tǒng)媒介服務(wù)器流出的媒介協(xié)議支持更多。它支持可能包含聲音，影像和腳本數(shù)據(jù)從服務(wù)器到客戶和從客戶到服務(wù)器多條線路的動態(tài)傳輸。RTMP對聲音、影像和腳本數(shù)據(jù)分別處理。
聲音和視頻數(shù)據(jù)被分開地緩沖在服務(wù)器中。如果聲音數(shù)據(jù)在聲音緩沖器中達到某一極限，所有在緩沖器中的數(shù)據(jù)將被丟掉，并且最近到達的數(shù)據(jù)被允許開始收集在緩沖中并被送到各個客戶。視頻數(shù)據(jù)被以相似的方式處理，不同是當新的關(guān)鍵幀到達時，緩沖器中數(shù)據(jù)才被清除。在丟掉舊的幀數(shù)據(jù)時，如果發(fā)現(xiàn)客戶端的數(shù)據(jù)有誤，則將新舊兩個不同的幀進行擬合。
RTMP對數(shù)據(jù)給予不同的優(yōu)先級別。在實時交談中，聲音是最重要的，影像給予低優(yōu)先級，而腳本數(shù)據(jù)被給予的優(yōu)先權(quán)介于聲音和影像中間。
RTMP協(xié)議可以創(chuàng)建多個數(shù)據(jù)流，但是每個數(shù)據(jù)流只能有一個方向。
使用RTMP可以構(gòu)建這樣的一個系統(tǒng)，客戶端可以同時與RTMP服務(wù)器和應(yīng)用服務(wù)器進行交互，使得服務(wù)端的負荷得以分散，雖然在這種改進的系統(tǒng)結(jié)構(gòu)中，RTMP服務(wù)器的性能要求比較高。
RTMP：Real Time Messaging Protocol（實時消息傳送協(xié)議）
RTMP（the Real-time Messaging Protocol）協(xié)議作為客戶端和服務(wù)器端的傳輸協(xié)議，這是一個專門為高效傳輸視頻、音頻和數(shù)據(jù)而設(shè)計的 TCP/IP 協(xié)議，使用 RTMP 協(xié)議傳輸?shù)臄?shù)據(jù)是未經(jīng)加密的，包括用戶名和密碼等認證信息。
類別：Adobe
RTP：Real-Time Transport protocol（實時傳輸協(xié)議）
實時傳輸協(xié)議（RTP）為數(shù)據(jù)提供了具有實時特征的端對端傳送服務(wù)，如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或模擬數(shù)據(jù)。應(yīng)用程序通常在 UDP 上運行 RTP 以便使用其多路結(jié)點和校驗服務(wù)；這兩種協(xié)議都提供了傳輸層協(xié)議的功能。但是 RTP 可以與其它適合的底層網(wǎng)絡(luò)或傳輸協(xié)議一起使用。
類別：IETF
來源：RFC 3550
