流媒體傳輸協議總結

1、RTP傳輸協議

 2、RTCP數據傳輸控制協議

 3、 RTSP實時流媒體協議

 4、 RSVP資源預留協議

 -------------------------------------------------------------------------------------------------------------------

    流媒體實現的關鍵技術是流式傳輸，所以，流媒體傳輸協議無疑成爲流媒體技術的重中之重，流媒體協議的設計和制定是爲了實現流媒體服務器和客戶端的通信。在流媒體傳輸中，標準的協議是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應用傳輸數據流時可以得到特殊服務質量。

1、RTP傳輸協議
    RTP(Real-time Transport Protocol)是用於Internet上針對多媒體數據流的一種傳輸協議。RTP被定義爲在一對一或一對多的傳輸狀況下工做，其目的是提供時間信息和實現流同步。RTP一般使用UDP來傳送數據，但RTP也能夠在TCP或ATM等其餘協議之上工做。當RTP工做於一對多的傳輸狀況下時，依靠底層網絡實現組播，利用RTP over UDP模式實現組播的傳輸就是其典型應用。RTP傳輸協議有以下一些特色：
 一、協議靈活性
    RTP協議不具有運輸層協議的完整功能，其自己也不提供任何機制來保證明時地傳輸數據，不支持資源預留，也不保證服務質量。RTP報文甚至不包括長度和報文邊界的描述，而是依靠下層協議提供長度標識和長度限制。另外，RTP協議將部分運輸層協議功能(好比流量控制)上移到應用層完成，簡化了運輸層處理，提升了該層效率。
 二、數據流和控制流分離

    RTP協議的數據報文和控制報文使用相鄰的不一樣端口，這樣大大提升了協議的靈活性和處理的簡單性。
 三、協議的可擴展性和適用性
    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報文。

2、RTCP數據傳輸控制協議
    RTP協議自己包括兩部分：RTP數據傳輸協議和RTCP傳輸控制協議。爲了可靠、高效地傳送實時數據，RTP和RTCP必須配合使用，一般RTCP包的數量佔全部傳輸量的5%。RTP實時傳輸協議主要用於負載多媒體數據，並經過包頭時間參數的配置使其具備實時的特徵。RTP自己並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP(Real-time Contro1 Protocol)傳輸控制協議提供這些服務。RTCP傳輸控制協議主要用於週期的傳送RTCP包，監視RTP傳輸的服務質量。在RTCP包中，含有已發送的數據包的數量、丟失的數據包的數量等統計資料。所以，服務器能夠利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型，實現流量控制和擁塞控制服務。
    RTP的控制協議RTCP經過在會話用戶之間週期性地遞交控制報文來完成監聽服務質量和交換會話用戶信息等功能。根據用戶間的數據傳輸反饋信息，能夠制定流量控制的策略，而會話用戶信息的交互，能夠制定會話控制的策略。RTCP協議將控制包週期發送給全部鏈接者，應用與數據報文相同的分佈機制。底層協議提供數據與控制包的複用，如使用單獨的UDP端口號。

    具體來講RTCP的主要功能包括如下四個部分：
    一、提供數據發佈的質量反饋，這是RTCP最主要的功能。做爲RTP傳輸協議的一部分，與其餘傳輸協議的流和阻塞控制有關。反饋對自適應編碼控制直接起做用。反饋功能由RTCP發送者和接收者報告執行。
    二、發送帶有稱做規範名字(CNAME)的RTP源持久傳輸層標識。如發現衝突，或程序從新啓動，既然SSRC標識可改變，接收者須要CNAME跟蹤參加者。接收者也須要CNAME與相關RTP鏈接中給定的幾個數據流聯繫。
    三、用於控制RTCP數量包的數量。前兩種功能要求全部參加者發送RTCP包，所以，爲了RTP擴展到大規模數量，速率必須受到控制。
    四、傳送最小鏈接控制信息，如參加者辨識。最可能用在「鬆散控制」鏈接，那裏參加者自由進入或離開，沒有成員控制或參數協調，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設計容許應用自動擴展的模式，鏈接數可從幾個到上千個。在通常的音頻會議中，由於同一時刻通常只有兩我的說話，因此數據流和控制流都是內在限制的，控制流不會對傳輸形成影響。而在組播發送模式下，給定鏈接數據率獨立於用戶數，還是常數，但控制流量不是內在限制的。若是每一個參加者以固定速率發送接收報告，控制流量將隨參加者數量線性增加，所以，速率必須按比例降低。

 

3、 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請求可由代理、通道與緩存處理。

4、 RSVP資源預留協議    因爲音頻和視頻數據流比傳統數據對網絡的延時更敏感，要在網絡中傳輸高質量的音頻、視頻信息，除帶寬要求以外，還需其它更多的條件。RSVP(ReSource reserVe Protocol)是Internet上的資源預留協議，使用RSVP預留一部分網絡資源(即帶寬)，能在必定程度上爲流媒體的傳輸提供QoS。資源預留協議使Internet應用傳輸數據流時可以得到特殊服務質量，它同路由協議協同工做，創建與路由協議計算出路由等價的動態訪問列表，RSVP屬OSI七層協議棧中傳輸層。RSVP的流程是單一的，並不區分發送方和接收方，且支持單播和組播，適應於可變成員個數和路由。