1、實(shí)時(shí)傳輸協(xié)議詳解實(shí)時(shí)傳輸協(xié)議RTP1.RTP協(xié)議：RTP（ Real-time Transport Protocol）協(xié)議最初是在70年代為了嘗試傳輸聲音文件，把包分成幾部分用來傳輸語音，時(shí)間標(biāo)志和隊(duì)列號(hào)。經(jīng)過一系列發(fā)展，RTP第一版本在 1991年8月由美國的一個(gè)實(shí)驗(yàn)室發(fā)布了。到本世紀(jì)1996年形成了標(biāo)準(zhǔn)的的版本。很多著名的公司如Netscape ,就宣稱“Netscape LiveMedia”是基于RTP協(xié)議的。. Microsoft 也宣稱他們的“NetMeeting”也是支持RTP協(xié)議.RTP被定義為傳輸音頻、視頻、模擬數(shù)據(jù)等實(shí)時(shí)數(shù)據(jù)的傳輸協(xié)議。最初設(shè)計(jì)是為了數(shù)據(jù)傳輸?shù)亩嗖ィ撬灿?/p>

2、于單播的。與傳統(tǒng)的注重的高可靠的數(shù)據(jù)傳輸?shù)倪\(yùn)輸層協(xié)議相比，它更加側(cè)重的數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性。此協(xié)議提供的服務(wù)包括時(shí)間載量標(biāo)識(shí)、數(shù)據(jù)序列、時(shí)戳、傳輸控制等。RTP與輔助控制協(xié)議RTCP一起得到數(shù)據(jù)傳輸?shù)囊恍┫嚓P(guān)的控制信息。2RTP協(xié)議是如何工作的：在前面說明過，威脅多媒體數(shù)據(jù)傳輸?shù)囊粋€(gè)尖銳的問題就是不可預(yù)料數(shù)據(jù)到達(dá)時(shí)間。但是流媒體的傳輸是需要數(shù)據(jù)的適時(shí)的到達(dá)用以播放和回放。RTP協(xié)議就是提供了時(shí)間標(biāo)簽,序列號(hào)以及其它的結(jié)構(gòu)用于控制適時(shí)數(shù)據(jù)的流放。在流的概念中”時(shí)間標(biāo)簽”是最重要的信息。發(fā)送端依照即時(shí)的采樣在數(shù)據(jù)包里隱蔽的設(shè)置了時(shí)間標(biāo)簽。在接受端收到數(shù)據(jù)包后,就依照時(shí)間標(biāo)簽按照正確的速率恢復(fù)成原始的適

3、時(shí)的數(shù)據(jù)。不同的媒體格式調(diào)時(shí)屬性是不一樣的。但是RTP本身并不負(fù)責(zé)同步，RTP只是傳輸層協(xié)議，為了簡(jiǎn)化了運(yùn)輸層處理，提高該層的效率。將部分運(yùn)輸層協(xié)議功能（比如流量控制）上移到應(yīng)用層完成。同步就是屬于應(yīng)用層協(xié)議完成的。它沒有運(yùn)輸層協(xié)議的完整功能，不提供任何機(jī)制來保證實(shí)時(shí)地傳輸數(shù)據(jù)，不支持資源預(yù)留，也不保證服務(wù)質(zhì)量。RTP報(bào)文甚至不包括長(zhǎng)度和報(bào)文邊界的描述。同時(shí)RTP協(xié)議的數(shù)據(jù)報(bào)文和控制報(bào)文的使用相鄰的不同端口，這樣大大提高了協(xié)議的靈活性和處理的簡(jiǎn)單性。RTP協(xié)議和UDP二者共同完成運(yùn)輸層協(xié)議功能。UDP協(xié)議只是傳輸數(shù)據(jù)包，是不管數(shù)據(jù)包傳輸?shù)臅r(shí)間順序。RTP的協(xié)議數(shù)據(jù)單元是用UDP分組來承載的。在

4、承載RTP數(shù)據(jù)包的時(shí)候，有時(shí)候一幀數(shù)據(jù)被分割成幾個(gè)包具有相同的時(shí)間標(biāo)簽，則可以知道時(shí)間標(biāo)簽并不是必須的。而UDP的多路復(fù)用讓RTP協(xié)議利用支持顯式的多點(diǎn)投遞，可以滿足多媒體會(huì)話的需求。RTP協(xié)議雖然是傳輸層協(xié)議但是它沒有作為OSI體系結(jié)構(gòu)中單獨(dú)的一層來實(shí)現(xiàn)。RTP協(xié)議通常根據(jù)一個(gè)具體的應(yīng)用來提供服務(wù)， RTP只提供協(xié)議框架，開發(fā)者可以根據(jù)應(yīng)用的具體要求對(duì)協(xié)議進(jìn)行充分的擴(kuò)展。目前，RTP的設(shè)計(jì)和研究主要是用來滿足多用戶的多媒體會(huì)議的需要，另外它也適用于連續(xù)數(shù)據(jù)的存儲(chǔ)，交互式分布仿真和一些控制、測(cè)量的應(yīng)用中。基于RTP的實(shí)驗(yàn)和商業(yè)產(chǎn)品也層出不窮。 實(shí)時(shí)傳輸控制協(xié)議RTCP協(xié)議1. RTCP協(xié)議：R

5、TCP（Real-time Transpor、Control Protocol）是設(shè)計(jì)和RTP一起使用的進(jìn)行流量控制和擁塞控制的服務(wù)控制協(xié)議。2. RTCP協(xié)議如何工作：當(dāng)應(yīng)用程序開始一個(gè)RTP會(huì)話時(shí)將使用兩個(gè)端口：一個(gè)給RTP，一個(gè)給RTCP。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。在RTP的會(huì)話之間周期的發(fā)放一些RTCP包以用來傳監(jiān)聽服務(wù)質(zhì)量和交換會(huì)話用戶信息等功能。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配

6、合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。根據(jù)用戶間的數(shù)據(jù)傳輸反饋信息，可以制定流量控制的策略，而會(huì)話用戶信息的交互，可以制定會(huì)話控制的策略。 RTCP協(xié)議處理機(jī)根據(jù)需要定義了五種類型的報(bào)文RR: receiver reportSR: sender reportSDES: source description items. BYE: indicates end of participation. APP: application specific functions它們完成接收、分析、產(chǎn)生和發(fā)送控制報(bào)文的功能。實(shí)時(shí)流協(xié)議RTSP協(xié)議1. RTSP協(xié)

7、議：RTSP（Real Time Streaming Protocol）協(xié)議定義了如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)，是一種客戶端到服務(wù)器端的多媒體描述協(xié)議。RTSP是一個(gè)非常類似于HTTP的應(yīng)用層協(xié)議。每個(gè)發(fā)布和媒體文件也被定義為RTSP UPL。而媒體文件的發(fā)布信息被書寫進(jìn)一個(gè)被稱為媒體發(fā)布文件里，這個(gè)文件在后面會(huì)說明。在這個(gè)文件說明的包括編碼器，語言，RTSP ULS，地址，端口號(hào)以幾其它參數(shù)。這個(gè)發(fā)布文件可以在客戶端通過EMAIL形式或者HTTP形式獲得。RTSP是由RealNetworks和Netscape以及哥倫比亞大學(xué)共同提出的。它是從RealNetworks的"Re

8、alAudio" 和 Netscape的 "LiveMedia"的實(shí)踐和經(jīng)驗(yàn)發(fā)展來來的。第一份RTSP協(xié)議是由IETF 在1996年8月9日正式提交后作為INTERNET的標(biāo)準(zhǔn)，在此后此協(xié)議經(jīng)過了很多明顯的變化。它的應(yīng)用現(xiàn)在是廣泛的，APPLE、 IBMNetscape, Apple, IBM, Silicon Graphics, VXtreme, Sun 還有其它公司都宣稱它們的在線播放器支持RTSP協(xié)議，不過微軟一直都堅(jiān)持不支持此協(xié)議，不知道這種局面還會(huì)持續(xù)多久。2. RTSP協(xié)議的特點(diǎn)：RTSP是應(yīng)用層協(xié)議,與RTP、RSVP一起設(shè)計(jì)來完全流式服務(wù)。RTSP

9、有很大的靈活性，可被用在多種操作系統(tǒng)上,它允許客戶端和不同廠商的服務(wù)平臺(tái)交互。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用RTP完成數(shù)據(jù)傳輸。它將流式媒體數(shù)據(jù)可控制的通過網(wǎng)絡(luò)傳輸?shù)娇蛻舳恕TSP可以保持用戶計(jì)算機(jī)與傳輸流業(yè)務(wù)服務(wù)器之間的固定連接，用于觀看者與單播（Unicast）服務(wù)器通信并且還允許雙向通信，觀看者可以同流媒體服務(wù)器通信.提供類似“VCR”形式的例如暫停、快進(jìn)、倒轉(zhuǎn)、跳轉(zhuǎn)等操作。操作的資源對(duì)象可以是直播流也可以是存儲(chǔ)片段。RTSP是設(shè)還提供了選擇傳輸通道，如使用UDP還是多點(diǎn)UDP或是TCP。資源預(yù)留協(xié)議RSVP 1. RSVP協(xié)議：RSVP (Resorce reS

10、erVation Protocol) 資源預(yù)留協(xié)議并不是一個(gè)路由協(xié)議，而是一種IP網(wǎng)絡(luò)中的信令協(xié)議，它與路由協(xié)議相結(jié)合來實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)傳輸服務(wù)質(zhì)量（QoS）的控制。RSVP是為支持因特網(wǎng)綜合業(yè)務(wù)而提出的。這是解決IP通信中QoS（服務(wù)質(zhì)量）問題的一種技術(shù)，用來保證點(diǎn)端到端的傳輸帶寬。2. RSVP協(xié)議是如何工作：RSVP使用控制數(shù)據(jù)報(bào)，這些數(shù)據(jù)報(bào)在向特定地址傳輸時(shí)包括了需要由路由器檢查（有些時(shí)候需要更新）的信息,如果路由器需要決定是不是要檢查數(shù)據(jù)報(bào)的內(nèi)容的時(shí)候?qū)ι蠈訑?shù)據(jù)內(nèi)容進(jìn)行語法分析。這種分析的代價(jià)可不小。現(xiàn)在的情況是，網(wǎng)絡(luò)終端利用它向網(wǎng)絡(luò)申請(qǐng)資源，在這種表明“申請(qǐng)” 的信號(hào)中，包含著如下的信息

11、：業(yè)務(wù)的種類？ 使用者類型？ 什么時(shí)間？ 需要多大帶寬？ 其他參考信息？網(wǎng)絡(luò)在接收到上類信息后，會(huì)根據(jù)實(shí)際情況為此次連接分配一個(gè)優(yōu)先代碼，用戶利用優(yōu)先代碼進(jìn)行信息傳遞時(shí)，網(wǎng)絡(luò)不需重新對(duì)業(yè)務(wù)進(jìn)行分析與判別，從另外一個(gè)角度來說，利用RSVP 能從一定程度上減少網(wǎng)絡(luò)對(duì)信息處理的時(shí)延，提高網(wǎng)絡(luò)節(jié)點(diǎn)的工作效率，改善信息傳輸?shù)姆?wù)質(zhì)量（QoS）。實(shí)時(shí)應(yīng)用用RSVP是為了在傳輸路徑中保持必要的資源以保證請(qǐng)求能確保到達(dá)。RSVP是IP路由器為提供更好的服務(wù)質(zhì)量向前邁進(jìn)的具有深刻意義的一步。傳統(tǒng)上IP路由器只負(fù)責(zé)分組轉(zhuǎn)發(fā)，通過路由協(xié)議知道鄰近路由器的地址。而 RSVP則類似于電路交換系統(tǒng)的信令協(xié)議一樣，為一個(gè)數(shù)據(jù)流通知其所經(jīng)過的每個(gè)節(jié)點(diǎn)（IP路由器），與端點(diǎn)協(xié)商為此數(shù)據(jù)流提供質(zhì)量保證。RSVP協(xié)議一出現(xiàn)，立刻獲得廣泛的認(rèn)同，基本上被任為較好地解決了資源預(yù)留的問題。在前面我們討論了一些實(shí)時(shí)媒體控制的相近的四個(gè)協(xié)議。在這里我再概括性的說明一下：RTP是實(shí)時(shí)數(shù)據(jù)傳輸協(xié)議。它提供時(shí)間標(biāo)志，序列號(hào)以及其它能夠保證在實(shí)時(shí)數(shù)據(jù)傳輸時(shí)處理時(shí)間的方法。它是依靠RVSP保證服務(wù)