《計算機網(wǎng)絡(luò)教程》電子教案第八章網(wǎng)絡(luò)應(yīng)用

多媒體應(yīng)用2主要內(nèi)容多媒體應(yīng)用（8.3）多媒體網(wǎng)絡(luò)概述多媒體運輸協(xié)議：RTP流媒體技術(shù)3網(wǎng)絡(luò)多媒體應(yīng)用網(wǎng)絡(luò)多媒體應(yīng)用可分為播放應(yīng)用和會議應(yīng)用播放（Playback）應(yīng)用：現(xiàn)場和點播流媒體（包括音頻和視頻）應(yīng)用會議應(yīng)用：實時交互，延時要求較高4網(wǎng)絡(luò)多媒體特征可靠性要求比較寬松實時性對數(shù)據(jù)從發(fā)送者到達接收者之間的延遲極其敏感改善方法：高效傳輸、高效編碼、壓縮等時性要求傳輸能很連貫地進行，即要求在連續(xù)的數(shù)據(jù)幀之間的延遲保持穩(wěn)定在一定范圍內(nèi)改善方法：數(shù)據(jù)緩沖5網(wǎng)絡(luò)多媒體特征因此實時多媒體流又稱為連續(xù)媒體（ContinousMedia），其中兩個使用最為廣泛的媒體流是音頻和視頻多媒體信息。目前大多數(shù)實時多媒體應(yīng)用不僅支持點到點的傳輸，而且通過采用IP組播技術(shù)支持點到多點、多點到多點的多媒體信息傳輸?？紤]到以上特性一般不使用TCP等傳統(tǒng)的可靠運輸協(xié)議傳輸多媒體信息TCP是面向連接的協(xié)議，不支持組播。TCP提供了相應(yīng)的機制保證可靠地數(shù)據(jù)傳輸，但實時多媒體會話中重傳基本上無實際意義。TCP提供慢啟動、擁塞避免等擁塞控制機制，這些機制在多媒體會話中可能并不是非常適合，而且會帶來額外的延遲和延遲的抖動。TCP沒有多媒體會話所要求的時間戳等機制。6多媒體運輸協(xié)議：RTP實時運輸協(xié)議RTP（Real-timeTransportProtocol）是一種用于實時多媒體的標(biāo)準(zhǔn)傳輸協(xié)議RTP用于交換多媒體信息，定義在RFC1889還包括配套的實時運輸控制協(xié)議RTCP，用于定期發(fā)送對應(yīng)該多媒體流的控制信息，通過該協(xié)議可以把接收者監(jiān)測到的多媒體流的接收情況通知給發(fā)送者，同時也可以傳遞一些簡單的會話控制信息。TCP不適合RTP，RTP一般運行于UDP之上（支持組播）RTP數(shù)據(jù)流和相應(yīng)的RTCP控制流利用相鄰的運輸層端口來傳輸，即RTP數(shù)據(jù)流的端口為偶數(shù)端口（x），而RTCP則使用相鄰的那個為奇數(shù)的端口（x+1）7RTP特征RTP不需要預(yù)先建立連接，同時也并沒有更多的可靠性控制。為了能夠多媒體會話能夠正常運行，網(wǎng)絡(luò)必須能夠提供足夠的帶寬來保證基本的多媒體通信質(zhì)量，至于怎么樣保證則和RTP無關(guān)。RTCP提供的服務(wù)質(zhì)量監(jiān)測功能可以讓發(fā)送者在發(fā)現(xiàn)網(wǎng)絡(luò)質(zhì)量下降或者提升的時候改變多媒體流的編碼方式，從而避免網(wǎng)絡(luò)的擁塞或者有效地利用網(wǎng)絡(luò)的帶寬。8RTP特征RTP是為實時多媒體應(yīng)用而設(shè)計的，因而提供了一種靈活的機制，使得新的多媒體應(yīng)用可以不需要重復(fù)那些通用的一些功能的設(shè)計，而是利用RTP協(xié)議。RTP協(xié)議只是定義了一個實時多媒體應(yīng)用的一個框架（Framework），一個新類型的多媒體應(yīng)用常常要求定義相應(yīng)的腳本（Profile）和相應(yīng)的格式，腳本保證這種類型的應(yīng)用對RTP頭部字段有一個統(tǒng)一的理解，而格式給出了實時多媒體信息是如何通過RTP消息傳遞。9RTP封裝實時多媒體信息被封裝進RTP報文中，每個RTP報文然后封裝進一個UDP報段中因為RTP為多媒體應(yīng)用提供服務(wù)，它常常被看作為運輸層的一個子層。但是從應(yīng)用開發(fā)者的角度來看，RTP不是運輸層協(xié)議，而是一種應(yīng)用層協(xié)議。應(yīng)用層RTPUDPIP子網(wǎng)socket10RTP封裝RTP協(xié)議的設(shè)計體現(xiàn)了應(yīng)用層成幀ALF（ApplicationLevelFraming）的思想。該思想認為新的多媒體應(yīng)用不可能使用傳統(tǒng)的TCP協(xié)議，而且不大可能設(shè)計出一種符合各種類型的新應(yīng)用的通用協(xié)議，即具體的應(yīng)用有具體的需求。所以RTP只是定義了一個基本的框架結(jié)構(gòu)，而大多數(shù)的協(xié)議細節(jié)在開發(fā)具體的多媒體應(yīng)用時再定義，這一般是在相應(yīng)的腳本和格式文檔中定義。11RTP幾個概念RTP會話多個用戶通過RTP交換多媒體信息，則它們屬于同一個RTP會話（RTPSession）。RTP會話中的每個多媒體源都被分配了一個32個比特的同步源SSRC（SynchronizationSource）標(biāo)識，該標(biāo)識在RTP會話中是惟一的，來自于這個多媒體源的RTP分組都屬于同一個RTP流，都包含了該SSRC標(biāo)識，并且采用相同的采樣時鐘和順序號空間，從而允許接收者知道分組接收的情況和時序。12RTP幾個概念通過RTP會話，可以支持點到點通信，也可以支持會議方式通信。同一個多媒體源的音頻和視頻可以捆綁在一個RTP流上，使用一個RTP會話；也可以分開在不同的RTP流上，屬于不同的RTP會話。13RTP幾個概念RTP混合器（Mixer）RTP支持在某個網(wǎng)關(guān)處把多個源混合在一起來形成一個新的單個流，這個時候這個流的分組頭部包含了所有被混合在一起的流的ID，該網(wǎng)關(guān)即RTP混合器?；旌掀鹘邮諄碜杂谝粋€或者多個源的RTP流，然后按照某種方式（可能改變其中的數(shù)據(jù)格式）將這些流合成在一起，然后轉(zhuǎn)發(fā)新的多媒體流，這個新的多媒體流實際上是一個單一的多媒體源，具有惟一的SSRC標(biāo)識，同時在RTP頭部中給出了那些原來的流的SSRC標(biāo)識列表，從而可以知道是哪些用戶合成的結(jié)果。14RTP幾個概念RTP轉(zhuǎn)發(fā)器（Translator）該設(shè)備轉(zhuǎn)發(fā)RTP流，在轉(zhuǎn)發(fā)的同時可能還會改變數(shù)據(jù)的格式，但是和混合器不同，它并不改變SSRC標(biāo)識。轉(zhuǎn)發(fā)器在某些環(huán)境下比較有用，如假設(shè)用戶所在的網(wǎng)絡(luò)不支持組播，這個時候就可以通過轉(zhuǎn)發(fā)器把收到的RTP流分發(fā)給會議中的各個成員，此外在需要進行編碼轉(zhuǎn)換或者繞過防火墻時都可以采用。15RTP消息格式M順序號相關(guān)源標(biāo)識CSRC···時間戳同步源標(biāo)識SSRC32比特VPXCC負載類型擴展頭部（可選）RTP負載16RTP消息格式一個RTP消息包括了一個12個字節(jié)的固定頭部，這個固定頭部在所有的RTP分組中都出現(xiàn)，而接下來的多個相關(guān)源標(biāo)識CSRC（ContributingSource）只在RTP混合器合成多個流下才使用，可選的擴展頭部用于協(xié)議的擴展，最后是實際攜帶的負載字段，該字段所攜帶的實時多媒體信息的格式是由具體的應(yīng)用而確定的。V（2bits）版本標(biāo)識，目前的RTP協(xié)議版本為217RTP消息格式P（1bit）填充標(biāo)志，RTP填充方法：X（1bit）是否有一個擴展的頭部CC（4bits）給出相關(guān)源標(biāo)識的個數(shù)，固定頭部后面的CSRC列表包含了那些被合成在一起的源標(biāo)識。M（1bit）標(biāo)志具體含義隨所承載的負載類型而定。在視頻數(shù)據(jù)報文中，用于表示一幀的結(jié)束；在音頻數(shù)據(jù)包中，表示一串語音的開始。UDP頭部RTP頭部RTP負載填充字節(jié)填充的字節(jié)數(shù)UDP頭部中的長度字段填充字段18RTP消息格式負載類型（7bits）所攜帶的多媒體信息的類型，如MPEG視頻還是GSM編碼格式的語音信息。順序號（16bits）用于檢測報文丟失的情況，同時可以區(qū)別那些同一個時間戳的報文。一個RTP流每次發(fā)出一個RTP分組時該順序號遞增，初始順序號是隨機選擇的。時間戳（32bits）描述了報文中攜帶的第一個樣本生成的時間，這個時間不是絕對的時間值而是相對值（即采樣間隔數(shù)），（采樣頻率由所承載的負載類型所確定，如當(dāng)前的版本中，所有的視頻數(shù)據(jù)使用65536Hz）。時間戳的初始值是隨機生成的。19RTP消息格式SSRC（32bits）標(biāo)識該多媒體的信息源，它是在每個RTP數(shù)據(jù)源初始化時隨機生成的，需確保在所有成員中保持唯一。CSRC（0～15*32bits）列表給出了本RTP分組攜帶的負載在合成前的多媒體流的SSRC列表，其個數(shù)在CC指定。

注意：RTP報文沒有長度字段，所以底層協(xié)議必須提供相應(yīng)的封裝機制。20實時傳輸控制協(xié)議RTCPRTP負責(zé)傳遞多媒體會話中的實時數(shù)據(jù)。RTP配套有一個RTCP（Real-timeTransportControlProtocol），其主要功能包括對多媒體遞交的質(zhì)量的反饋，把多媒體流與會話成員對應(yīng)起來的手段，給出RTP媒體時間戳和發(fā)送者的實時時鐘之間的關(guān)系，標(biāo)識會話中的發(fā)送者以進行會話控制等。21RTCP定義了5種類型的RTCP分組來攜帶不同類型的控制信息：發(fā)送報告SR（SenderReport）給出了會話成員最近發(fā)送的多媒體流的情況，另外它還包含了該成員最近接收到多媒體流的狀況。接收報告RR（ReceiverReport）給出了該成員最近接收到的多媒體流的狀況。源描述SDES（SourceDescription）給出了有關(guān)該成員的一些描述信息，比如CNAME、電子郵件、名字、電話號碼、所在位置和應(yīng)用軟件的有關(guān)信息。BYE分組在成員離開會話時采用。APP用于攜帶和應(yīng)用相關(guān)的信息，它的具體格式和含義在相應(yīng)的腳本中定義。22RTCP這些不同類型的RTCP報文再通過低層協(xié)議如UDP傳遞，為了減少RTCP分組頭部帶來的開銷，RTCP報文可以“堆疊”在一起形成一個RTCP消息再發(fā)送。在“堆疊”起來的RTCP消息中至少必須包含2個RTCP分組，一個是接收報告，另外一個是源描述，其它分組可以根據(jù)需要包含進去，但是必須是在不會導(dǎo)致消息太大而無法通過低層網(wǎng)絡(luò)傳遞的前提下。23RTCPRR給出了最近接收到的所有RTP流的情況，它實際上是由多個接收報告塊組成，每個報告塊對應(yīng)著一個RTP流，該用戶最近收到過來自于該RTP流的分組。這樣RTP會話中的所有成員都會收到該接收報告，因而發(fā)送者可以利用這些反饋信息來采取相應(yīng)的動作，比如改變媒體流的編碼方式，調(diào)整它們的發(fā)送速率，以滿足在分組交換網(wǎng)絡(luò)中公平地共享帶寬資源或“平滑”地降級的要求。24RTCP每個接收報告塊主要包含對應(yīng)著某個RTP流的如下信息：該報告對應(yīng)的RTP流的SSRC標(biāo)識在上次接收報告至今這段時間內(nèi)來自于該RTP流的分組丟失率接收到的分組數(shù)除以期望接收的分組數(shù)，期望接收的分組數(shù)可以通過RTP分組頭部中的順序號來計算總的丟失分組數(shù)目前接收到的最高順序號25RTCP到達抖動（InterarrivalJitter）估計（RTP流中相鄰分組的平均到達間隔時間）最近的SR時刻tLSR（即最近收到的和該RTP流對應(yīng)的發(fā)送報告的NTP時間戳，如果以前沒有收到過，則為0）從接收到那個最近的發(fā)送報告到發(fā)送這個接收報告的間隔時間tDLSR。26RTCP到達抖動估計到達抖動描述了兩個相鄰的RTP報文在發(fā)送時的間隔與收到時兩者的間隔的偏差情況，通過變換后相當(dāng)于RTP相對傳輸時間的偏差D。所謂相對傳輸時間為RTP報文到達接收者的時間與報文中包括的RTP時間戳的差，即RTP報文i和j之間的相對傳輸時間為：

那么，平均到達抖動可以按照下列公式進行更新：

27RTCPSR實際上包括兩個部分發(fā)送報告塊接收報告塊給出了最近的RTP流的接收情況，和RR分組中包含的接收報告塊采用相同的格式。發(fā)送報告塊給出了本用戶最近發(fā)送的RTP流的情況，它包含如下信息最近生成的RTP分組所對應(yīng)的RTP時間戳和NTP時間戳（即實際的時間）目前為止已發(fā)送的分組和字節(jié)數(shù)28RTCP利用SR和RR，還可以計算出發(fā)送者到接收者的往返傳輸時間RTT。接收報告中記錄了最近收到的SR時刻tLSR以及接收到最近的SR到發(fā)送接收報告的間隔時間tDLSR，這樣在發(fā)送者收到RTP接收報告時記錄下當(dāng)前的時刻tarrival后，就可以按照下列公式計算RTT：29RTCPSDES分組中包含了一個CNAME信息，CNAME給出了會議成員的正規(guī)名字（CanonicalName），它唯一標(biāo)識了該會議成員，一般采用在RFC822中使用的E-mail格式標(biāo)識如host@domain，其中給出了成員所在的主機名和當(dāng)前用戶名。除了CNAME外，SDES還可以包含用戶全名、電話號碼、項目信息等。這些信息如對于實用的會議系統(tǒng)來說，往往是必要的。30流媒體技術(shù)相對于所有媒體數(shù)據(jù)都下載完后再進行播放，為了減少播放時延，可以考慮采取邊下載邊播放的方法，這也就是流媒體技術(shù)，有時也稱之為網(wǎng)絡(luò)放送（Webcasting）時間當(dāng)前在硬盤上的部分全部音頻或視頻流正在觀看的部分在緩沖區(qū)的部分31流媒體技術(shù)純HTTP流媒體傳輸HTTP無狀態(tài)協(xié)議，用戶和服務(wù)器之間的交互困難，很難對媒體的播放進行暫停、跳轉(zhuǎn)等控制對延時非常敏感、允許少量數(shù)據(jù)丟失的傳輸媒體流情況，TCP不適合Web瀏覽器媒體播放器1)HTTP請求元文件2)元文件WebServer3)HTTP請求多媒體文件32流媒體技術(shù)使用專門協(xié)議傳輸流媒體如RTP協(xié)議用戶和服務(wù)器之間的交互仍然困難Web瀏覽器媒體播放器1)HTTP請求元文件3)音頻或視頻2)元文件Web服務(wù)器流媒體服務(wù)器33流媒體技術(shù)引入RTSP進行交互控制實時