計(jì)算機(jī)網(wǎng)絡(luò)第8章因特網(wǎng)上的音頻視頻服務(wù)

計(jì)算機(jī)網(wǎng)絡(luò)（第5版）

第8章因特網(wǎng)上的音頻/視頻服務(wù)

課件制作人：謝希仁

第8章因特網(wǎng)上的音頻/視頻服務(wù)

8.1概述

8.2流式存儲(chǔ)音頻/視頻

8.2.1具有元文件的萬維網(wǎng)服務(wù)器

8.2.2媒體服務(wù)器

8.2.3實(shí)時(shí)流式協(xié)議RTSP

課件制作人：謝希仁

第8章因特網(wǎng)上的音頻/視頻服務(wù)

（續(xù)）

8.3交互式音頻/視頻

8.3.1IP電話概述

8.3.2IP電話所需要的幾種應(yīng)用協(xié)議

8.3.3實(shí)時(shí)運(yùn)輸協(xié)議RTP

8.3.4實(shí)時(shí)運(yùn)輸控制協(xié)議RTCP

8.3.5H.323

8.3.6會(huì)話發(fā)起協(xié)議SIP

課件制作人：謝希仁

第8章因特網(wǎng)上的音頻/視頻服務(wù)

（續(xù)）

8.4改進(jìn)“盡最大努力交付”的服務(wù)

8.4.1使因特網(wǎng)提供服務(wù)質(zhì)量

8.4.2調(diào)度和管制機(jī)制

8.4.3綜合服務(wù)IntServ和資源預(yù)留

協(xié)議RSVP

8.4.4區(qū)分服務(wù)DiffServ

課件制作人：謝希仁

8.1概述

■計(jì)算機(jī)網(wǎng)絡(luò)最初是為傳送數(shù)據(jù)信息設(shè)計(jì)

的。因特網(wǎng)IP層提供的“盡最大努力交

付”服務(wù)，以及每一個(gè)分組獨(dú)立交付的

策略，對傳送數(shù)據(jù)信息也是很合適的。

■因特網(wǎng)使用的TCP協(xié)議可以很好地解決

網(wǎng)絡(luò)不能提供可靠交付這一問題。

課件制作人：謝希仁

多媒體信息的特點(diǎn)

■多媒體信息(包括聲音和圖像信息)與

不包括聲音和圖像的數(shù)據(jù)信息有很大的

區(qū)別。

■多媒體信息的信息量往往很大。

■在傳輸多媒體數(shù)據(jù)時(shí)，對時(shí)延和時(shí)延抖

動(dòng)均有較高的要求。

■多媒體數(shù)據(jù)往往是實(shí)時(shí)數(shù)據(jù)(realtime

data),它的含義是：在發(fā)送實(shí)時(shí)數(shù)據(jù)的

同時(shí)，在接收端邊接收邊播放。

課件制作人：謝希仁

因特網(wǎng)是非等時(shí)的

■模擬的多媒體信號(hào)經(jīng)過采樣和模數(shù)轉(zhuǎn)換變?yōu)閿?shù)

字信號(hào)，再組裝成分組。這些分組的發(fā)送速率

是恒定的（等時(shí)的）。

■傳統(tǒng)的因特網(wǎng)本身是非等時(shí)的。因此經(jīng)過因特

網(wǎng)的分組變成了非恒定速率的分組。

丁后方采樣后的信號(hào)構(gòu)成分組,

八八^^一UillhilkhuMh7口胃hItV因特網(wǎng).1口“口

恒定速率/非恒定速率

課件制作人：謝希仁

在接收端設(shè)置緩存

■接收端需設(shè)置適當(dāng)大小的緩存。當(dāng)緩存中的分

組數(shù)達(dá)到一定的數(shù)量后再以恒定速率按順序把

分組讀出進(jìn)行還原播放。

■緩存實(shí)際上就是一個(gè)先進(jìn)先出的隊(duì)列。圖中標(biāo)

明的丁叫做播放時(shí)延。

有可能發(fā)生

分組丟失

緩存（隊(duì)列）

非恒定速率T恒定速率

課件制作人：謝希仁

緩存的影響

■緩存使所有到達(dá)的分組都經(jīng)受了遲延。

■早到達(dá)的分組在緩存中停留的時(shí)間較長,

而晚到達(dá)的分組在緩存中停留的時(shí)間則

較短。

■以非恒定速率到達(dá)的分組，經(jīng)過緩存后

再以恒定速率讀出，就能夠在一定程度

上消除了時(shí)延的抖動(dòng)。但我們付出的代

價(jià)是增加了時(shí)延。

課件制作人：謝希仁

分組

發(fā)出tttttt

123456

需要解決的問題

■在傳送時(shí)延敏感(delaysensitive)的實(shí)時(shí)

數(shù)據(jù)時(shí)，不僅傳輸時(shí)延不能太大，而且

時(shí)延抖動(dòng)也必須受到限制。

■對于傳送實(shí)時(shí)數(shù)據(jù)，很少量分組的丟失

對播放效果的影響并不大(因?yàn)檫@是由

人來進(jìn)行主觀評價(jià)的)，因而是可以容

忍的。丟失容忍(losstolerant)也是實(shí)時(shí)

數(shù)據(jù)的另一個(gè)重要特點(diǎn)。

課件制作人：謝希仁

需要解決的問題（續(xù)）

■由于分組的到達(dá)可能不按序，但將分組還原和

播放時(shí)又應(yīng)當(dāng)是按序的。因此在發(fā)送多媒體分

組時(shí)還應(yīng)當(dāng)給每一個(gè)分組加上序號(hào)。這表明還

應(yīng)當(dāng)有相應(yīng)的協(xié)議支持才行。

■要使接收端能夠?qū)⒐?jié)目中本來就存在的正常的

短時(shí)間停頓（如音樂中停頓幾拍）和因某些分

組的較大遲延造成的“停頓”區(qū)分開來。這就

需要增加一個(gè)時(shí)間戳（timestamp）,以便告訴接

收端應(yīng)當(dāng)在什么時(shí)間播放哪個(gè)分組。

課件制作人：謝希仁

必須改造現(xiàn)有的因特網(wǎng)

■大量使用光纜和高速路由器,網(wǎng)絡(luò)的時(shí)延和時(shí)

延抖動(dòng)就可以足夠小，在因特網(wǎng)上傳送實(shí)時(shí)數(shù)

據(jù)就不會(huì)有問題。

■把因特網(wǎng)改造為能夠?qū)Χ说蕉说膸拰?shí)現(xiàn)預(yù)留

(reservation),把使用無連接協(xié)議的因特網(wǎng)轉(zhuǎn)

變?yōu)槊嫦蜻B接的網(wǎng)絡(luò)。

■部分改動(dòng)因特網(wǎng)的協(xié)議棧所付出的代價(jià)較小，

而這也能夠使多媒體信息在因特網(wǎng)上的傳輸質(zhì)

量得到改進(jìn)。

課件制作人：謝希仁

目前因特網(wǎng)提供的音頻/視頻服務(wù)

大體上可分為三種類型

■流式(streaming)存儲(chǔ)音頻/視頻一一邊下

載邊播放。

■流式實(shí)況音頻/視頻——邊錄制邊發(fā)送。

■交互式音頻/視頻——實(shí)時(shí)交互式通信。

課件制作人：謝希仁

“邊下載邊播放”中的“下載”

■“邊下載邊播放”結(jié)束后,在用戶的硬盤上沒有

留下有關(guān)播放內(nèi)容的任何痕跡。

■流媒體(streamingmedia),即流式音頻/視頻。

■流媒體特點(diǎn)就是“邊下載邊播放"(streaming

andplaying)。

課件制作人：謝希仁

8.2流式存儲(chǔ)音頻/視頻

-傳統(tǒng)的下載文件方法

客戶機(jī)口

V服務(wù)器

----------?GET:音頻/視頻文件

萬維網(wǎng)

瀏覽器RESPONSE?

服務(wù)器

音頻/視頻文件

1,

媒體

播放器

課件制作人：謝希仁

傳統(tǒng)的瀏覽器從服務(wù)器

下載音頻/視頻文件

?用戶從客戶機(jī)(clientmachine)的瀏覽器上用

HTTP協(xié)議向服務(wù)器請求下載某個(gè)音頻/視頻文

件。

?服務(wù)器如有此文件就發(fā)送給瀏覽器。在響應(yīng)報(bào)

文中就裝有用戶所要的音頻/視頻文件。整個(gè)下

載過程可能會(huì)花費(fèi)很長的時(shí)間。

?當(dāng)瀏覽器完全收下這個(gè)文件后，就可以傳送給

自己機(jī)器上的媒體播放器進(jìn)行解壓縮，然后播

放。

課件制作人：謝希仁

8.2.1具有元文件的萬維網(wǎng)服務(wù)器

■元文件就是一種非常小的文件，它描述或指明其他文

件的一些重要信息。

客戶機(jī)口

___zd服務(wù)器

____

-----------?GET:元文件-

瀏覽器RESPONSE?

■

萬維網(wǎng)

元文件

服務(wù)器

?GET:音頻/視頻文件-

媒體二

播放器.______________RESPONSE?

.…乍人:謝希仁

使用元文件下載音頻/視頻文件

?瀏覽器用戶使用HTTP的GET報(bào)文接入到萬維網(wǎng)服

務(wù)器。這個(gè)超鏈指向一個(gè)元文件。這個(gè)元文件有實(shí)際

的音頻/視頻文件的統(tǒng)一資源定位符URLo

?萬維網(wǎng)服務(wù)器把該元文件裝入HTTP響應(yīng)報(bào)文的主體,

發(fā)回給瀏覽器。

?客戶機(jī)瀏覽器調(diào)用相關(guān)的媒體播放器，把提取出的元

文件傳送給媒體播放器。

?媒體播放器使用元文件中的URL,向萬維網(wǎng)服務(wù)器發(fā)

送HTTP請求報(bào)文，要求下載音頻/視頻文件。

?萬維網(wǎng)服務(wù)器發(fā)送HTTP響應(yīng)報(bào)文，把該苜頻/視頻文

件發(fā)送給媒體播放器o媒體播放器邊下載邊解壓縮邊

播放。

課件制作人：謝希仁

8.2.2媒體服務(wù)器

■媒體服務(wù)器也稱為流式服務(wù)器(streaming

server),它支持流式音頻和視頻的傳送。

■媒體播放器與媒體服務(wù)器的關(guān)系是客戶與服務(wù)

器的關(guān)系。

■媒體播放器不是向萬維網(wǎng)服務(wù)器而是向媒體服

務(wù)器請求音頻/視頻文件。

■媒體服務(wù)器和媒體播放器之間采用另外的協(xié)議

進(jìn)仃父互。

課件制作人：謝希仁

使用媒體服務(wù)器

客戶機(jī)服務(wù)器

□

?GET:元文件

.

萬維網(wǎng)

瀏覽器

RESPONSE?服務(wù)器

?

元文件

?GET:音頻/視頻文件

媒體一媒體

播放器RESPONSE?服務(wù)器

課件制作人：謝希仁

采用媒體服務(wù)器

下載音頻/視頻文件的步驟

???前三個(gè)步驟仍然和上一節(jié)的一樣,區(qū)別就

是后面兩個(gè)步驟。

?媒體播放器使用元文件中的URL接入到媒體

服務(wù)器，請求下載瀏覽器所請求的音頻/視頻文

件。下載可以借助于使用UDP的任何協(xié)議，

例如使用實(shí)時(shí)運(yùn)輸協(xié)議RTPO

?媒體服務(wù)器給出響應(yīng)，把該音頻/視頻文件發(fā)

送給媒體播放器。媒體播放器在遲延了若干秒

后，以流的形式邊下載邊解壓縮邊播放。

課件制作人：謝希仁

8.2.3實(shí)時(shí)流式協(xié)議RTSP

(Real-TimeStreamingProtocol)

-RTSP協(xié)議以客戶服務(wù)器方式工作，它是一個(gè)

多媒體播放控制協(xié)議，用來使用戶在播放從因

特網(wǎng)下載的實(shí)時(shí)數(shù)據(jù)時(shí)能夠進(jìn)行控制，如：暫

停/繼續(xù)、后退、前進(jìn)等。因此RTSP又稱為

“因特網(wǎng)錄像機(jī)遙控協(xié)議”。

■要實(shí)現(xiàn)RTSP的控制功能，我們不僅要有協(xié)議,

而且要有專門的媒體播放器(mediaplayer)和

媒體服務(wù)器(mediaserver)o

課件制作人：謝希仁

客戶機(jī)服務(wù)器

__zd

?GET:元文件

萬維網(wǎng)

瀏覽器一RESPONSE?服務(wù)器

ntr

元文件

1,

?SETUP」

RESPONSE豆

?PLAY.

RESPONSE?

媒體媒體

播放器音頻/視頻流服務(wù)器

?TEARDOWN.

RESPONSE?

使用RTSP的媒體服務(wù)器

的工作過程

?瀏覽器向萬維網(wǎng)服務(wù)器請求音頻/視頻文件。

?萬維網(wǎng)服務(wù)器從瀏覽器發(fā)送攜帶有元文件的響應(yīng)。

?瀏覽器把收到的元文件傳送給媒體播放器。

?RTSP客戶與媒體服務(wù)器的RTSP服務(wù)器建立連接。

?RTSP服務(wù)器發(fā)送響應(yīng)RESPONSE報(bào)文。

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

?RTSP服務(wù)器發(fā)送響應(yīng)RESPONSE報(bào)文。

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

?RTSP服務(wù)器發(fā)送響應(yīng)RESPONSE報(bào)文。

課件制作人：謝希仁

8.3交互式音頻/視頻

8.3.1IP電話概述

■狹義的IP電話就是指在IP網(wǎng)絡(luò)上打電話。

所謂“IP網(wǎng)絡(luò)”就是“使用IP協(xié)議的分組

交換網(wǎng)”的簡稱。

■廣義的IP電話則不僅僅是電話通信，而且

還可以是在IP網(wǎng)絡(luò)上進(jìn)行交互式多媒體實(shí)

時(shí)通信(包括話音、視像等)，甚至還包

括即時(shí)傳信IM(InstantMessaging)。

課件制作人：謝希仁

IP電話網(wǎng)關(guān)的幾種連接方法

固定電話機(jī)到固定電話機(jī)

IP電話的通話質(zhì)量

■IP電話的通話質(zhì)量主要由兩個(gè)因素決定。

一個(gè)是通話雙方端到端的時(shí)延和時(shí)延抖

動(dòng)，另一個(gè)是話音分組的丟失率。但這

兩個(gè)因素是不確定的，是取決于當(dāng)時(shí)網(wǎng)

絡(luò)上的通信量。

■經(jīng)驗(yàn)證明，在電話交談中，端到端的時(shí)

延不應(yīng)超過250ms,否則交談?wù)呔湍芨?/p>

到不自然。

課件制作人：謝希仁

IP電話的端到端時(shí)延

H)話音信號(hào)進(jìn)行模數(shù)轉(zhuǎn)換要經(jīng)受時(shí)延。

(2)話音比特流裝配成話音分組的時(shí)延。

(3)話音分組的發(fā)送需要時(shí)間，此時(shí)間等于話音分

組長度與通信線路的數(shù)據(jù)率之比。

(4)話音分組在因特網(wǎng)中的存儲(chǔ)轉(zhuǎn)發(fā)時(shí)延。

(5)話音分組在接收端緩存中暫存所引起的時(shí)延。

(6)話音分組還原成模擬話音信號(hào)的時(shí)延。

(7)話音信號(hào)在通信線路上的傳播時(shí)延。

(8)終端設(shè)備的硬件和操作系統(tǒng)產(chǎn)生的接入時(shí)延。

課件制作人：謝希仁

低速率話音編碼的標(biāo)準(zhǔn)

⑴G.729——速率為8kb/s的共聊結(jié)構(gòu)代

數(shù)碼激勵(lì)線性預(yù)測聲碼器CS-ACELP

(Conjugate-StructureAlgebraic-Code-

ExcitedLinearPrediction)□

(2)G.723.1—速率為5.3/6.3kb/s的為多

媒體通信用的低速率聲碼器。

課件制作人：謝希仁

播放時(shí)延有一個(gè)最佳值

100ms150ms400ms

課件制作人：謝希仁

線速路由器

■提高路由器的轉(zhuǎn)發(fā)分組的速率對提高IP

電話的質(zhì)量也是很重要的。

■據(jù)統(tǒng)計(jì)，一個(gè)跨大西洋的IP電話一般要

經(jīng)過20?30個(gè)路由器。

■若能改用吉比特路由器（又稱為線速路

由器），則每秒可轉(zhuǎn)發(fā)5百萬至6千萬

個(gè)分組（即交換速率達(dá)60Gb/s左右）。

這樣還可進(jìn)一步減少由網(wǎng)絡(luò)造成的時(shí)延。

課件制作人：謝希仁

關(guān)于Skype

■Skype采用了P2P和全球索引技術(shù)提供快速路由選擇

機(jī)制，管理成本大大降低。由于用戶路由信息分布式

存儲(chǔ)于因特網(wǎng)的結(jié)點(diǎn)中，因此呼叫連接完成得很快。

■Skype采用了端對端加密方式，保證信息的安全性。

■Skype使用P2P的技術(shù)，用戶數(shù)據(jù)主要存儲(chǔ)在P2P

網(wǎng)絡(luò)中，因此必須保證存儲(chǔ)在公共網(wǎng)絡(luò)中的數(shù)據(jù)是可

靠的和沒有被篡改的。Skype對公共目錄中存儲(chǔ)的和

用戶相關(guān)的數(shù)據(jù)都采用了數(shù)字簽名，保證了數(shù)據(jù)無法

被篡改。

■Skype的問世給全球信息技術(shù)和通信產(chǎn)業(yè)帶來深遠(yuǎn)的

影響，也給每一位網(wǎng)絡(luò)使用者帶來生活方式的改變。

課件制作人：謝希仁

8.3.2IP電話所需要的幾種應(yīng)用協(xié)議

信令

應(yīng)

用

層

協(xié)

議

8.3.3實(shí)時(shí)運(yùn)輸協(xié)議RTP

(Real-timeTransportProtocol)

■RTP為實(shí)時(shí)應(yīng)用提供端到端的運(yùn)輸，但不提供任

何服務(wù)質(zhì)量的保證。

■多媒體數(shù)據(jù)塊經(jīng)壓縮編碼處理后，先送給RTP封

裝成為RTP分組，再裝入運(yùn)輸層的UDP用戶數(shù)

據(jù)報(bào)，然后再交給IP層。

■RTP是一個(gè)協(xié)議框架，只包含了實(shí)時(shí)應(yīng)用的一些

共同的功能。

■RTP自己并不對多媒體數(shù)據(jù)塊做任何處理，而只

是向應(yīng)用層提供一些附加的信息，讓應(yīng)用層知道

應(yīng)當(dāng)如何進(jìn)行處理。

課件制作人：謝希仁

RTP的層次

■從應(yīng)用開發(fā)者的角度看，RTP應(yīng)當(dāng)是應(yīng)

用層的一部分。

■在應(yīng)用的發(fā)送端，開發(fā)者必須編寫用

RTP封裝分組的程序代碼，然后把RTP

分組交給UDP插口接口。

■在接收端，RTP分組通過UDP插口接口

進(jìn)入應(yīng)用層后，還要利用開發(fā)者編寫的程

序代碼從RTP分組中把應(yīng)用數(shù)據(jù)塊提取

出來。

課件制作人：謝希仁

RTP也可看成是

運(yùn)輸層的一個(gè)子層

■RTP封裝了多媒體應(yīng)用的

數(shù)據(jù)塊。由于RTP向多

媒體應(yīng)用程序提供了服務(wù)

（如時(shí)間戳和序號(hào)），因

此也可以將RTP看成是

在UDP之上的一個(gè)運(yùn)輸

層的子層。

課件制作人：謝希仁

RTP分組的首部格式

發(fā)送------------------------------------------------------------

<=IP首部UDP首部RTP首部RTP數(shù)據(jù)部分（應(yīng)用層數(shù)據(jù)）

-------------RTP分組

-UDP用戶數(shù)據(jù)報(bào)

IP數(shù)據(jù)報(bào)--------

8.3.4實(shí)時(shí)運(yùn)輸控制協(xié)議RTCP

(RTPControlProtocol)

■RTCP是與RTP配合使用的協(xié)議。

■RTCP協(xié)議的主要功能是：服務(wù)質(zhì)量的監(jiān)視與反

饋、媒體間的同步，以及多播組中成員的標(biāo)識(shí)。

■RTCP分組也使用UDP傳送，但RTCP并不對

聲音或視像分組進(jìn)行封裝。

■可將多個(gè)RTCP分組封裝在一個(gè)UDP用戶數(shù)據(jù)

報(bào)中。

■RTCP分組周期性地在網(wǎng)上傳送，它帶有發(fā)送端

和接收端對服務(wù)質(zhì)量的統(tǒng)計(jì)信息報(bào)告。

課件制作人：謝希仁

RTCP使用的五種分組類型

■結(jié)束分組BYE表示關(guān)閉一個(gè)數(shù)據(jù)流。

■特定應(yīng)用分組APP使應(yīng)用程序能夠定義新的分

組類型。

-接收端報(bào)告分組RR用來使接收端周期性地向

所有的點(diǎn)用多播方式進(jìn)行報(bào)告。

■發(fā)送端報(bào)告分組SR用來使發(fā)送端周期性地向所

有接收端用多播方式進(jìn)行報(bào)告。

■源點(diǎn)描述分組SDES給出會(huì)話中參加者的描述。

課件制作人：謝希仁

8.3.5H.323

■H.323是ITU-T于1996年制訂的一個(gè)名稱很長

的建議書，1998年的第二個(gè)版本改用的名稱是

“基于分組的多媒體通信系統(tǒng)”。

■H.323包括系統(tǒng)和構(gòu)件的描述，呼叫模型的描述,

呼叫信令過程，控制報(bào)文，復(fù)用，話音編解碼

器，視像編解碼器，以及數(shù)據(jù)協(xié)議等，但不保

證服務(wù)質(zhì)量QoSo

課件制作人：謝希仁

H.323終端使用H.323協(xié)議

進(jìn)行多媒體通信

課件制作人：謝希仁

H.323標(biāo)準(zhǔn)指明的四種構(gòu)件

⑴H.323終端

(2)網(wǎng)關(guān)——網(wǎng)關(guān)連接到兩種不同的網(wǎng)絡(luò)，使H.323

網(wǎng)絡(luò)可以和非H.323網(wǎng)絡(luò)進(jìn)行通信。

⑶網(wǎng)閘(gatekeeper)------所有的呼叫都要通過網(wǎng)閘，

因?yàn)榫W(wǎng)閘提供地址轉(zhuǎn)換、授權(quán)、帶寬管理和計(jì)費(fèi)功

能。

(4)多點(diǎn)控制單元MCU(MultipointControlUnit)——

MCU支持三個(gè)或更多的H.323終端的音頻或視頻

會(huì)議。

課件制作人：謝希仁

H.323網(wǎng)關(guān)用來和

非H.323網(wǎng)絡(luò)進(jìn)行連接

多點(diǎn)控制單元

MCU

H.323終端

課件制作人：謝希仁

H.323的協(xié)議體系結(jié)構(gòu)

苜頻/視頻應(yīng)用信令和控制數(shù)據(jù)應(yīng)用

苜頻視頻

H.225.0H.225.0H.245

編解碼編解碼T.120

RTCP登記呼叫控制

彳言令數(shù)據(jù)

信令1口?

RTP

UDPTCP

IP

課件制作人：謝希仁

8.3.6會(huì)話發(fā)起協(xié)議SIP

I(SessionInitiationProtocol)

■SIP是一套較為簡單且實(shí)用的標(biāo)準(zhǔn)，目前已成

為因特網(wǎng)的建議標(biāo)準(zhǔn)。

■SIP協(xié)議以因特網(wǎng)為基礎(chǔ)，把IP電話視為因特

網(wǎng)上的新應(yīng)用。

■SIP協(xié)議只涉及到IP電話的信令和有關(guān)服務(wù)質(zhì)

量問題，而沒有提供像H.323那樣多的功能。

■SIP沒有指定使用RTP協(xié)議，但實(shí)際上大家還

是選用RTP和RTCP作為配合使用的協(xié)議。

課件制作人：謝希仁

SIP系統(tǒng)的構(gòu)件

■SIP系統(tǒng)的兩種構(gòu)件是用戶代理和網(wǎng)絡(luò)服務(wù)器。

■用戶代理包括用戶代理客戶和用戶代理服務(wù)器，

前者用來發(fā)起呼叫，而后者用來接受呼叫。

■網(wǎng)絡(luò)服務(wù)器分為代理服務(wù)器和重定向服務(wù)器。

■代理服務(wù)器接受來自主叫用戶的呼叫請求，并將

其轉(zhuǎn)發(fā)給下一跳代理服務(wù)器，最后將呼叫請求轉(zhuǎn)

發(fā)給被叫用戶。

■重定向服務(wù)器不接受呼叫，它通過響應(yīng)告訴客戶

下一跳代理服務(wù)器的地址，由客戶按此地址向下

一跳代理服務(wù)器重新發(fā)送呼叫請求。

課件制作人：謝希仁

SIP的地址十分靈活

■可以是電話號(hào)石馬,也可以是電子郵件地

址、IP地址或其他類型的地址。但一定

要使用SIP的地址格式，例如：

-電話號(hào)碼

sip:zhangsan@8625-87654321

■IPv4地址

sip:zhangsan@6

■電子郵件地址

sip:zhangsan@public1.

課件制作人：謝希仁

一個(gè)簡單的SIP會(huì)話

主叫方被叫方

課件制作人：謝希仁

SIP登記器的用途

——跟蹤被叫方一

SIP代理

主叫方服務(wù)器SIP登記器被叫方

事

U___、

INVITE查找

百洛

INVITE

OK

ACK

電話交談

BYE

課件制作人￡謝希仁

1「

會(huì)話描述協(xié)議SDP

(SessionDescriptionProtocol)

■SDP在電話會(huì)議的情況下特別重要，因?yàn)殡娫?/p>

會(huì)議的參加者是動(dòng)態(tài)地加入和退出。

■SDP詳細(xì)地指明了媒體編碼、協(xié)議的端口號(hào)以

及多播地址。

■SIP使用了HTTP的許多首部、編碼規(guī)則、差

錯(cuò)碼以及一些鑒別機(jī)制，它比H.323具有更好

的可擴(kuò)縮性。

■由于SIP問世較晚，因此它現(xiàn)在比H.323占

有的市場份額要小。

課件制作人：謝希仁

U?r以心,8月又，、力乂I'JHunix

務(wù)

JL8.4.1使因特網(wǎng)提供服務(wù)質(zhì)量

■服務(wù)質(zhì)量QoS是服務(wù)性能的總效果，此效果決

定了一個(gè)用戶對服務(wù)的滿意程度。因此在最簡

單的意義上，有服務(wù)質(zhì)量的服務(wù)就是能夠滿足

用戶的應(yīng)用需求的服務(wù)。

■服務(wù)質(zhì)量可用若干基本的性能指標(biāo)來描述，包

括可用性、差錯(cuò)率、響應(yīng)時(shí)間、吞吐量、分組

丟失率、連接建立時(shí)間、故障檢測和改正時(shí)間

等。服務(wù)提供者可向其用戶保證某一種等級(jí)的

服務(wù)質(zhì)量。

課件制作人：謝希仁

主機(jī)H1和山分別向主機(jī)H3和H4發(fā)送數(shù)據(jù)

?I1Mb/s的實(shí)時(shí)音頻數(shù)據(jù)?,H3

需要給不同性質(zhì)的分組打上不同的標(biāo)記。當(dāng)?和力的

分組進(jìn)入時(shí)，R應(yīng)能識(shí)別實(shí)時(shí)數(shù)據(jù)分組，并使這些

分組以高優(yōu)先級(jí)進(jìn)入輸出隊(duì)列，而僅在隊(duì)列有多余空間

時(shí)才準(zhǔn)許低優(yōu)先級(jí)的FTP數(shù)據(jù)分組進(jìn)入。

主機(jī)H1和力分別向主機(jī)H3和H4發(fā)送數(shù)據(jù)

?I1Mb/s的實(shí)時(shí)音頻數(shù)據(jù)?,H3

應(yīng)當(dāng)使路由器增加分類(class幣cation)機(jī)制，即路由器

根據(jù)某些準(zhǔn)則(例如，根據(jù)發(fā)送數(shù)據(jù)的地址)對輸入分

組進(jìn)行分類，然后對不同類別的通信量給予不同的優(yōu)先

級(jí)。

主機(jī)H1和力分別向主機(jī)H3和H4發(fā)送數(shù)據(jù)

?I數(shù)據(jù)率異常的實(shí)時(shí)音頻數(shù)據(jù)IH3

路由器應(yīng)能將對數(shù)據(jù)流進(jìn)行通信量的管制(policing),

使該數(shù)據(jù)流不影響其他正常數(shù)據(jù)流在網(wǎng)絡(luò)中通過。例

如，可將H1的數(shù)據(jù)率限定為1Mb/SoR1不停地監(jiān)視

的數(shù)據(jù)率。只要其數(shù)據(jù)率超過規(guī)定的1Mb/s,(就

將其中的某些分組丟棄。

主機(jī)H1和力分別向主機(jī)H3和H4發(fā)送數(shù)據(jù)

?I數(shù)據(jù)率異常的實(shí)時(shí)音頻數(shù)據(jù)IH3

應(yīng)在路由器中再增加調(diào)度(scheduling)機(jī)制。利用調(diào)度

功能給實(shí)時(shí)音頻分配「0Mb/s的帶寬，給文件傳送分

配0.5Mb/s的帶寬(相當(dāng)于在帶寬為1.5Mb/s的鏈路

中劃分出兩個(gè)邏輯鏈路)，因而對這兩種應(yīng)用都有相

應(yīng)的服務(wù)質(zhì)量保證。

主機(jī)H1和力分別向主機(jī)H3和H4發(fā)送數(shù)據(jù)

總數(shù)據(jù)率已超過了1.5Mb/s鏈路的帶寬。比較合理的

做法是讓一個(gè)數(shù)據(jù)流通過1.5Mb/s的鏈路，而阻止另

一個(gè)數(shù)據(jù)流的通過。這就需要呼叫接納(calladmission)

機(jī)制。數(shù)據(jù)流要預(yù)先聲明所需的服務(wù)質(zhì)量，然后或者

被準(zhǔn)許進(jìn)入網(wǎng)絡(luò)，或者被拒絕進(jìn)入網(wǎng)絡(luò)。

8.4.2調(diào)度和管制機(jī)制

1.調(diào)度機(jī)制

■“調(diào)度”就是指排隊(duì)的規(guī)則O

■如不采用專門的調(diào)度機(jī)制，則默認(rèn)排隊(duì)規(guī)則就

是先進(jìn)先出FIFO(FirstInFirstOut)。當(dāng)隊(duì)列

已滿時(shí)，后到達(dá)的分組就被丟棄。

-先進(jìn)先出的最大缺點(diǎn)就是不能區(qū)分時(shí)間敏感分

組和一般數(shù)據(jù)分組，并且也不公平。

■在先進(jìn)先出的基礎(chǔ)上增加按優(yōu)先級(jí)排隊(duì)，就能

使優(yōu)先級(jí)高的分組優(yōu)先得到服務(wù)。

課件制作人：謝希仁

分組按優(yōu)先級(jí)排隊(duì)

路由器

分組離開

路由器

課件制作人：謝希仁

高優(yōu)先級(jí)分組優(yōu)先接受服務(wù)

到達(dá)

接受

服務(wù)

離開

課件制作人：謝希仁

加權(quán)公平排隊(duì)WFQ

>(WeightedFairQueuing)

路由器

分組到達(dá)分組離開

路由器路由器

課件制作人：謝希仁

加權(quán)公平排隊(duì)WFQ

廠分組到達(dá)后就將分組進(jìn)行分類，然后送交與其類

別對應(yīng)的隊(duì)列。隊(duì)列按順序依次將隊(duì)首的分組發(fā)

送到鏈路。遇到隊(duì)列空就跳過去。

■給隊(duì)列，指派一個(gè)權(quán)重叫。隊(duì)列，得到的平均服

務(wù)時(shí)間為叱/Q嗎），這里X嗎.是對所有的非空隊(duì)列

的權(quán)重求和。

■隊(duì)列，將得到的有保證的帶寬用應(yīng)為

7?xw.

R.=----L(8-1)

'Zw.

J

課件制作人：謝希仁

WFQ與FIFO的比較

⑶分組流1的分組連續(xù)輸入

分組流

111111111111

分組流2

課件制作人：謝希仁

WFQ與FIFO的比較

(b)分組流1的分組斷續(xù)輸入

分組流innnnnnnnnnnnnnnnnnnnnn^

分組流22t

分組流1111

FIFO12345678910111111111111t

WFQI1I2I1I3I1I4I1I5I1I6I1I7I1I8I1I9I1|10|1Illi1It

—iI-IIII-I―，jI

課件制作人：謝希仁

2.管制機(jī)制

(1)平均速率網(wǎng)絡(luò)需要控制一個(gè)數(shù)據(jù)流的

平均速率。這里的平均速率是指在一定

的時(shí)間間隔內(nèi)通過的分組數(shù)。

(2)峰值速率峰值速率限制了數(shù)據(jù)流在非

常短的時(shí)間間隔內(nèi)的流量。

(3)突發(fā)長度網(wǎng)絡(luò)也限制在非常短的時(shí)間

間隔內(nèi)連續(xù)注入到網(wǎng)絡(luò)中的分組數(shù)。

課件制作人：謝希仁

漏桶管制器

(leakybucketpolicer)

標(biāo)記注入漏桶的速率為每秒r個(gè)權(quán)標(biāo)

漏桶中最多

年入b個(gè)權(quán)標(biāo)

等待權(quán)標(biāo)

分組到達(dá)―后/金準(zhǔn)許分組進(jìn)入網(wǎng)絡(luò)

Illi~-------?

在任何時(shí)間間隔t內(nèi)準(zhǔn)許進(jìn)入網(wǎng)絡(luò)的分組數(shù)=rt+b

課件制作人：謝希仁

3.漏桶機(jī)制與加權(quán)公平排隊(duì)相結(jié)合

■現(xiàn)假定有〃個(gè)分組流輸入到一個(gè)路由器，復(fù)用后

從一條鏈路輸出。每一個(gè)分組流使用漏桶機(jī)制進(jìn)

行管制，漏桶參數(shù)為，和勺，，=1，2,…，*

■設(shè)漏桶/已裝滿了，個(gè)權(quán)標(biāo)。因此，個(gè)分組可馬

上從路由器輸出。但分組流/得到的帶寬是由公

式(10-1)給出。這，個(gè)分組中的最后一個(gè)分組所經(jīng)

受的時(shí)延最大，它等于傳輸這，個(gè)分組所需的時(shí)

間"max，即，除以公式給出的傳輸速率：

b.

d=----------

max(8-2)

Rxwi./Xwj.

用漏桶機(jī)制進(jìn)行管制

路由器

課件制作人：謝希仁

8.4.3綜合服務(wù)IntServ

與資源預(yù)留協(xié)議RSVP

■IntServ(IntegratedServices)可對單個(gè)的應(yīng)用

會(huì)話提供服務(wù)質(zhì)量的保證，其主要特點(diǎn)有二，

即：

■資源預(yù)留。路由器需要知道不斷出現(xiàn)的會(huì)話已

預(yù)留了多少資源(即鏈路帶寬和緩存空間)。

■呼叫建立。需要服務(wù)質(zhì)量保證的會(huì)話必須首先

在源站到目的站的路徑上的每個(gè)路由器預(yù)留足

夠的資源，以保證其端到端的服務(wù)質(zhì)量要求。

課件制作人：謝希仁

IntServ定義了兩類服務(wù)

■有保證的服務(wù)(guaranteedservice),可保

證一個(gè)分組在通過路由器時(shí)的排隊(duì)時(shí)延有一

個(gè)嚴(yán)格的上限。

■受控負(fù)載的服務(wù)(controlled-loadservice),

可以使應(yīng)用程序得到比通常的“盡最大努力”

更加可靠的服務(wù)。

課件制作人：謝希仁

IntServ由四個(gè)組成部分

⑴資源預(yù)留協(xié)議RSVP,它是IntServ的

信令協(xié)議。

(2)接納控制(admissioncontrol),用來決

定是否同意對某一資源的請求。

(3)分類器(classifier),用來將進(jìn)入路由器

的分組進(jìn)行分類，并根據(jù)分類的結(jié)果將

不同類別的分組放入特定的隊(duì)列。

⑷調(diào)度器(scheduler),根據(jù)服務(wù)質(zhì)量要求

決定分組發(fā)送的前后順序。

課件制作人：謝希仁

流(flow)

?“流”是在多媒體通信中的一個(gè)常用的名

詞，一般定義為：

■具有同樣的源IP地址、源端口號(hào)、目的

IP地址、目的端口號(hào)、協(xié)議標(biāo)識(shí)符以及

服務(wù)質(zhì)量需求的一連串分組。

課件制作人：謝希仁

RSVP協(xié)議的工作原理

.—JjH250kb/s

源站

Hid100kb/s

—?表示PATH報(bào)文

3Mb/s

(a)源點(diǎn)用多播發(fā)送PATH報(bào)文H53Mb/s

50kb/s

100kb/s

3Mb/s

(b)各終點(diǎn)向源點(diǎn)返回RESV3Mb/s

IntServ體系結(jié)構(gòu)

在路由器中的實(shí)現(xiàn)

課件制作人：謝希仁

綜合服務(wù)IntServ體系結(jié)構(gòu)

存在的主要問題

(1)狀態(tài)信息的數(shù)量與流的數(shù)目成正比。因此

在大型網(wǎng)絡(luò)中，按每個(gè)流進(jìn)行資源預(yù)留會(huì)產(chǎn)

生很大的開銷。

(2)IntServ體系結(jié)構(gòu)復(fù)雜。若要得到有保證的

服務(wù)，所有的路由器都必須裝有RSVP、接

納控制、分類器和調(diào)度器。

(3)綜合服務(wù)IntServ所定義的服務(wù)質(zhì)量等級(jí)數(shù)

量太少，不夠靈活。

課件制作人：謝希仁

8.4.4區(qū)分服務(wù)DiffServ

(DifferentiatedServices)

1.區(qū)分服務(wù)的基本概念

■由于綜合服務(wù)IntServ和資源預(yù)留協(xié)議

RSVP都較復(fù)雜，很難在大規(guī)模的網(wǎng)絡(luò)

中實(shí)現(xiàn)，因此IETF提出了新的策略，即

區(qū)分服務(wù)DiffServ。

■區(qū)分服務(wù)有時(shí)也簡寫為DSo因此，具有

區(qū)分服務(wù)功能的結(jié)點(diǎn)就稱為DS結(jié)