流媒體實現的關鍵技術是流式傳輸，因此，流媒體傳輸協議無疑成為流媒體技術的重中之重，流媒體協議的設計和制定是為了實現流媒體服務器和客戶端的通訊。在流媒體傳輸中，標準的協議是RTP（Real-time Transport Protocol,實時傳輸協議）、RTCP（Real-time Transport Control Protocal,實時傳輸控制協議）、RTSP（Real Time Streaming Protocal,實時流媒體協議）和RSVP（ReSource reserVe Protocol,資源預定協議）。
實時傳輸協議RTP是針對在互聯網上進行媒體數據流傳輸而提出的，它的目的是提供時間信息和實現流同步。RTP是最典型、最廣泛的服務於流媒體的傳輸層協議。RTP可以在一對一或一對多的傳輸情況下工作。RTP可以在UDP、TCP或ATM等其他協議之上工作。
實時傳輸控制協議RTCP和RTP一起提供流量控制和擁塞控制服務。
實時流協議RTSP是由Realnetworks和Netscape共同提出的，該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。
RSVP是互聯網上的資源預定協議，使用RSVP預留一部分網絡資源（即帶寬），能在一定程度上為流媒體的傳輸提供QoS，它使Internet應用傳輸數據流時能夠獲得特殊服務質量。
一、RTP傳輸協議
RTP(Real-time Transport Protocol)是用於Internet上針對多媒體數據流的一種傳輸協議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP通常使用UDP來傳送數據，但RTP也可以在TCP或ATM等其他協議之上工作。當RTP工作於一對多的傳輸情況下時，依靠底層網絡實現組播，利用RTP over UDP模式實現組播的傳輸就是其典型應用。RTP傳輸協議有如下一些特點：
1、協議靈活性
RTP協議不具備運輸層協議的完整功能，其本身也不提供任何機制來保證實時地傳輸數據，不支持資源預留，也不保證服務質量。RTP報文甚至不包括長度和報文邊界的描述，而是依靠下層協議提供長度標識和長度限制。另外，RTP協議將部分運輸層協議功能(比如流量控制)上移到應用層完成，簡化了運輸層處理，提高了該層效率。
2、數據流和控制流分離
RTP協議的數據報文和控制報文使用相鄰的不同端口，這樣大大提高了協議的靈活性和處理的簡單性。
3、協議的可擴展性和適用性
RTP協議通常為一個具體的應用來提供服務，通過一個具體的應用進程實現，而不作為OSI體系結構中單獨的一層來實現，RTP只提供協議框架，開發者可以根據應用的具體要求對協議進行充分的擴展。
雖然RTP協議是為多媒體數據流傳輸而設計的，但是其用途不僅限於此，RTP協議還可以用於連續數據的存儲，交互式分佈仿真和一些控制、測量的應用中。RTP報文格式中包括固定的RTP報文頭，可選用的作用標識(CSRC)和負載數據。如果RTP所依賴的底層協議對RTP報文的格式有所要求，RTP報文的格式必須進行修改或重新定義。通常，單一的底層數據報文僅包含單一的RTP報文。下圖1為一個典型的負載MPEG-4視頻流的RTP報文格式。
RTP報文頭部分各參數的意義如下：
(1)負載類型（PT）：對音頻或視頻等數據類型予以說明，並說明數據的編碼格式。
(2)填充（P）：如果設置了填充位，表示在該RTP包的末尾含有並非有效負載數據31的填充位。
(3)擴展位（Extension-X）：由使用的RTP框架定義。
(4)序列號（Sequence Number）：為了安全，服務器從一個隨機初始化值開始，每發送一個RTP數據包序列號增加1。客戶端可以根據序列號重新排列數據包的順序，並對丟失、損壞和重複的數據包進行檢測。
(5)標誌位（Marker-M）：標誌位由具體的應用框架定義。例如，RTP的MPEG4負載格式中，標誌位設為1標誌就是VOP的最後一個（或僅有一個）RTP包。
(6)時間戳（Timestamp）：RTP時間戳為同步不同的媒體流提供採樣時間，用於重新建立原始音頻或視頻的時序。另外，它還可以幫助接收方確定數據到達時間的一致性或變化（有時被稱為抖動）。
(7)同步源標識（SSRC）：幫助接收方利用發送方生成的唯一的數值來區分多個同時的數據流。SSRC必須是一個嚴格的隨機數。
(8)作用標識(CSRC):網絡中使用混合器時，混合器會在RTP報文頭部之後插入新的同步源標識，區分多個同時的數據流。在所有PTP報文中，開始12個字節的格式完全按照上圖定義的格式，而CSRC標識列表僅出現在混合器插入時。
標準的RTP數據報文頭部參數對RTP支持的所有應用類的共同需要是完整的。然而，為了維持ALF設計原則，報文頭部還可以通過改變、增加參數實現優化，或適應特殊應用的需要。由於標誌位和負載類型段攜帶特定設置信息，所以很多應用都需要它們，否則要容納它們，就要增加另外32位字，因此，標誌位和負載類型允許分配在固定頭中。包含這些段的八進制可通過設置重新定義以適應不同要求，例如採用更多或更少標誌位。如果有標誌位，既然設置無關監控器能觀察報文丟失模式和標誌位間關係，可定位八進制中最重要的位。
如果RTP協議需要負載其它特殊格式(如視頻編碼)的音視頻數據，所要求的信息應該攜帶在報文的數據負載部分。所需信息也可以出現在報文頭部，但必須總是在載荷部分開始處，或在數據模式的保留值中指出。如果特殊應用類需要獨立負載格式的附加功能，應用運行設置應該在現存固定報文頭部的SSRC參數之後，定義附加固定段。這些設置能使客戶端迅速而直接訪問附加段，同時，與監控器和記錄器無關設置通過解釋開始的12個八進制處理RTP報文。
二、RTCP數據傳輸控制協議
RTP協議本身包括兩部分：RTP數據傳輸協議和RTCP傳輸控制協議。為了可靠、高效地傳送實時數據，RTP和RTCP必須配合使用，通常RTCP包的數量佔所有傳輸量的5%。RTP實時傳輸協議主要用於負載多媒體數據，並通過包頭時間參數的配置使其具有實時的特徵。RTP本身並不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP(Real-time Contro1 Protocol)傳輸控制協議提供這些服務。RTCP傳輸控制協議主要用於週期的傳送RTCP包，監視RTP傳輸的服務質量。在RTCP包中，含有已發送的數據包的數量、丟失的數據包的數量等統計資料。因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型，實現流量控制和擁塞控制服務。
RTP的控制協議RTCP通過在會話用戶之間週期性地遞交控制報文來完成監聽服務質量和交換會話用戶信息等功能。根據用戶間的數據傳輸反饋信息，可以制定流量控制的策略，而會話用戶信息的交互，可以制定會話控制的策略。RTCP協議將控制包週期發送給所有連接者，應用與數據報文相同的分佈機制。底層協議提供數據與控制包的複用，如使用單獨的UDP端口號。
具體來說RTCP的主要功能包括以下四個部分：
1、提供數據發佈的質量反饋，這是RTCP最主要的功能。作為RTP傳輸協議的一部分，與其他傳輸協議的流和阻塞控制有關。反饋對自適應編碼控制直接起作用。反饋功能由RTCP發送者和接收者報告執行。
2、發送帶有稱作規範名字(CNAME)的RTP源持久傳輸層標識。如發現衝突，或程序重新啟動，既然SSRC標識可改變，接收者需要CNAME跟蹤參加者。接收者也需要CNAME與相關RTP連接中給定的幾個數據流聯繫。
3、用於控制RTCP數量包的數量。前兩種功能要求所有參加者發送RTCP包，因此，為了RTP擴展到大規模數量，速率必須受到控制。
4、傳送最小連接控制信息，如參加者辨識。最可能用在“鬆散控制”連接，那裡參加者自由進入或離開，沒有成員控制或參數協調，RTCP充當通往所有參加者的方便通道，但不必支持應用的所有控制通信要求。
RTCP報文格式與RTP報文類似，包括固定的報文頭部分和可變長結構元素，結構元素的意義由RTCP報文的類型決定，因為通常RTCP包非常小，一般把多個RTCP包合併為一個RTCP包，然後利用一個底層協議所定義的報文格式進行發送。
RTCP報文格式如圖2所示，RTCP報文頭部參數首先要區別攜帶不同控制信息的RTCP報文的類型，RICP報文類型主要有以下幾種：
SR：發送報告，當前活動發送者發送、接收統計；
RR：接收報告，非活動發送者接收統計；
SDES：源描述項，包括CNAME；
BYB：表示結束；
APP：應用特定函數。
在一個典型的應用場合下，發送媒體流的應用程序將週期性地產生髮送端報告SR，該RTCP數據報含有不同媒體流間的同步信息，以及己經發送的數據報和字節的計數，接收端根據這些信息可以估計出實際的數據傳輸速率。另一方面，接收端會向所有已知的發送端發送接收端報告RR，該RTCP數據報含有已接收數據報的最大序列號、丟失的數據報數目、延時抖動和時間戳等重要信息，發送端應用根據這些信息可以估計出往返時延，並且可以根據數據報丟失概率和時延抖動情況動態調整發送速率，以改善網絡擁塞狀況，或者根據網絡狀況平滑地調整應用程序的服務質量。
其中最主要的RTCP報文是SR和RR。通常SR報文佔總RTCP數據包的25%，RR報文佔75%。類似於RTP數據包，每個RTCP報文以固定的包頭部分開始，緊接著的是可變長結構元素，但是以32位長度為結束邊界。在RTCP報文中，不需要插入任何分隔符就可以將多個RTCP報文連接起來形成一個RTCP組合報文。由於需要底層協議提供整體長度來決定組合報文的結尾，所以在組合報文中沒有單個RTCP報文的顯式計數。
RTCP控制報文的發送週期是變化的，與報文長度L、用戶數N和控制報文帶寬B相關：週期P=L*N/B。原因是RTP設計允許應用自動擴展的模式，連接數可從幾個到上千個。在一般的音頻會議中，因為同一時刻一般只有兩個人說話，所以數據流和控制流都是內在限制的，控制流不會對傳輸造成影響。而在組播發送模式下，給定連接數據率獨立於用戶數，仍是常數，但控制流量不是內在限制的。如果每個參加者以固定速率發送接收報告，控制流量將隨參加者數量線性增長，因此，速率必須按比例下降。
三、 RTSP實時流媒體協議
RTSP（Real-time Steaming Protocol）是由RealNetworks和Netcape共同提出的一個應用層協議。它可以在媒體服務器和客戶端之間建立和控制連續的音/視頻媒體流，協同更低層協議RTP、RSVP等一起來提供基於Internet的整套流式服務。RTSP提供了一種可擴展框架，使得可控的、點播的實時數據的傳送成為可能。它提供用於音頻和視頻流的“VCR模式”遠程控制功能，例如暫停、快進、快退和定位。支持單播和組播。RTSP還提供選擇發送通道的方法(如UDP、組播UDP和TCP)和基於RTP的發送機制。RTSP像是媒體服務器和客戶端之間的“網絡遠程控制”，它提供多種服務，如從媒體服務器上檢索媒體、邀請媒體服務器進入會議、添加媒體到現成節目。RTSP在語法和操作上類似於HTTP，因此許多HTTP的擴展機制都可以移植於RTSP上。在RTSP中，每個節目和媒體流由RTSP URL確定，全部節目和媒體特性都在節目描述文件中給予了描述，包括編碼、語言、RTSP URL、目的地址、端口號以及其它參數。但是，不同於HTTP的無狀態和非對稱，RTSP是有狀態的、對稱的協議。RTSP的服務器保持會話狀態以連接RTSP流的請求，並且服務器和客戶端都可以發出請求。
協議支持的操作如下：
媒體服務器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示就包含用於連續媒體的組播地址和端口。如演示僅通過單播發送給用戶，用戶為了安全應提供目的地址。
媒體服務器邀請進入會議：媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分佈式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。
將媒體加到現成講座中：如服務器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。
四、 RSVP資源預留協議
由於音頻和視頻數據流比傳統數據對網絡的延時更敏感，要在網絡中傳輸高質量的音頻、視頻信息，除帶寬要求之外，還需其它更多的條件。RSVP(ReSource reserVe Protocol)是Internet上的資源預留協議，使用RSVP預留一部分網絡資源(即帶寬)，能在一定程度上為流媒體的傳輸提供QoS。資源預留協議使Internet應用傳輸數據流時能夠獲得特殊服務質量，它同路由協議協同工作，建立與路由協議計算出路由等價的動態訪問列表，RSVP屬OSI七層協議棧中傳輸層。RSVP的流程是單一的，並不區分發送方和接收方，且支持單播和組播，適應於可變成員個數和路由。
閱讀更多 cpp軟件架構獅 的文章
