第8章因特網上音頻視頻服務

第8章因特網上音頻視頻服務第一頁，共84頁。第8章因特網上的音頻/視頻服務主要內容概述流式存儲音頻/視頻交互式音頻/視頻改進“盡最大努力交付”的服務2第二頁，共84頁。8.1概述1、概述計算機網絡最初是為傳送數(shù)據(jù)信息設計的提供的服務：因特網IP層提供的“盡最大努力交付”服務；每一個分組獨立交付的策略；對傳送數(shù)據(jù)信息是很合適的；上層（TCP協(xié)議）解決網絡不能提供可靠交付這一問題。多媒體信息：多媒體信息（包括聲音和圖像信息）與不包括聲音和圖像的數(shù)據(jù)信息有很大的區(qū)別3第三頁，共84頁。多媒體特點多媒體信息的信息量往往很大。時延和時延抖動：對時延和時延抖動均有較高的要求。實時數(shù)據(jù)(realtimedata)：在發(fā)送實時數(shù)據(jù)的同時，在接收端邊接收邊播放。4第四頁，共84頁。2、因特網的非等時性多媒體信號發(fā)送速率的恒定性（等時性）：模擬的多媒體信號經過采樣、模數(shù)轉換變?yōu)閿?shù)字信號；組裝成分組。這些分組發(fā)送速率是恒定性速率的（等時性）因特網本身是非等時的：因特網的分組傳輸是非恒定速率的tt因特網t模擬信號t采樣后的信號構成分組恒定速率非恒定速率5第五頁，共84頁。接收端需設置適當大小的緩存。當緩存中的分組數(shù)達到一定的數(shù)量后再以恒定速率按順序把分組讀出進行還原播放。緩存實際上就是一個先進先出的隊列。圖中標明的T叫做播放時延。3、解決辦法：在接收端設置緩存tT緩存（隊列）恒定速率t非恒定速率有可能發(fā)生分組丟失6第六頁，共84頁。緩存帶來的影響緩存使所有到達的分組都經受了遲延早到達的分組在緩存中停留的時間較長，而晚到達的分組在緩存中停留的時間則較短。以非恒定速率到達的分組，經過緩存后再以恒定速率讀出，就能夠在一定程度上消除了時延的抖動，付出的代價是增加了時延。7第七頁，共84頁。分組發(fā)出1

2

3

4

5

6t到達分組數(shù)6543211

2

3

4

5

6t緩存時間緩存時間再推遲播放時間如果網絡無時延推遲播放分組遲到網絡出現(xiàn)時延分組1的時延分組到達1

2

34

5

6t實際的網絡8第八頁，共84頁。4、需要解決的問題時延與抖動的限制：在傳送時延敏感(delaysensitive)的實時數(shù)據(jù)時，不僅傳輸時延不能太大，而且時延抖動也必須受到限制。丟失容忍(losstolerant)：對于傳送實時數(shù)據(jù)，很少量分組的丟失對播放效果的影響并不大（因為這是由人來進行主觀評價的），因而是可以容忍的。9第九頁，共84頁。分組的按序：由于分組的到達可能不按序，但將分組還原和播放時又應當是按序的。因此在發(fā)送多媒體分組時還應當給每一個分組加上序號。這表明還應當有相應的協(xié)議支持才行。時間戳(timestamp)：要使接收端能夠將節(jié)目中本來就存在的正常的短時間停頓（如音樂中停頓幾拍）和因某些分組的較大遲延造成的“停頓”區(qū)分開來。這就需要增加一個時間戳，以便告訴接收端應當在什么時間播放哪個分組。10第十頁，共84頁。5、改造現(xiàn)有的因特網資源子網：大量使用光纜和高速路由器，使網絡的時延和時延抖動就可以足夠小面向連接服務：把因特網改造為能夠對端到端的帶寬實現(xiàn)預留(reservation)，把使用無連接協(xié)議的因特網轉變?yōu)槊嫦蜻B接的網絡。協(xié)議棧的改動：部分改動因特網的協(xié)議棧，使多媒體信息在因特網上的傳輸質量得到改進。11第十一頁，共84頁。6、因特網提供的音頻/視頻服務分類流式存儲音頻/視頻：壓縮文件存放在服務器；邊下載邊播放；如電影、電視節(jié)目、歌曲等。流式實況音頻/視頻：邊錄制邊發(fā)送。如廣播、視頻。交互式音頻/視頻：實時交互式通信。IP電話等。12第十二頁，共84頁。8.2流式存儲音頻/視頻1、使用WWW服務器傳統(tǒng)的瀏覽器從服務器下載音頻/視頻文件用戶從客戶機的瀏覽器上用HTTP協(xié)議向服務器請求下載某個音頻/視頻文件。服務器如有此文件就發(fā)送給瀏覽器。在響應報文中就裝有用戶所要的音頻/視頻文件。整個下載過程可能會花費很長的時間。當瀏覽器完全收下這個文件后，就可以傳送給自己機器上的媒體播放器進行解壓縮，然后播放。說明：不涉及流；下載后才能播放13第十三頁，共84頁。萬維網服務器客戶機服務器媒體播放器

GET:音頻/視頻文件

RESPONSE

音頻/視頻文件瀏覽器14第十四頁，共84頁。2、使用具有元文件的萬維網服務器元文件：是一種非常小的文件，它描述或指明其他文件的一些重要信息。萬維網服務器客戶機服務器媒體播放器

元文件瀏覽器

GET:元文件

RESPONSEGET:音頻/視頻文件RESPONSE15第十五頁，共84頁。使用元文件下載音頻/視頻文件

瀏覽器使用HTTP的GET報文接入到WWW服務器。這個超鏈指向一個元文件。這個元文件有實際的音頻/視頻文件的統(tǒng)一資源定位符URL。

WWW服務器把該元文件裝入HTTP響應報文的主體，發(fā)回給瀏覽器?？蛻魴C瀏覽器調用相關的媒體播放器，把提取出的元文件傳送給媒體播放器。媒體播放器使用元文件中的URL，向萬維網服務器發(fā)送HTTP請求報文，要求下載音頻/視頻文件。

WWW服務器發(fā)送HTTP響應報文，把該音頻/視頻文件發(fā)送給媒體播放器。媒體播放器邊下載、邊解壓縮、邊播16第十六頁，共84頁。3、媒體服務器流式服務器(streamingserver)：即媒體服務器也，它支持流式音頻和視頻的傳送。媒體播放器：媒體播放器與媒體服務器的關系是客戶與服務器的關系。媒體播放器：向媒體服務器（而不是向萬維網服務器）請求音頻/視頻文件。交互協(xié)議：媒體服務器和媒體播放器之間采用另外的協(xié)議進行交互。17第十七頁，共84頁。使用媒體服務器萬維網服務器媒體播放器

元文件瀏覽器

GET:元文件

RESPONSEGET:音頻/視頻文件RESPONSE媒體服務器客戶機服務器18第十八頁，共84頁。采用媒體服務器下載音頻/視頻文件的步驟

瀏覽器使用HTTP的GET報文接入到WWW服務器。這個超鏈指向一個元文件。這個元文件有實際的音頻/視頻文件的統(tǒng)一資源定位符URL。萬維網服務器把該元文件裝入HTTP響應報文的主體，發(fā)回給瀏覽器?？蛻魴C瀏覽器調用相關的媒體播放器，把提取出的元文件傳送給媒體播放器。媒體播放器使用元文件中的URL接入到媒體服務器，請求下載瀏覽器所請求的音頻/視頻文件。下載可以借助于使用UDP的任何協(xié)議，例如使用實時運輸協(xié)議RTP。媒體服務器給出響應，把該音頻/視頻文件發(fā)送給媒體播放器。媒體播放器遲延若干秒后，以流的形式邊下載、邊解壓、邊播放19第十九頁，共84頁。4、使用媒體服務器和實時流式協(xié)議RTSP實時流式協(xié)議RTSP(Real-TimeStreamingProtocol)：RTSP協(xié)議以客戶服務器方式工作，它是一個多媒體播放控制協(xié)議使用戶在播放從因特網下載的實時數(shù)據(jù)時能夠進行控制，如：暫停/繼續(xù)、后退、前進等。又稱“因特網錄像機遙控協(xié)議”。要有專門的媒體播放器(mediaplayer)和媒體服務器(mediaserver)。20第二十頁，共84頁。萬維網服務器客戶機服務器媒體播放器

元文件瀏覽器媒體服務器音頻/視頻流

GET:元文件

RESPONSESETUPRESPONSEPLAYRESPONSE

RESPONSE

TEARDOWN

21第二十一頁，共84頁。使用RTSP的媒體服務器的工作過程

瀏覽器向萬維網服務器請求音頻/視頻文件。萬維網服務器從瀏覽器發(fā)送攜帶有元文件的響應。瀏覽器把收到的元文件傳送給媒體播放器。

RTSP客戶與媒體服務器的RTSP服務器建立連接。

RTSP服務器發(fā)送響應RESPONSE報文。

RTSP客戶發(fā)送PLAY報文，開始下載音頻/視頻文件。

RTSP服務器發(fā)送響應RESPONSE報文。

RTSP客戶發(fā)送TEARDOWN報文斷開連接。

RTSP服務器發(fā)送響應RESPONSE報文。22第二十二頁，共84頁。8.3交互式音頻/視頻8.3.1IP電話概述IP電話：VoIP（VoiceoverIP）、InternetTelephony、VON（VoiceOntheNet）狹義的IP電話：指在IP網絡上打電話（“IP網絡”指“使用IP協(xié)議的分組交換網”的簡稱）。廣義的IP電話：不僅僅是電話通信，而是在IP網絡上進行交互式多媒體實時通信（包括話音、視像等），甚至還包括即時傳信IM(InstantMessaging)。IP網關：在電話呼叫階段和呼叫釋放階段進行電話信令的轉換；在通話期間進行話音編碼的轉換。23第二十三頁，共84頁。IP電話網關的幾種連接方法

因特網PC到PC分組交換電路交換電路交換公用電話網IP

電話網關

因特網PC到固定電話機公用電話網IP

電話網關公用電話網IP

電話網關因特網固定電話機到固定電話機24第二十四頁，共84頁。IP電話的通話質量IP電話的通話質量主要由兩個因素決定一個是通話雙方端到端的時延和時延抖動另一個是話音分組的丟失率。但這兩個因素是不確定的，是取決于當時網絡上的通信量。經驗證明，在電話交談中，端到端的時延不應超過250ms，否則交談者就能感到不自然。25第二十五頁，共84頁。IP電話的端到端時延(1)話音信號進行模數(shù)轉換要經受時延。(2)話音比特流裝配成話音分組的時延。(3)話音分組的發(fā)送需要時間，此時間等于話音分組長度與通信線路的數(shù)據(jù)率之比。(4)話音分組在因特網中的存儲轉發(fā)時延。(5)話音分組在接收端緩存中暫存所引起的時延。(6)話音分組還原成模擬話音信號的時延。(7)話音信號在通信線路上的傳播時延。(8)終端設備的硬件和操作系統(tǒng)產生的接入時延。26第二十六頁，共84頁。低速率話音編碼的標準(1)G.729——速率為8kb/s的共軛結構代數(shù)碼激勵線性預測聲碼器CS-ACELP(Conjugate-StructureAlgebraic-Code-ExcitedLinearPrediction)。(2)G.723.1——速率為5.3/6.3kb/s的為多媒體通信用的低速率聲碼器。27第二十七頁，共84頁。播放時延有一個最佳值D

分組丟失率端到端時延20%10%5%100ms150ms400msABCN良好基本可用不好長途電話質量接收端播放時延增大28第二十八頁，共84頁。線速路由器提高路由器的轉發(fā)分組的速率對提高IP電話的質量也是很重要的。據(jù)統(tǒng)計，一個跨大西洋的IP電話一般要經過2030個路由器。若能改用吉比特路由器（又稱為線速路由器），則每秒可轉發(fā)5百萬至6千萬個分組（即交換速率達60Gb/s左右）。這樣還可進一步減少由網絡造成的時延。29第二十九頁，共84頁。關于SkypeSkype采用了P2P和全球索引技術提供快速路由選擇機制，管理成本大大降低。由于用戶路由信息分布式存儲于因特網的結點中，因此呼叫連接完成得很快。Skype采用了端對端加密方式，保證信息的安全性。Skype使用P2P的技術，用戶數(shù)據(jù)主要存儲在P2P網絡中，因此必須保證存儲在公共網絡中的數(shù)據(jù)是可靠的和沒有被篡改的。Skype對公共目錄中存儲的和用戶相關的數(shù)據(jù)都采用了數(shù)字簽名，保證了數(shù)據(jù)無法被篡改。Skype的問世給全球信息技術和通信產業(yè)帶來深遠的影響，也給每一位網絡使用者帶來生活方式的改變。30第三十頁，共84頁。8.3.2IP電話所需要的幾種應用協(xié)議TCPUDP信令服務質量IPv4/IPv6RTSPRTCPRSVPH.323SIPRTP應用層協(xié)議音頻/視頻SDP底層網絡31第三十一頁，共84頁。8.3.3實時運輸協(xié)議RTP實時運輸協(xié)議RTP(Real-timeTransportProtocol)RTP為實時應用提供端到端的運輸，但不提供任何服務質量的保證。多媒體數(shù)據(jù)塊經壓縮編碼處理后，先送給RTP封裝成為RTP分組，再裝入運輸層的UDP用戶數(shù)據(jù)報，然后再交給IP層。RTP是一個協(xié)議框架，只包含了實時應用的一些共同的功能。RTP自己并不對多媒體數(shù)據(jù)塊做任何處理，只是向應用層提供一些附加的信息，讓應用層知道應當如何進行處理。32第三十二頁，共84頁。RTP的層次從應用開發(fā)者的角度看，RTP應當是應用層的一部分。在應用的發(fā)送端，開發(fā)者必須編寫用RTP封裝分組的程序代碼，然后把RTP分組交給UDP插口接口。在接收端，RTP分組通過UDP插口接口進入應用層后，還要利用開發(fā)者編寫的程序代碼從RTP分組中把應用數(shù)據(jù)塊提取出來。33第三十三頁，共84頁。RTP也可看成是運輸層的一個子層RTP封裝了多媒體應用的數(shù)據(jù)塊。由于RTP向多媒體應用程序提供了服務（如時間戳和序號），因此也可以將RTP看成是在UDP之上的一個運輸層的子層。運輸層應用層IP數(shù)據(jù)鏈路層物理層RTPUDP34第三十四頁，共84頁。RTP分組的首部格式12字節(jié)序號位01381631有效載荷類型版本PXM參與源數(shù)時間戳同步源標識符(SSRC)參與源標識符(CSRC)[0..15]…發(fā)送RTP分組UDP用戶數(shù)據(jù)報IP數(shù)據(jù)報IP首部UDP首部RTP首部RTP數(shù)據(jù)部分（應用層數(shù)據(jù)）35第三十五頁，共84頁。8.3.4實時運輸控制協(xié)議RTCP實時運輸控制協(xié)議RTCP(RTPControlProtocol)RTCP是與RTP配合使用的協(xié)議。RTCP協(xié)議的主要功能：服務質量的監(jiān)視與反饋、媒體間的同步，以及多播組中成員的標識。RTCP分組也使用UDP傳送，但RTCP并不對聲音或視像分組進行封裝?？蓪⒍鄠€RTCP分組封裝在一個UDP用戶數(shù)據(jù)報中。RTCP分組周期性地在網上傳送，它帶有發(fā)送端和接收端對服務質量的統(tǒng)計信息報告。36第三十六頁，共84頁。RTCP使用的五種分組類型結束分組BYE表示關閉一個數(shù)據(jù)流。特定應用分組APP使應用程序能夠定義新的分組類型。接收端報告分組RR用來使接收端周期性地向所有的點用多播方式進行報告。發(fā)送端報告分組SR用來使發(fā)送端周期性地向所有接收端用多播方式進行報告。源點描述分組SDES給出會話中參加者的描述。37第三十七頁，共84頁。8.3.5H.323H.323是ITU-T于1996年制訂的一個名稱很長的建議書，1998年的第二個版本改用的名稱是“基于分組的多媒體通信系統(tǒng)”。H.323包括系統(tǒng)和構件的描述，呼叫模型的描述，呼叫信令過程，控制報文，復用，話音編解碼器，視像編解碼器，以及數(shù)據(jù)協(xié)議等，但不保證服務質量QoS。38第三十八頁，共84頁。H.323終端使用H.323協(xié)議進行多媒體通信分組交換網（例如，因特網）H.323H.323終端H.323終端

39第三十九頁，共84頁。H.323標準指明的四種構件(1)H.323終端(2)網關——網關連接到兩種不同的網絡，使H.323網絡可以和非H.323網絡進行通信。(3)網閘(gatekeeper)——所有的呼叫都要通過網閘，因為網閘提供地址轉換、授權、帶寬管理和計費功能。(4)多點控制單元MCU(MultipointControlUnit)——MCU支持三個或更多的H.323終端的音頻或視頻會議。40第四十頁，共84頁。H.323網關用來和非H.323網絡進行連接因特網公用電話網網關網閘H.323終端

多點控制單元MCU41第四十一頁，共84頁。H.323的協(xié)議體系結構音頻/視頻應用音頻編解碼視頻編解碼RTCPH.225.0登記信令H.225.0呼叫信令H.245控制信令RTPUDPTCPIP信令和控制數(shù)據(jù)應用T.120數(shù)據(jù)42第四十二頁，共84頁。8.3.6會話發(fā)起協(xié)議SIP會話發(fā)起協(xié)議SIP(SessionInitiationProtocol)SIP是一套較為簡單且實用的標準，目前已成為因特網的建議標準。SIP協(xié)議以因特網為基礎，把IP電話視為因特網上的新應用。SIP協(xié)議只涉及到IP電話的信令和有關服務質量問題，而沒有提供像H.323那樣多的功能。SIP沒有指定使用RTP協(xié)議，但實際上大家還是選用RTP和RTCP作為配合使用的協(xié)議。43第四十三頁，共84頁。SIP系統(tǒng)的構件SIP系統(tǒng)的兩種構件是用戶代理和網絡服務器。用戶代理包括用戶代理客戶和用戶代理服務器，前者用來發(fā)起呼叫，而后者用來接受呼叫。網絡服務器分為代理服務器和重定向服務器。代理服務器接受來自主叫用戶的呼叫請求，并將其轉發(fā)給下一跳代理服務器，最后將呼叫請求轉發(fā)給被叫用戶。重定向服務器不接受呼叫，它通過響應告訴客戶下一跳代理服務器的地址，由客戶按此地址向下一跳代理服務器重新發(fā)送呼叫請求。44第四十四頁，共84頁。SIP的地址十分靈活可以是電話號碼，也可以是電子郵件地址、IP地址或其他類型的地址。但一定要使用SIP的地址格式，例如：電話號碼

sip:zhangsan@1IPv4地址sip:電子郵件地址sip:45第四十五頁，共84頁。一個簡單的SIP會話

主叫方被叫方OK:地址ACKINVITE:地址，選項建立會話BYE終止會話電話交談通信tt46第四十六頁，共84頁。SIP登記器的用途

——跟蹤被叫方——

主叫方被叫方INVITE查找回答電話交談ttSIP代理服務器SIP登記器INVITEOKOKACKACKBYEtt47第四十七頁，共84頁。會話描述協(xié)議SDP會話描述協(xié)議SDP(SessionDescriptionProtocol)SDP在電話會議的情況下特別重要，因為電話會議的參加者是動態(tài)地加入和退出。SDP詳細地指明了媒體編碼、協(xié)議的端口號以及多播地址。SIP使用了HTTP的許多首部、編碼規(guī)則、差錯碼以及一些鑒別機制，它比H.323具有更好的可擴縮性。由于SIP問世較晚，因此它現(xiàn)在比H.323占有的市場份額要小。48第四十八頁，共84頁。8.4改進“盡最大努力交付”的服務8.4.1使因特網提供服務質量服務質量QoS：是服務性能的總效果，決定了一個用戶對服務的滿意程度。有服務質量的服務就是能夠滿足用戶的應用需求的服務。服務質量的基本指標：可用性、差錯率、響應時間、吞吐量、分組丟失率、連接建立時間、故障檢測和改正時間等。服務提供者可向其用戶保證某一種等級的服務質量。49第四十九頁，共84頁。主機H1和H2分別向主機H3和H4發(fā)送數(shù)據(jù)1.5Mb/s鏈路H1H2H3H4R2R1H1H21.5Mb/s鏈路輸出隊列1Mb/s的實時音頻數(shù)據(jù)FTP文件數(shù)據(jù)需要給不同性質的分組打上不同的標記。當H1和H2的分組進入R1時，R1應能識別實時數(shù)據(jù)分組，并使這些分組以高優(yōu)先級進入輸出隊列，而僅在隊列有多余空間時才準許低優(yōu)先級的FTP數(shù)據(jù)分組進入。50第五十頁，共84頁。主機H1和H2分別向主機H3和H4發(fā)送數(shù)據(jù)1.5Mb/s鏈路H1H2H3H4R2R1H1H21.5Mb/s鏈路輸出隊列1Mb/s的實時音頻數(shù)據(jù)高優(yōu)先級的FTP文件數(shù)據(jù)應當使路由器增加分類(classification)機制，即路由器根據(jù)某些準則（例如，根據(jù)發(fā)送數(shù)據(jù)的地址）對輸入分組進行分類，然后對不同類別的通信量給予不同的優(yōu)先級。51第五十一頁，共84頁。主機H1和H2分別向主機H3和H4發(fā)送數(shù)據(jù)1.5Mb/s鏈路H1H2H3H4R2R1H1H21.5Mb/s鏈路輸出隊列數(shù)據(jù)率異常的實時音頻數(shù)據(jù)FTP文件數(shù)據(jù)路由器應能將對數(shù)據(jù)流進行通信量的管制(policing)，使該數(shù)據(jù)流不影響其他正常數(shù)據(jù)流在網絡中通過。例如，可將H1的數(shù)據(jù)率限定為1Mb/s。R1不停地監(jiān)視H1的數(shù)據(jù)率。只要其數(shù)據(jù)率超過規(guī)定的1Mb/s，R1就將其中的某些分組丟棄。52第五十二頁，共84頁。主機H1和H2分別向主機H3和H4發(fā)送數(shù)據(jù)1.5Mb/s鏈路H1H2H3H4R2R1H1H21.5Mb/s鏈路輸出隊列數(shù)據(jù)率異常的實時音頻數(shù)據(jù)FTP文件數(shù)據(jù)應在路由器中再增加調度(scheduling)機制。利用調度功能給實時音頻分配1.0Mb/s的帶寬，給文件傳送分配0.5Mb/s的帶寬（相當于在帶寬為1.5Mb/s的鏈路中劃分出兩個邏輯鏈路），因而對這兩種應用都有相應的服務質量保證。53第五十三頁，共84頁。主機H1和H2分別向主機H3和H4發(fā)送數(shù)據(jù)1.5Mb/s鏈路H1H2H3H4R2R1H1H21.5Mb/s鏈路輸出隊列1Mb/s的實時數(shù)據(jù)總數(shù)據(jù)率已超過了1.5Mb/s鏈路的帶寬。比較合理的做法是讓一個數(shù)據(jù)流通過1.5Mb/s的鏈路，而阻止另一個數(shù)據(jù)流的通過。這就需要呼叫接納(calladmission)機制。數(shù)據(jù)流要預先聲明所需的服務質量，然后或者被準許進入網絡，或者被拒絕進入網絡。54第五十四頁，共84頁。8.4.2調度和管制機制1.調度機制“調度”就是指排隊的規(guī)則。如不采用專門的調度機制，則默認排隊規(guī)則就是先進先出FIFO(FirstInFirstOut)。當隊列已滿時，后到達的分組就被丟棄。先進先出的最大缺點就是不能區(qū)分時間敏感分組和一般數(shù)據(jù)分組，并且也不公平。在先進先出的基礎上增加按優(yōu)先級排隊，就能使優(yōu)先級高的分組優(yōu)先得到服務。55第五十五頁，共84頁。分組按優(yōu)先級排隊高優(yōu)先級隊列低優(yōu)先級隊列分組到達路由器調度分組離開路由器分類器（服務員）路由器高

高高低56第五十六頁，共84頁。高優(yōu)先級分組優(yōu)先接受服務t1235到達離開接受服務41325413254t高高高低低57第五十七頁，共84頁。分組離開路由器加權公平排隊WFQ(WeightedFairQueuing)分組到達路由器調度分類器w1w2w3123路由器58第五十八頁，共84頁。加權公平排隊WFQ分組到達后就將分組進行分類，然后送交與其類別對應的隊列。隊列按順序依次將隊首的分組發(fā)送到鏈路。遇到隊列空就跳過去。給隊列i

指派一個權重wi。隊列i

得到的平均服務時間為wi/(wj)，這里wj是對所有的非空隊列的權重求和。隊列i將得到的有保證的帶寬Ri

應為

（8-1）

59第五十九頁，共84頁。WFQ與FIFO的比較111111111112111234567891011111111111112345678910111111111111分組流1分組流2分組流11FIFOWFQ…(a)分組流1的分組連續(xù)輸入ttttt60第六十頁，共84頁。WFQ與FIFO的比較111111111112111234567891011111111111112345678910111111111111分組流1分組流2分組流11FIFOWFQ…ttttt(b)分組流1的分組斷續(xù)輸入61第六十一頁，共84頁。2.管制機制(1)平均速率：網絡需要控制一個數(shù)據(jù)流的平均速率。這里的平均速率是指在一定的時間間隔內通過的分組數(shù)。(2)峰值速率：峰值速率限制了數(shù)據(jù)流在非常短的時間間隔內的流量。(3)突發(fā)長度：網絡也限制在非常短的時間間隔內連續(xù)注入到網絡中的分組數(shù)。62第六十二頁，共84頁。漏桶管制器(leakybucketpolicer)

分組到達漏桶中最多裝入b

個權標拿走權標準許分組進入網絡等待權標在任何時間間隔t

內準許進入網絡的分組數(shù)=rt+b標記注入漏桶的速率為每秒r

個權標63第六十三頁，共84頁。漏桶機制與加權公平排隊相結合現(xiàn)假定有n個分組流輸入到一個路由器，復用后從一條鏈路輸出。每一個分組流使用漏桶機制進行管制，漏桶參數(shù)為bi和ri，i=1,2,…,n。設漏桶I已裝滿了bi個權標。因此bi個分組可馬上從路由器輸出。但分組流I得到的帶寬是由公式(10-1)給出。這bi個分組中的最后一個分組所經受的時延最大，它等于傳輸這bi個分組所需的時間dmax，即bi除以公式(10-1)給出的傳輸速率：(8-2)64第六十四頁，共84頁。分組離開路由器分組到達路由器用漏桶機制進行管制調度分類器w1wn隊列1…b1r1bnrn…隊列n路由器65第六十五頁，共84頁。8.4.3綜合服務IntServ與資源預留協(xié)議RSVPIntServ(IntegratedServices)可對單個的應用會話提供服務質量的保證，其主要特點有二，即：資源預留。路由器需要知道不斷出現(xiàn)的會話已預留了多少資源（即鏈路帶寬和緩存空間）。呼叫建立。需要服務質量保證的會話必須首先在源站到目的站的路徑上的每個路由器預留足夠的資源，以保證其端到端的服務質量要求。66第六十六頁，共84頁。IntServ定義了兩類服務有保證的服務(guaranteedservice)，可保證一個分組在通過路由器時的排隊時延有一個嚴格的上限。受控負載的服務(controlled-loadservice)，可以使應用程序得到比通常的“盡最大努力”更加可靠的服務。67第六十七頁，共84頁。IntServ由四個組成部分(1)資源預留協(xié)議RSVP，它是IntServ的信令協(xié)議。(2)接納控制(admissioncontrol)，用來決定是否同意對某一資源的請求。(3)分類器(classifier)，用來將進入路由器的分組進行分類，并根據(jù)分類的結果將不同類別的分組放入特定的隊列。(4)調度器(scheduler)，根據(jù)服務質量要求決定分組發(fā)送的前后順序。68第六十八頁，共84頁。流(flow)“流”是在多媒體通信中的一個常用的名詞，一般定義為:具有同樣的源IP地址、源端口號、目的IP地址、目的端口號、協(xié)議標識符以及服務質量需求的一連串分組。69第六十九頁，共84頁。RSVP協(xié)議的工作原理H1H250kb/sR2R1H3100kb/sH43Mb/sR3R4H53Mb/s源站(a)源點用多播發(fā)送PATH報文

表示PATH報文3Mb/s3Mb/s3Mb/s100kb/sH1H250kb/sR2R1H3100kb/sH43Mb/sR3R4H53Mb/s源站(b)各終點向源點返回RESV報文

表示RESV報文70第七十頁，共84頁。IntServ體系結構在路由器中的實現(xiàn)路由選擇協(xié)議路由選擇數(shù)據(jù)庫RSVP接納控制管理代理通信量控制數(shù)據(jù)庫分類器與分組轉發(fā)調度器分組入分組出71第七十一頁，共84頁。綜合服務IntServ體系結構存在的主要問題(1)狀態(tài)信息的數(shù)量與流的數(shù)目成正比。因此在大型網絡中，按每個流進行資源預留會產生很大的開銷。(2)IntServ體系結構復雜。若要得到有保證的服務，所有的路由器都必須裝有RSVP、接納控制、分類器和調度器。(3)綜合服務IntServ所定義的服務質量等級數(shù)量太少，不夠靈活。72第七十二頁，共84頁。8.4.4區(qū)分服務DiffServ1.區(qū)分服務的基本概念區(qū)分服務DiffServ(DifferentiatedServices)由于綜合服務IntServ和資源預留協(xié)議RSVP都較復雜，很難在大規(guī)模的網絡中實現(xiàn)，因此IETF提出了新的策略，即區(qū)分服務DiffServ。區(qū)分服務有時也簡寫為DS。因此，具有區(qū)分服務功能的結點就稱為DS結點。73第七十三頁，共84頁。區(qū)分服務DiffServ的要點(1)DiffServ在路由器中增加區(qū)分服務的功能。DiffServ將IPv4協(xié)議中原有的服務類型字段和IPv6的通信量類字段定義為區(qū)分服務字段DS。路由器根據(jù)DS字段的值來轉發(fā)分組。利用DS字段可提供不同等級的服務質量。DS字段現(xiàn)只使用前6bit，即區(qū)分服務碼點DSCP(DifferentiatedServicesCodePoint)