互動(dòng)業(yè)務(wù)支撐平臺(tái) 流媒體傳輸技術(shù) 考試重點(diǎn)部分

（5）服務(wù)質(zhì)量服務(wù)質(zhì)量QoS(QualityofService)是多媒體網(wǎng)絡(luò)中的一個(gè)重要概念。數(shù)據(jù)傳輸和多媒體信息傳輸具有不同的服務(wù)質(zhì)量需求。多媒體信息傳輸與傳統(tǒng)的最有效的數(shù)據(jù)服務(wù)的區(qū)別在于：如文件傳輸協(xié)議（FTP）和簡(jiǎn)單的郵件傳輸協(xié)議（SMTP）這些傳統(tǒng)的數(shù)據(jù)服務(wù)，其中的時(shí)間變化往往不會(huì)引起人們的注意，人們更關(guān)注收到的信息是否完整、正確，而音頻和視頻數(shù)據(jù)只有在指定的時(shí)間區(qū)間內(nèi)傳輸才有用，延遲的傳送將會(huì)改變音頻和視頻流中包含信息的有效性。1網(wǎng)絡(luò)流媒體面臨的挑戰(zhàn)

當(dāng)前的Internet體系結(jié)構(gòu)只能提供“盡力服務(wù)”（Best-EffortService），不能嚴(yán)格保障視頻播放所需要的傳輸服務(wù)質(zhì)量（QualityofService，簡(jiǎn)稱QoS），因此，如何在“盡力服務(wù)”的網(wǎng)絡(luò)傳輸條件下獲得良好的視頻播放質(zhì)量成為了一個(gè)重大的挑戰(zhàn)。23.4流媒體傳輸協(xié)議流式傳輸定義很廣泛，現(xiàn)在主要指通過(guò)網(wǎng)絡(luò)傳送媒體（如音頻、視頻）的技術(shù)總稱。其特定含義為通過(guò)Internet將影視節(jié)目傳送到PC機(jī)。實(shí)現(xiàn)流式傳輸有兩種方法：順序流式傳輸（ProgressiveStreaming）和實(shí)時(shí)流式傳輸（RealTimeStreaming）。3（1）順序流式傳輸順序流式傳輸是順序下載，在下載文件的同時(shí)用戶可觀看在線媒體，在給定時(shí)刻，用戶只能觀看已下載的那部分，而不能跳到還未下載的部分，通過(guò)標(biāo)準(zhǔn)的HTTP服務(wù)器可發(fā)送這種形式的文件，它經(jīng)常被稱作HTTP流式傳輸。它不支持交互式操作，嚴(yán)格說(shuō)來(lái)，它是一種點(diǎn)播技術(shù)。（2）實(shí)時(shí)流式傳輸實(shí)時(shí)流式傳輸指保證媒體信號(hào)帶寬與網(wǎng)絡(luò)連接配匹，使媒體可被實(shí)時(shí)觀看到。實(shí)時(shí)流與HTTP流式傳輸不同，他需要專用的流媒體服務(wù)器與傳輸協(xié)議。4緩沖存儲(chǔ)是流式傳輸實(shí)現(xiàn)的基本技術(shù)。這是由于在網(wǎng)絡(luò)中以數(shù)據(jù)包傳輸為特征的網(wǎng)絡(luò)將產(chǎn)生延遲抖動(dòng)，使用緩存系統(tǒng)可以有效地彌補(bǔ)延遲和抖動(dòng)的影響，從而使媒體數(shù)據(jù)能連續(xù)輸出，而不會(huì)因?yàn)榫W(wǎng)絡(luò)暫時(shí)擁塞使播放出現(xiàn)停頓。流式傳輸?shù)膶?shí)現(xiàn)需要合適的傳輸協(xié)議。由于TCP需要較多的開(kāi)銷，故不太適合傳輸實(shí)時(shí)數(shù)據(jù)。在流式傳輸?shù)膶?shí)現(xiàn)方案中，一般采用HTTP/TCP來(lái)傳輸控制信息，而用RTP/UDP來(lái)傳輸實(shí)時(shí)聲音數(shù)據(jù)。5流媒體傳輸協(xié)議1.

實(shí)時(shí)傳輸協(xié)議RTP：是用于Internet上針對(duì)多媒體數(shù)據(jù)流的一種傳輸協(xié)議，為交互式音頻、視頻等具有實(shí)時(shí)特征的數(shù)據(jù)提供端到端的傳送服務(wù)。2.

實(shí)時(shí)傳輸控制協(xié)議RTCP：是RTP的控制協(xié)議，RTCP和RTP一起提供流量控制和擁塞控制服務(wù)。實(shí)時(shí)流協(xié)議RTSP：該協(xié)議定義了一對(duì)多應(yīng)用程序如何有效地通過(guò)IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。資源預(yù)留協(xié)議RSVP：是網(wǎng)絡(luò)中預(yù)留所需資源的傳送通道建立和控制的信令協(xié)議，可沿著數(shù)據(jù)流所選定的路由來(lái)預(yù)留資源（如帶寬）。6流媒體傳輸協(xié)議應(yīng)用層表示層會(huì)話層傳送層網(wǎng)絡(luò)層數(shù)據(jù)鏈路層物理層(硬件接口)應(yīng)用層TCPUDPIPARP網(wǎng)絡(luò)接口ISO參考模型TCP/IP模型(硬件)使用IP地址使用物理地址Internet應(yīng)用(SNPM/NFS)RTSPUDP/Multicasting網(wǎng)絡(luò)接口層IPv4/6RSVPTCP實(shí)時(shí)組播應(yīng)用實(shí)時(shí)流應(yīng)用RTPRTCPInternet應(yīng)用(SNPM/NFS)7

8Web瀏覽器Web服務(wù)器流媒體播放器流媒體服務(wù)器流媒體傳輸流程

流媒體的具體傳輸流程如圖所示：

HTTP/TCP

控制信息

RTSP/TCP(UDP)

數(shù)據(jù)流RTP/UDP9從Web服務(wù)器調(diào)用流媒體(1)Audio和video文件存儲(chǔ)在Web服務(wù)器上最原始的方法瀏覽器使用HTTP請(qǐng)求報(bào)文從Web服務(wù)器訪問(wèn)流媒體文件Web服務(wù)器用HTTP響應(yīng)報(bào)文發(fā)送文件content-type首部行描述了audio/video的編碼瀏覽器啟動(dòng)媒體播放器,并將文件傳遞給它媒體播放器解讀該文件

主要缺點(diǎn):

媒體播放器通過(guò)瀏覽器作為中介

與Web服務(wù)器交互10從Web服務(wù)器調(diào)用流媒體(2)改進(jìn):在服務(wù)器和播放器之間建立連接瀏覽器請(qǐng)求和接收元文件（metafile）(用來(lái)描述對(duì)象的文件）而不是接收文件本身);Content-type首部說(shuō)明是特定的audio/video應(yīng)用瀏覽器啟動(dòng)媒體播放器并將元文件傳遞給它播放器與服務(wù)器建立TCP連接并發(fā)送HTTP請(qǐng)求.問(wèn)題討論:媒體播放器使用HTTP通信,沒(méi)有pause,ff,rwnd功能可以考慮使用UDP通信11從流媒體服務(wù)器調(diào)用流媒體該結(jié)構(gòu)可以使用非HTTP協(xié)議進(jìn)行通信在服務(wù)器和流媒體播放器之間進(jìn)行通信可以使用UDP來(lái)替代TCP.12

實(shí)時(shí)傳輸協(xié)議RTP多媒體通信的主要特點(diǎn)之一是實(shí)時(shí)性，TCP協(xié)議提供了高可靠的服務(wù)，但是同時(shí)又引入了高的傳輸時(shí)延并占用了網(wǎng)絡(luò)帶寬，因而不適于傳送實(shí)時(shí)的音視頻數(shù)據(jù)。實(shí)時(shí)傳輸協(xié)議RTP能夠支持基于IP網(wǎng)絡(luò)的多媒體通信業(yè)務(wù)的實(shí)現(xiàn)，為實(shí)時(shí)數(shù)據(jù)的應(yīng)用提供點(diǎn)到點(diǎn)或點(diǎn)到多點(diǎn)通信的傳輸服務(wù)。RTP運(yùn)行于UDP之上，利用了UDP協(xié)議的端口和校驗(yàn)和的功能。RTP協(xié)議本身并不確保實(shí)時(shí)的傳送報(bào)文和提供另外的服務(wù)質(zhì)量保證，而是依賴下層服務(wù)提供。它既不確保報(bào)文的傳送也不防止報(bào)文失序，同時(shí)也不認(rèn)為下層網(wǎng)絡(luò)是可靠地按序傳送報(bào)文的。13RTP協(xié)議用于傳送具有實(shí)時(shí)性要求的數(shù)據(jù)，如音/視頻數(shù)據(jù)。它與另一個(gè)協(xié)議密切相關(guān)，這個(gè)協(xié)議就是RTP的控制協(xié)議——實(shí)時(shí)傳輸控制協(xié)議RTCP（RTPControlProtocol），該協(xié)議用于監(jiān)測(cè)實(shí)時(shí)傳輸?shù)姆?wù)質(zhì)量，并傳遞正在進(jìn)行的會(huì)話中的參與者的信息。RTP主要用于承載多媒體數(shù)據(jù)，并通過(guò)包頭時(shí)間參數(shù)的配置使其具有實(shí)時(shí)的特征。RTCP主要用于周期地傳送RTCP包，監(jiān)視RTP傳輸?shù)姆?wù)質(zhì)量。14RTP會(huì)話一組用戶之間通過(guò)RTP建立的連接稱為RTP會(huì)話，“用戶”為會(huì)話的參與者。對(duì)每一參與者，該RTP會(huì)話由一對(duì)特定的傳送層地址來(lái)標(biāo)識(shí)，包括一個(gè)網(wǎng)絡(luò)地址和一對(duì)端口號(hào)(分別給RTP和RTCP使用)組播：IP地址相同，并使用同一對(duì)端口號(hào)單播：使用各自IP地址，使用同一對(duì)端口號(hào)多個(gè)媒體對(duì)應(yīng)多個(gè)RTP會(huì)話15PT:有效載荷類型,占7位,用于說(shuō)明RTP報(bào)文中有效載荷的類型,如GSM音頻、JPEG圖像等。V:RTP協(xié)議的版本號(hào),占2位,當(dāng)前協(xié)議版本號(hào)為2。P:填充標(biāo)志,占1位,如果P=1,則在該報(bào)文的尾部將填充一個(gè)或多個(gè)額外的八位組,它們不是有效載荷的一部分。X:擴(kuò)展標(biāo)志,占1位,如果X=1,則在RTP報(bào)頭后跟有一個(gè)擴(kuò)展報(bào)頭。CC:CSRC計(jì)數(shù)器,占4位,指示CSRC標(biāo)識(shí)符的個(gè)數(shù)。M:標(biāo)記,占1位,不同的有效載荷有不同的含義,對(duì)于視頻,標(biāo)記一幀的結(jié)束;對(duì)于音頻,標(biāo)記會(huì)話的開(kāi)始。VPXCCMPT序列號(hào)時(shí)戳同步信源(SSRC)標(biāo)識(shí)符特約信源(CSRC)標(biāo)識(shí)符…RTP報(bào)頭格式16同步源(SSRC)標(biāo)識(shí)符:占32位,用于標(biāo)識(shí)同步信源。該標(biāo)識(shí)符是隨機(jī)選擇的,參加同一視頻會(huì)議的兩個(gè)同步信源不能有相同的SSRC。序列號(hào):占16位,用于標(biāo)識(shí)發(fā)送者所發(fā)送的RTP報(bào)文的序列號(hào),每發(fā)送一個(gè)報(bào)文,序列號(hào)增1。接收者通過(guò)序列號(hào)來(lái)檢測(cè)報(bào)文丟失情況,重新排序報(bào)文,恢復(fù)數(shù)據(jù)。時(shí)戳(Timestamp):占32位,時(shí)戳反映了該RTP報(bào)文的第一個(gè)八位組的采樣時(shí)刻。接收者使用時(shí)戳來(lái)計(jì)算延遲和延遲抖動(dòng),并進(jìn)行同步控制。提供源(CSRC)標(biāo)識(shí)符:每個(gè)CSRC標(biāo)識(shí)符占32位,可以有0～15個(gè)。每個(gè)CSRC標(biāo)識(shí)了包含在該RTP報(bào)文有效載荷中的所有特約信源。17實(shí)時(shí)傳輸控制協(xié)議RTCPRTCP協(xié)議作為RTP協(xié)議的控制協(xié)議，通過(guò)周期性的向所有參加者發(fā)送控制報(bào)文來(lái)傳輸有關(guān)服務(wù)質(zhì)量的反饋信息和參加會(huì)話的成員信息。RTCP的控制報(bào)文主要有以下幾種類型：（1）SR（SenderReport）——發(fā)送者報(bào)告（2）RR（Receiverreport）——接收者報(bào)告（3）SDES（Sourcedescriptionitems）——源描述項(xiàng)（4）BYE（Indicatesendofparticipation）——再見(jiàn)（5）APP（Applicationspecificfunctions）——應(yīng)用特定功能18RTCP協(xié)議主要實(shí)現(xiàn)以下4種功能：（1）提供關(guān)于數(shù)據(jù)傳輸質(zhì)量的反饋（2）固定源標(biāo)識(shí)（3）控制流量的縮放（4）可選功能19RTP僅僅實(shí)現(xiàn)了網(wǎng)絡(luò)傳輸層的功能，要真正實(shí)現(xiàn)流媒體的網(wǎng)絡(luò)傳輸，網(wǎng)絡(luò)層和會(huì)話層協(xié)議也必不可少。RTP的實(shí)現(xiàn)服務(wù)器端的RTP實(shí)現(xiàn)框圖InternetIP層UDP/TCP層RTP層RTCP層RTSP/SIP層壓縮打包后的音頻、視頻數(shù)據(jù)數(shù)據(jù)控制20服務(wù)器端在數(shù)據(jù)平面:(3)最后，由IP層負(fù)責(zé)最后的報(bào)文頭部配置，實(shí)現(xiàn)網(wǎng)絡(luò)傳輸。(1)將壓縮打包后的音視頻數(shù)據(jù)按照RTP的報(bào)文格式裝入RTP報(bào)文的數(shù)據(jù)負(fù)載段，同時(shí)配置RTP報(bào)文頭部的時(shí)間截、同步信息、序列號(hào)等重要參數(shù)，此時(shí)的數(shù)據(jù)報(bào)文已經(jīng)具有典型的時(shí)間特征，即被“流化”了。(2)在UDP/TCP層，RTP報(bào)文作為負(fù)載數(shù)據(jù)裝入U(xiǎn)DP/TCP報(bào)文中;21

各網(wǎng)絡(luò)層依次去除報(bào)文頭部，并讀取相關(guān)的控制參數(shù)和時(shí)間參數(shù)，最終獲取可以實(shí)時(shí)播放的音視頻數(shù)據(jù)。在客戶端，實(shí)現(xiàn)方式相反:RTCP和RTSP報(bào)文通過(guò)UDP/TCP層后，同樣由IP層負(fù)責(zé)發(fā)送。RTSP的主要功能是實(shí)現(xiàn)停滯、暫停、快進(jìn)等VCR控制操作，SIP與RTSP功能類似，RTCP僅負(fù)責(zé)控制RTP報(bào)文的傳輸。在控制平面226.3.4資源預(yù)留協(xié)議RSVPRSVP（ResourceReservationProtocol）協(xié)議位于IP層之上，屬于OSI參考模型中的傳輸層，但它不是網(wǎng)絡(luò)傳送協(xié)議，因?yàn)樗粋魉蛻?yīng)用數(shù)據(jù)，它也不是路由選擇協(xié)議，它是一種網(wǎng)絡(luò)控制協(xié)議，用于建立網(wǎng)絡(luò)資源預(yù)留，它允許客戶端向網(wǎng)絡(luò)提出一個(gè)特定的請(qǐng)求，為其數(shù)據(jù)流提供所需的端到端的服務(wù)質(zhì)量（QoS）。23數(shù)據(jù)流在RSVP協(xié)議中將具有一個(gè)特定的目的地和傳輸層協(xié)議的數(shù)據(jù)流定義為“會(huì)話（Session）”，所以通常用數(shù)據(jù)流來(lái)表示它所在的那個(gè)會(huì)話。消息類型RSVP能夠支持多種消息類型，其中最重要的兩個(gè)消息是Resv和Path。24Path消息:由發(fā)送端經(jīng)路由器逐跳hop-by-hop向下游傳送給接收端，其目的是指示數(shù)據(jù)流的正確路徑，包括上一個(gè)送出此Path消息的網(wǎng)絡(luò)節(jié)點(diǎn)的IP地址發(fā)送模板Sender_Template發(fā)送流量說(shuō)明Sender_TspecResv消息：由接收端主機(jī)向上游傳送給發(fā)送端，這些消息嚴(yán)格地按照Path消息的反向路徑上傳到所有的發(fā)送端主機(jī)，其目的是根據(jù)Path消息指示的路徑，逆向在沿途的每個(gè)節(jié)點(diǎn)處預(yù)留資源，同一數(shù)據(jù)流中的不同分組請(qǐng)求預(yù)留的QoS可以不同。流規(guī)范Flowspec過(guò)濾器規(guī)范Filter_spec：預(yù)留分組的情況25RSVP協(xié)議的機(jī)制(工作過(guò)程)發(fā)送端主機(jī)發(fā)出Path消息接收端主機(jī)發(fā)出Resv消息預(yù)留資源發(fā)送端數(shù)據(jù)沿資源預(yù)留的路徑傳向接收端26RSVP網(wǎng)絡(luò)節(jié)點(diǎn)的“業(yè)務(wù)控制”機(jī)制包括：接入控制模塊、策略控制模塊、分組類別模塊、分組調(diào)度模塊和RSVP處理模塊在預(yù)留建立期間：進(jìn)行接入控制模塊和策略控制模塊測(cè)試資源預(yù)留后，分組類別模塊確定每一個(gè)數(shù)據(jù)分組的QoS等級(jí)。RSVP處理模塊策略控制接入控制策略控制分組調(diào)度分組類別資源預(yù)留數(shù)據(jù)27RSVP協(xié)議的特點(diǎn)RSVP是單工的，僅為單向數(shù)據(jù)流請(qǐng)求資源，因此RSVP的發(fā)端和收端在邏輯上被認(rèn)為是截然相反的。RSVP是面向接收者的，即一個(gè)數(shù)據(jù)流的接收端初始化資源預(yù)留RSVP不是一個(gè)路由協(xié)議，但是依賴于路由選擇協(xié)議，路由選擇協(xié)議決定的是分組向何處轉(zhuǎn)發(fā)，而RSVP僅關(guān)心這些分組的QoSRSVP對(duì)不支持RSVP協(xié)議的路由器提供透明操作，無(wú)須采用額外的隧道技術(shù)RSVP既支持IPv4，也支持IPv6。28實(shí)時(shí)流協(xié)議RTSP實(shí)時(shí)流協(xié)議RTSP（RealTimeStreamingProtocol）是一種應(yīng)用層協(xié)議，位于傳輸層之上。RTSP協(xié)議定義了媒體服務(wù)器和多用戶之間如何通過(guò)IP網(wǎng)絡(luò)有效地傳送實(shí)時(shí)多媒體數(shù)據(jù)。RTSP是一個(gè)請(qǐng)求/響應(yīng)的協(xié)議，客戶端發(fā)出請(qǐng)求，媒體服務(wù)器端作出響應(yīng)，同樣，當(dāng)媒體服務(wù)器發(fā)出請(qǐng)求的時(shí)候，客戶端也能作出響應(yīng)。RSTP協(xié)議建立并控制一個(gè)或多個(gè)時(shí)間同步的連續(xù)媒體，如音頻或視頻；但其本身并不傳送連續(xù)媒體流，而是提供一種方法來(lái)選擇傳送通道，如UDP、TCP等RSTP控制的流可以通過(guò)一個(gè)獨(dú)立的協(xié)議來(lái)傳送，該協(xié)議與RTSP的控制通道無(wú)關(guān)。29在RTSP的媒體服務(wù)器和客戶端中，主要存在四種狀態(tài)：Init、Ready、Playing和Recording。狀態(tài)之間的轉(zhuǎn)變可以通過(guò)某種方法傳遞消息來(lái)觸發(fā)：SETUPPLAY,RECORDPAUSETEARDOWNRTSP協(xié)議是基于文本的協(xié)議，其語(yǔ)法和操作來(lái)于HTTP1.1：HTTP傳送的是HTML；而RTSP傳送的是多媒體數(shù)據(jù)HTTP請(qǐng)求由客戶端發(fā)出，服務(wù)器端響應(yīng)；而RTSP中，客戶端和服務(wù)器都可以發(fā)出請(qǐng)求，可見(jiàn)RTSP是雙向的30實(shí)時(shí)流媒體協(xié)議（RealTimeStreamingProtocol）:RTSP

HTTPHTTP所服務(wù)的媒體已經(jīng)定型:HTML,images,applets,etc.HTTP的設(shè)計(jì)沒(méi)有考慮流媒體(i.e.,audio,video,etc.)RTSP:RFC2326客戶端-服務(wù)器應(yīng)用層協(xié)議.可為用戶提供播出控制:rewind,fastforward,pause,resume,repositioning,etc…它所不能做到的:沒(méi)有流媒體傳遞過(guò)程中的audio/video數(shù)據(jù)的封裝不限制流媒體的傳遞方式;既可以用UDP也可以用TCP沒(méi)有定義流媒體播放器如何對(duì)audio/video數(shù)據(jù)進(jìn)行緩存RealNetworks服務(wù)器和播放器使用RTSP互相向?qū)Ψ桨l(fā)送控制信息31RTSP:帶外控制-outofbandcontrolFTP使用了“帶外”的控制通道:文件傳輸通過(guò)一個(gè)通道控制信息(cd,rm,mv,etc.)則通過(guò)分離的TCP連接發(fā)送.

“帶外”和“帶內(nèi)”通道使用不同的端口號(hào).RTSP報(bào)文也使用帶外通道傳送:RTSP控制報(bào)文使用的端口號(hào)與媒體流使用的不同，所以是帶外傳遞.流媒體的分組結(jié)構(gòu)不是由RTPS定義的，因此被認(rèn)為是在“帶內(nèi)”傳輸?shù)?如果RTSP報(bào)文使用與流媒體相同的端口號(hào)，RTSP將與流媒體一起“間隔”傳送.32RTSP啟動(dòng)和控制傳遞首先客戶端獲取多媒體的表示方式描述,這可以由若干媒體流組成.瀏覽器個(gè)根據(jù)表示方式所描述的內(nèi)容類型調(diào)用媒體播放器(輔助的應(yīng)用程序-helperapplication).表示描述中使用URL方法