計算機網(wǎng)絡（第6版）課件：CH8 音頻視頻

1、計算機網(wǎng)絡（第 6 版） 第 8 章 因特網(wǎng)上的音頻/視頻服務 第 8 章 因特網(wǎng)上的音頻/視頻服務 8.1 概述 8.2 流式存儲音頻/視頻 8.2.1 具有元文件的萬維網(wǎng)服務器 8.2.2 媒體服務器 8.2.3 實時流式協(xié)議 RTSP 8.3 交互式音頻/視頻 8.3.1 IP 電話概述 8.3.2 IP 電話所需要的幾種應用協(xié)議 8.3.3 實時運輸協(xié)議 RTP 8.3.4 實時運輸控制協(xié)議 RTCP 8.3.5 H.323 8.3.6 會話發(fā)起協(xié)議 SIP 第 8 章 因特網(wǎng)上的音頻/視頻服務 （續(xù)） 8.4 改進“盡最大努力交付”的服務 8.4.1 使因特網(wǎng)提供服務質(zhì)量 8.4.2

2、 調(diào)度和管制機制 8.4.3 綜合服務 IntServ 和資源預留 協(xié)議 RSVP 8.4.4 區(qū)分服務 DiffServ 第 8 章 因特網(wǎng)上的音頻/視頻服務 （續(xù)） 8.1 概述 n計算機網(wǎng)絡最初是為傳送數(shù)據(jù)信息設計 的。因特網(wǎng) IP 層提供的“盡最大努力交 付”服務，以及每一個分組獨立交付的 策略，對傳送數(shù)據(jù)信息也是很合適的。 n因特網(wǎng)使用的 TCP 協(xié)議可以很好地解決 網(wǎng)絡不能提供可靠交付這一問題。 多媒體信息的特點 n多媒體信息（包括聲音和圖像信息）與 不包括聲音和圖像的數(shù)據(jù)信息有很大的 區(qū)別。 n多媒體信息的信息量往往很大。 n在傳輸多媒體數(shù)據(jù)時，對時延和時延抖 動均有較高的要求。

3、 n多媒體數(shù)據(jù)往往是實時數(shù)據(jù)(real time data)，它的含義是：在發(fā)送實時數(shù)據(jù)的 同時，在接收端邊接收、邊播放。 因特網(wǎng)是非等時的 n模擬的多媒體信號經(jīng)過采樣和模數(shù)轉(zhuǎn)換變?yōu)閿?shù) 字信號，再組裝成分組。這些分組的發(fā)送速率 是恒定的（等時的）。 n傳統(tǒng)的因特網(wǎng)本身是非等時的。因此經(jīng)過因特 網(wǎng)的分組變成了非恒定速率的分組。 tt 因特網(wǎng) t 模擬信號 t 采樣后的信號 構(gòu)成分組 恒定速率非恒定速率 n接收端需設置適當大小的緩存。當緩存中的分 組數(shù)達到一定的數(shù)量后再以恒定速率按順序把 分組讀出進行還原播放。 n緩存實際上就是一個先進先出的隊列。圖中標 明的 T 叫做播放時延。 在接收端設置緩存

4、 t T 緩存（隊列） 恒定速率 t 非恒定速率 有可能發(fā)生 分組丟失 n緩存使所有到達的分組都經(jīng)受了遲延。 n早到達的分組在緩存中停留的時間較長， 而晚到達的分組在緩存中停留的時間則 較短。 n以非恒定速率到達的分組，經(jīng)過緩存后 再以恒定速率讀出，就能夠在一定程度 上消除了時延的抖動。但我們付出的代 價是增加了時延。 緩存的影響 分組 發(fā)出 1 2 3 4 5 6 t 到達分組數(shù) 6 5 4 3 2 1 1 2 3 4 5 6 t 緩存時間 緩存時間 再推遲播放時間 如果網(wǎng)絡無時延 推遲播放 分組遲到 網(wǎng)絡出現(xiàn)時延 分組 1 的時延 分組 到達 1 2 3 4 5 6 t 實際的網(wǎng)絡 需要解

5、決的問題 n在傳送時延敏感(delay sensitive)的實時 數(shù)據(jù)時，不僅傳輸時延不能太大，而且 時延抖動也必須受到限制。 n對于傳送實時數(shù)據(jù)，很少量分組的丟失 對播放效果的影響并不大（因為這是由 人來進行主觀評價的），因而是可以容 忍的。丟失容忍(loss tolerant)也是實時 數(shù)據(jù)的另一個重要特點。 需要解決的問題（續(xù)） n由于分組的到達可能不按序，但將分組還原和 播放時又應當是按序的。因此在發(fā)送多媒體分 組時還應當給每一個分組加上序號。這表明還 應當有相應的協(xié)議支持才行。 n要使接收端能夠?qū)⒐?jié)目中本來就存在的正常的 短時間停頓（如音樂中停頓幾拍）和因某些分 組的較大遲延造成的

6、“停頓”區(qū)分開來。這就 需要增加一個時間戳(timestamp)，以便告訴接 收端應當在什么時間播放哪個分組。 必須改造現(xiàn)有的因特網(wǎng) n大量使用光纜和高速路由器，網(wǎng)絡的時延和時 延抖動就可以足夠小，在因特網(wǎng)上傳送實時數(shù) 據(jù)就不會有問題。 n把因特網(wǎng)改造為能夠?qū)Χ说蕉说膸拰崿F(xiàn)預留 (reservation)，把使用無連接協(xié)議的因特網(wǎng)轉(zhuǎn) 變?yōu)槊嫦蜻B接的網(wǎng)絡。 n部分改動因特網(wǎng)的協(xié)議棧所付出的代價較小， 而這也能夠使多媒體信息在因特網(wǎng)上的傳輸質(zhì) 量得到改進。 目前因特網(wǎng)提供的音頻/視頻服務 大體上可分為三種類型 n流式(streaming)存儲音頻/視頻 邊下 載邊播放。 n流式實況音頻/視頻 邊

7、錄制邊發(fā)送 。 n交互式音頻/視頻實時交互式通信。 “邊下載邊播放”中的“下載” n“邊下載邊播放”結(jié)束后，在用戶的硬盤上沒有 留下有關(guān)播放內(nèi)容的任何痕跡。 n流媒體(streaming media)，即流式音頻/視頻。 n流媒體特點就是“邊下載邊播放” (streaming and playing) 。 8.2 流式存儲音頻/視頻 n傳統(tǒng)的下載文件方法 萬維網(wǎng) 服務器 客戶機 服務器 媒體 播放器 GET: 音頻/視頻文件 RESPONSE 音頻/視頻文件 瀏覽器 傳統(tǒng)的瀏覽器從服務器 下載音頻/視頻文件 用戶從客戶機(client machine)的瀏覽器上用 HTTP 協(xié)議向服務器請求下

8、載某個音頻/視頻文 件。 服務器如有此文件就發(fā)送給瀏覽器。在響應報 文中就裝有用戶所要的音頻/視頻文件。整個下 載過程可能會花費很長的時間。 當瀏覽器完全收下這個文件后，就可以傳送給 自己機器上的媒體播放器進行解壓縮，然后播 放。 8.2.1 具有元文件的萬維網(wǎng)服務器 n元文件就是一種非常小的文件，它描述或指明其他文 件的一些重要信息。 萬維網(wǎng) 服務器 客戶機 服務器 媒體 播放器 元文件 瀏覽器 GET: 元文件 RESPONSE GET: 音頻/視頻文件 RESPONSE 使用元文件下載音頻/視頻文件 瀏覽器用戶使用 HTTP 的 GET 報文接入到萬維網(wǎng)服 務器。這個超鏈指向一個元文件。

9、這個元文件有實際 的音頻/視頻文件的統(tǒng)一資源定位符 URL。 萬維網(wǎng)服務器把該元文件裝入 HTTP 響應報文的主體， 發(fā)回給瀏覽器。 客戶機瀏覽器調(diào)用相關(guān)的媒體播放器，把提取出的元 文件傳送給媒體播放器。 媒體播放器使用元文件中的 URL ，向萬維網(wǎng)服務器發(fā) 送 HTTP 請求報文，要求下載音頻/視頻文件。 萬維網(wǎng)服務器發(fā)送 HTTP 響應報文，把該音頻/視頻文 件發(fā)送給媒體播放器。媒體播放器邊下載邊解壓縮邊 播放。 8.2.2 媒體服務器 n媒體服務器也稱為流式服務器(streaming server) ，它支持流式音頻和視頻的傳送。 n媒體播放器與媒體服務器的關(guān)系是客戶與服務 器的關(guān)系。

10、n媒體播放器不是向萬維網(wǎng)服務器而是向媒體服 務器請求音頻/視頻文件。 n媒體服務器和媒體播放器之間采用另外的協(xié)議 進行交互。 使用媒體服務器 萬維網(wǎng) 服務器 媒體 播放器 元文件 瀏覽器 GET: 元文件 RESPONSE GET: 音頻/視頻文件 RESPONSE 媒體 服務器 客戶機服務器 采用媒體服務器 下載音頻/視頻文件的步驟 前三個步驟仍然和上一節(jié)的一樣，區(qū)別就 是后面兩個步驟。 媒體播放器使用元文件中的 URL 接入到媒體 服務器，請求下載瀏覽器所請求的音頻/視頻文 件。下載可以借助于使用 UDP 的任何協(xié)議， 例如使用實時運輸協(xié)議 RTP。 媒體服務器給出響應，把該音頻/視頻文件

11、發(fā) 送給媒體播放器。媒體播放器在遲延了若干秒 后，以流的形式邊下載邊解壓縮邊播放。 8.2.3 實時流式協(xié)議 RTSP (Real-Time Streaming Protocol) nRTSP 協(xié)議以客戶服務器方式工作，它是一個 多媒體播放控制協(xié)議，用來使用戶在播放從因 特網(wǎng)下載的實時數(shù)據(jù)時能夠進行控制，如：暫 停/繼續(xù)、后退、前進等。因此 RTSP 又稱為 “因特網(wǎng)錄像機遙控協(xié)議”。 n要實現(xiàn) RTSP 的控制功能，我們不僅要有協(xié)議， 而且要有專門的媒體播放器(media player)和 媒體服務器(media server)。 萬維網(wǎng) 服務器 客戶機服務器 媒體 播放器 元文件 瀏覽器

12、媒體 服務器 GET: 元文件 RESPONSE SETUP RESPONSE PLAY RESPONSE RESPONSE TEARDOWN 使用 RTSP 的媒體服務器 的工作過程 瀏覽器向萬維網(wǎng)服務器請求音頻/視頻文件。 萬維網(wǎng)服務器從瀏覽器發(fā)送攜帶有元文件的響應。 瀏覽器把收到的元文件傳送給媒體播放器。 RTSP 客戶與媒體服務器的 RTSP 服務器建立連接。 RTSP 服務器發(fā)送響應 RESPONSE 報文。 RTSP 客戶發(fā)送 PLAY 報文，開始下載音頻/視頻文件。 RTSP 服務器發(fā)送響應 RESPONSE 報文。 RTSP 客戶發(fā)送 TEARDOWN 報文斷開連接。 RTSP

13、 服務器發(fā)送響應 RESPONSE 報文。 8.3 交互式音頻/視頻 8.3.1 IP 電話概述 n狹義的 IP 電話就是指在 IP 網(wǎng)絡上打電話。 所謂“IP 網(wǎng)絡”就是“使用 IP 協(xié)議的分組 交換網(wǎng)”的簡稱。 n廣義的 IP 電話則不僅僅是電話通信，而且 還可以是在IP網(wǎng)絡上進行交互式多媒體實 時通信（包括話音、視像等），甚至還包 括即時傳信IM (Instant Messaging)。 IP 電話網(wǎng)關(guān)的幾種連接方法 分組交換電路交換 電路交換 因特網(wǎng) PC 到 PC 公用電話網(wǎng) IP 電話 網(wǎng)關(guān) 因特網(wǎng) PC 到固定電話機 公用電話網(wǎng) IP 電話 網(wǎng)關(guān)公用電話網(wǎng) IP 電話 網(wǎng)關(guān) 因特

14、網(wǎng) 固定電話機到固定電話機 IP 電話的通話質(zhì)量 nIP 電話的通話質(zhì)量主要由兩個因素決定。 一個是通話雙方端到端的時延和時延抖 動，另一個是話音分組的丟失率。但這 兩個因素是不確定的，是取決于當時網(wǎng) 絡上的通信量。 n經(jīng)驗證明，在電話交談中，端到端的時 延不應超過 250 ms，否則交談者就能感 到不自然。 IP 電話的端到端時延 (1) 話音信號進行模數(shù)轉(zhuǎn)換要經(jīng)受時延。 (2) 話音比特流裝配成話音分組的時延。 (3) 話音分組的發(fā)送需要時間，此時間等于話音分 組長度與通信線路的數(shù)據(jù)率之比。 (4) 話音分組在因特網(wǎng)中的存儲轉(zhuǎn)發(fā)時延。 (5) 話音分組在接收端緩存中暫存所引起的時延。 (6

15、) 話音分組還原成模擬話音信號的時延。 (7) 話音信號在通信線路上的傳播時延。 (8) 終端設備的硬件和操作系統(tǒng)產(chǎn)生的接入時延。 低速率話音編碼的標準 (1) G.729速率為 8 kb/s 的共軛結(jié)構(gòu)代 數(shù)碼激勵線性預測聲碼器 CS-ACELP (Conjugate-Structure Algebraic-Code- Excited Linear Prediction)。 (2) G.723.1速率為 5.3/6.3 kb/s 的為多 媒體通信用的低速率聲碼器。 D 播放時延有一個最佳值 分組 丟失率 端到端時延 20 % 10 % 5 % 100 ms 150 ms400 ms A B

16、C N 良好 基本 可用 不好 長途電話 質(zhì)量 接收端播放 時延增大 線速路由器 n提高路由器的轉(zhuǎn)發(fā)分組的速率對提高 IP 電話的質(zhì)量也是很重要的。 n據(jù)統(tǒng)計，一個跨大西洋的 IP 電話一般要 經(jīng)過 2030 個路由器。 n若能改用吉比特路由器（又稱為線速路 由器），則每秒可轉(zhuǎn)發(fā) 5 百萬至 6 千萬 個分組（即交換速率達 60 Gb/s 左右）。 這樣還可進一步減少由網(wǎng)絡造成的時延。 關(guān)于 Skype nSkype 采用了 P2P 和全球索引技術(shù)提供快速路由選擇 機制，管理成本大大降低。由于用戶路由信息分布式 存儲于因特網(wǎng)的結(jié)點中，因此呼叫連接完成得很快。 nSkype 采用了端對端加密方式

17、，保證信息的安全性。 nSkype 使用 P2P 的技術(shù)，用戶數(shù)據(jù)主要存儲在 P2P 網(wǎng)絡中，因此必須保證存儲在公共網(wǎng)絡中的數(shù)據(jù)是可 靠的和沒有被篡改的。Skype 對公共目錄中存儲的和 用戶相關(guān)的數(shù)據(jù)都采用了數(shù)字簽名，保證了數(shù)據(jù)無法 被篡改。 nSkype的問世給全球信息技術(shù)和通信產(chǎn)業(yè)帶來深遠的 影響，也給每一位網(wǎng)絡使用者帶來生活方式的改變。 8.3.2 IP電話所需要的幾種應用協(xié)議 TCPUDP 信令 服務質(zhì)量 IPv4/IPv6 RTSPRTCPRSVPH.323SIPRTP 應 用 層 協(xié) 議 音頻/視頻 SDP 底層網(wǎng)絡 8.3.3 實時運輸協(xié)議 RTP (Real-time Tra

18、nsport Protocol) nRTP 為實時應用提供端到端的運輸，但不提供任 何服務質(zhì)量的保證。 n多媒體數(shù)據(jù)塊經(jīng)壓縮編碼處理后，先送給 RTP 封 裝成為 RTP 分組，再裝入運輸層的 UDP 用戶數(shù) 據(jù)報，然后再交給 IP 層。 nRTP 是一個協(xié)議框架，只包含了實時應用的一些 共同的功能。 nRTP 自己并不對多媒體數(shù)據(jù)塊做任何處理，而只 是向應用層提供一些附加的信息，讓應用層知道 應當如何進行處理。 RTP 的層次 n從應用開發(fā)者的角度看，RTP 應當是應 用層的一部分。 n在應用的發(fā)送端，開發(fā)者必須編寫用 RTP 封裝分組的程序代碼，然后把 RTP 分組交給 UDP 插口接口。

19、 n在接收端，RTP 分組通過 UDP 插口接口 進入應用層后，還要利用開發(fā)者編寫的程 序代碼從 RTP 分組中把應用數(shù)據(jù)塊提取 出來。 RTP 也可看成是 運輸層的一個子層 nRTP 封裝了多媒體應用的 數(shù)據(jù)塊。由于 RTP 向多 媒體應用程序提供了服務 （如時間戳和序號），因 此也可以將 RTP 看成是 在 UDP 之上的一個運輸 層的子層。 運輸層 應用層 IP 數(shù)據(jù)鏈路層 物理層 RTP UDP RTP 分組的首部格式 12 字節(jié) 序 號 位 0 1 3 8 16 31 有效載荷類型版本 P XM參與源數(shù) 時 間 戳 同 步 源 標 識 符 (SSRC) 參 與 源 標 識 符 (CS

20、RC) 0.15 發(fā)送 RTP 分組 UDP 用戶數(shù)據(jù)報 IP 數(shù)據(jù)報 IP 首部 UDP 首部 RTP 首部 RTP 數(shù)據(jù)部分（應用層數(shù)據(jù)） 8.3.4 實時運輸控制協(xié)議 RTCP (RTP Control Protocol) nRTCP 是與 RTP 配合使用的協(xié)議。 nRTCP 協(xié)議的主要功能是：服務質(zhì)量的監(jiān)視與反 饋、媒體間的同步，以及多播組中成員的標識。 nRTCP 分組也使用 UDP 傳送，但 RTCP 并不對 聲音或視像分組進行封裝。 n可將多個 RTCP 分組封裝在一個 UDP 用戶數(shù)據(jù) 報中。 nRTCP 分組周期性地在網(wǎng)上傳送，它帶有發(fā)送端 和接收端對服務質(zhì)量的統(tǒng)計信息報告

21、。 RTCP 使用的五種分組類型 n結(jié)束分組 BYE 表示關(guān)閉一個數(shù)據(jù)流。 n特定應用分組 APP 使應用程序能夠定義新的分 組類型。 n接收端報告分組 RR 用來使接收端周期性地向 所有的點用多播方式進行報告。 n發(fā)送端報告分組 SR 用來使發(fā)送端周期性地向所 有接收端用多播方式進行報告。 n源點描述分組 SDES 給出會話中參加者的描述。 8.3.5 H.323 nH.323 是 ITU-T 于 1996 年制訂的一個名稱很長 的建議書，1998 年的第二個版本改用的名稱是 “基于分組的多媒體通信系統(tǒng)”。 nH.323 包括系統(tǒng)和構(gòu)件的描述，呼叫模型的描述， 呼叫信令過程，控制報文，復用，

22、話音編解碼 器，視像編解碼器，以及數(shù)據(jù)協(xié)議等，但不保 證服務質(zhì)量 QoS。 H.323 終端使用 H.323 協(xié)議 進行多媒體通信 分組交換網(wǎng) （例如，因特網(wǎng)） H.323 H.323 終端H.323 終端 H.323 標準指明的四種構(gòu)件 (1) H.323 終端 (2) 網(wǎng)關(guān)網(wǎng)關(guān)連接到兩種不同的網(wǎng)絡，使 H.323 網(wǎng)絡可以和非 H.323 網(wǎng)絡進行通信。 (3) 網(wǎng)閘(gatekeeper)所有的呼叫都要通過網(wǎng)閘， 因為網(wǎng)閘提供地址轉(zhuǎn)換、授權(quán)、帶寬管理和計費功 能。 (4) 多點控制單元 MCU (Multipoint Control Unit) MCU 支持三個或更多的 H.323 終端

23、的音頻或視頻 會議。 H.323 網(wǎng)關(guān)用來和 非 H.323 網(wǎng)絡進行連接 因特網(wǎng) 公用電話網(wǎng) 網(wǎng)關(guān) 網(wǎng)閘 H.323 終端 多點控制單元 MCU H.323 的協(xié)議體系結(jié)構(gòu) 音頻/視頻應用 音頻 編解碼 視頻 編解碼 RTCP H.225.0 登記 信令 H.225.0 呼叫 信令 H.245 控制 信令 RTP UDPTCP IP 信令和控制數(shù)據(jù) 應用 T.120 數(shù)據(jù) 8.3.6 會話發(fā)起協(xié)議 SIP (Session Initiation Protocol) nSIP 是一套較為簡單且實用的標準，目前已成 為因特網(wǎng)的建議標準。 nSIP 協(xié)議以因特網(wǎng)為基礎，把 IP 電話視為因特 網(wǎng)上

24、的新應用。 nSIP 協(xié)議只涉及到 IP 電話的信令和有關(guān)服務質(zhì) 量問題，而沒有提供像H.323那樣多的功能。 nSIP沒有指定使用 RTP 協(xié)議，但實際上大家還 是選用 RTP 和 RTCP 作為配合使用的協(xié)議。 SIP 系統(tǒng)的構(gòu)件 nSIP系統(tǒng)的兩種構(gòu)件是用戶代理和網(wǎng)絡服務器。 n用戶代理包括用戶代理客戶和用戶代理服務器， 前者用來發(fā)起呼叫，而后者用來接受呼叫。 n網(wǎng)絡服務器分為代理服務器和重定向服務器。 n代理服務器接受來自主叫用戶的呼叫請求，并將 其轉(zhuǎn)發(fā)給下一跳代理服務器，最后將呼叫請求轉(zhuǎn) 發(fā)給被叫用戶。 n重定向服務器不接受呼叫，它通過響應告訴客戶 下一跳代理服務器的地址，由客戶按此

25、地址向下 一跳代理服務器重新發(fā)送呼叫請求。 SIP 的地址十分靈活 n可以是電話號碼，也可以是電子郵件地 址、IP 地址或其他類型的地址。但一定 要使用 SIP 的地址格式，例如： n電話號碼 sip:zhangsan8625-87654321 nIPv4 地址 sip:zhangsan6 n電子郵件地址 sip: 一個簡單的 SIP 會話 主叫方被叫方 OK: 地址 ACK INVITE: 地址，選項 建立 會話 BYE終止 會話 電話交談 通信 tt SIP 登記器的用途 跟蹤被叫方 主叫方被叫方 INVITE 查找 回答 電話交談 tt SIP 代理 服務器SIP

26、登記器 INVITE OK OK ACK ACK BYE t t 會話描述協(xié)議SDP (Session Description Protocol) nSDP 在電話會議的情況下特別重要，因為電話 會議的參加者是動態(tài)地加入和退出。 nSDP 詳細地指明了媒體編碼、協(xié)議的端口號以 及多播地址。 nSIP 使用了 HTTP 的許多首部、編碼規(guī)則、差 錯碼以及一些鑒別機制，它比 H.323 具有更好 的可擴縮性。 n由于 SIP 問世較晚，因此它現(xiàn)在比 H.323 占有 的市場份額要小。 8.4 改進“盡最大努力交付”的服 務 8.4.1 使因特網(wǎng)提供服務質(zhì)量 n服務質(zhì)量 QoS 是服務性能的總效果，

27、此效果決 定了一個用戶對服務的滿意程度。因此在最簡 單的意義上，有服務質(zhì)量的服務就是能夠滿足 用戶的應用需求的服務。 n服務質(zhì)量可用若干基本的性能指標來描述，包 括可用性、差錯率、響應時間、吞吐量、分組 丟失率、連接建立時間、故障檢測和改正時間 等。服務提供者可向其用戶保證某一種等級的 服務質(zhì)量。 主機 H1 和 H2 分別向主機 H3 和 H4 發(fā)送數(shù)據(jù) 1.5 Mb/s 鏈路 H1 H2 H3 H4 R2R1 H1 H2 1.5 Mb/s 鏈路 輸出隊列 1 Mb/s的實時音頻數(shù)據(jù) FTP 文件數(shù)據(jù) 需要給不同性質(zhì)的分組打上不同的標記。當 H1 和 H2 的 分組進入 R1 時， R1 應

28、能識別實時數(shù)據(jù)分組，并使這些 分組以高優(yōu)先級進入輸出隊列，而僅在隊列有多余空間 時才準許低優(yōu)先級的 FTP 數(shù)據(jù)分組進入。 主機 H1 和 H2 分別向主機 H3 和 H4 發(fā)送數(shù)據(jù) 1.5 Mb/s 鏈路 H1 H2 H3 H4 R2R1 H1 H2 1.5 Mb/s 鏈路 輸出隊列 1 Mb/s的實時音頻數(shù)據(jù) 高優(yōu)先級的 FTP 文件數(shù)據(jù) 應當使路由器增加分類(classification)機制，即路由器 根據(jù)某些準則（例如，根據(jù)發(fā)送數(shù)據(jù)的地址）對輸入分 組進行分類，然后對不同類別的通信量給予不同的優(yōu)先 級。 主機 H1 和 H2 分別向主機 H3 和 H4 發(fā)送數(shù)據(jù) 1.5 Mb/s 鏈

29、路 H1 H2 H3 H4 R2R1 H1 H2 1.5 Mb/s 鏈路 輸出隊列 數(shù)據(jù)率異常的實時音頻數(shù)據(jù) FTP 文件數(shù)據(jù) 路由器應能將對數(shù)據(jù)流進行通信量的管制(policing)， 使該數(shù)據(jù)流不影響其他正常數(shù)據(jù)流在網(wǎng)絡中通過。例 如，可將 H1 的數(shù)據(jù)率限定為 1 Mb/s。R1 不停地監(jiān)視 H1 的數(shù)據(jù)率。只要其數(shù)據(jù)率超過規(guī)定的 1 Mb/s，R1 就 將其中的某些分組丟棄。 主機 H1 和 H2 分別向主機 H3 和 H4 發(fā)送數(shù)據(jù) 1.5 Mb/s 鏈路 H1 H2 H3 H4 R2R1 H1 H2 1.5 Mb/s 鏈路 輸出隊列 數(shù)據(jù)率異常的實時音頻數(shù)據(jù) FTP 文件數(shù)據(jù) 應在

30、路由器中再增加調(diào)度(scheduling)機制。利用調(diào)度 功能給實時音頻分配 1.0 Mb/s 的帶寬，給文件傳送分 配 0.5 Mb/s 的帶寬（相當于在帶寬為 1.5 Mb/s 的鏈路 中劃分出兩個邏輯鏈路），因而對這兩種應用都有相 應的服務質(zhì)量保證。 主機 H1 和 H2 分別向主機 H3 和 H4 發(fā)送數(shù)據(jù) 1.5 Mb/s 鏈路 H1 H2 H3 H4 R2R1 H1 H2 1.5 Mb/s 鏈路 輸出隊列 1 Mb/s 的實時數(shù)據(jù) 總數(shù)據(jù)率已超過了 1.5 Mb/s 鏈路的帶寬。比較合理的 做法是讓一個數(shù)據(jù)流通過 1.5 Mb/s 的鏈路，而阻止另 一個數(shù)據(jù)流的通過。這就需要呼叫接

31、納(call admission) 機制。數(shù)據(jù)流要預先聲明所需的服務質(zhì)量，然后或者 被準許進入網(wǎng)絡，或者被拒絕進入網(wǎng)絡。 8.4.2 調(diào)度和管制機制 1. 調(diào)度機制 n“調(diào)度”就是指排隊的規(guī)則。 n如不采用專門的調(diào)度機制，則默認排隊規(guī)則就 是先進先出 FIFO (First In First Out)。當隊列 已滿時，后到達的分組就被丟棄。 n先進先出的最大缺點就是不能區(qū)分時間敏感分 組和一般數(shù)據(jù)分組，并且也不公平。 n在先進先出的基礎上增加按優(yōu)先級排隊，就能 使優(yōu)先級高的分組優(yōu)先得到服務。 分組按優(yōu)先級排隊 高優(yōu)先級隊列 低優(yōu)先級隊列 分組到達 路由器 調(diào)度 分組離開 路由器 分類器 （服務

32、員） 路由器 高 高 高 低 高優(yōu)先級分組優(yōu)先接受服務 t 1235 到達 離開 接受 服務 4 13254 13254 t 高高高低低 分組離開 路由器 加權(quán)公平排隊 WFQ (Weighted Fair Queuing) 分組到達 路由器 調(diào)度 分類器 w1 w2 w3 1 2 3 路由器 加權(quán)公平排隊 WFQ n分組到達后就將分組進行分類，然后送交與其類 別對應的隊列。隊列按順序依次將隊首的分組發(fā) 送到鏈路。遇到隊列空就跳過去。 n給隊列 i 指派一個權(quán)重 wi。隊列 i 得到的平均服 務時間為 wi /(wj)，這里wj 是對所有的非空隊列 的權(quán)重求和。 n隊列 i 將得到的有保證的帶

33、寬 Ri 應為 （8-1） j i i w wR R WFQ 與 FIFO 的比較 11111111111 2 11 123456789 10 11 1 111111111123456789 10 11 1 111111111 分組流 1 分組流 2 分組流 11 FIFO WFQ (a) 分組流 1 的分組連續(xù)輸入 t t t t t WFQ 與 FIFO 的比較 11111111111 2 11 123456789 10 11 1 1111111111234567891011 1 111111111 分組流 1 分組流 2 分組流 11 FIFO WFQ t t t t t (b) 分組流

34、 1 的分組斷續(xù)輸入 2. 管制機制 (1) 平均速率 網(wǎng)絡需要控制一個數(shù)據(jù)流的 平均速率。這里的平均速率是指在一定 的時間間隔內(nèi)通過的分組數(shù)。 (2) 峰值速率 峰值速率限制了數(shù)據(jù)流在非 常短的時間間隔內(nèi)的流量。 (3) 突發(fā)長度 網(wǎng)絡也限制在非常短的時間 間隔內(nèi)連續(xù)注入到網(wǎng)絡中的分組數(shù)。 分組到達 漏桶管制器 (leaky bucket policer) 漏桶中最多 裝入 b 個權(quán)標 拿走 權(quán)標 準許分組進入網(wǎng)絡 等待權(quán)標 在任何時間間隔 t 內(nèi)準許進入網(wǎng)絡的分組數(shù) = r t + b 標記注入漏桶的速率為每秒 r 個權(quán)標 3.漏桶機制與加權(quán)公平排隊相結(jié)合 n現(xiàn)假定有 n 個分組流輸入到一

35、個路由器，復用后 從一條鏈路輸出。每一個分組流使用漏桶機制進 行管制，漏桶參數(shù)為 bi 和 ri，i = 1, 2, , n。 n設漏桶 I 已裝滿了 bi 個權(quán)標。因此 bi 個分組可馬 上從路由器輸出。但分組流 I 得到的帶寬是由公 式(10-1)給出。這 bi 個分組中的最后一個分組所經(jīng) 受的時延最大，它等于傳輸這 bi 個分組所需的時 間 dmax，即 bi 除以公式(10-1)給出的傳輸速率： ji i wwR b d / max (8-2) 分組離開 路由器 分組到達 路由器 用漏桶機制進行管制 調(diào)度 分類器 w1 wn 隊列 1 b1 r1 bn rn 隊列 n 路由器 8.4.

36、3 綜合服務 IntServ 與資源預留協(xié)議 RSVP nIntServ (Integrated Services)可對單個的應用 會話提供服務質(zhì)量的保證，其主要特點有二， 即： n資源預留。路由器需要知道不斷出現(xiàn)的會話已 預留了多少資源（即鏈路帶寬和緩存空間）。 n呼叫建立。需要服務質(zhì)量保證的會話必須首先 在源站到目的站的路徑上的每個路由器預留足 夠的資源，以保證其端到端的服務質(zhì)量要求。 IntServ 定義了兩類服務 n有保證的服務(guaranteed service)，可保 證一個分組在通過路由器時的排隊時延有一 個嚴格的上限。 n受控負載的服務(controlled-load ser

37、vice)， 可以使應用程序得到比通常的“盡最大努力” 更加可靠的服務。 IntServ 由四個組成部分 (1) 資源預留協(xié)議 RSVP，它是 IntServ 的 信令協(xié)議。 (2) 接納控制(admission control)，用來決 定是否同意對某一資源的請求。 (3) 分類器(classifier)，用來將進入路由器 的分組進行分類，并根據(jù)分類的結(jié)果將 不同類別的分組放入特定的隊列。 (4) 調(diào)度器(scheduler)，根據(jù)服務質(zhì)量要求 決定分組發(fā)送的前后順序。 流(flow) n“流”是在多媒體通信中的一個常用的名 詞，一般定義為: n具有同樣的源 IP 地址、源端口號、目的 IP

38、 地址、目的端口號、協(xié)議標識符以及 服務質(zhì)量需求的一連串分組。 RSVP 協(xié)議的工作原理 H1 H2 50 kb/s R2R1 H3 100 kb/s H4 3 Mb/s R3 R4 H5 3 Mb/s 源站 (a) 源點用多播發(fā)送PATH報文 表示 PATH 報文 3 Mb/s3 Mb/s 3 Mb/s 100 kb/s H1 H2 50 kb/s R2R1 H3 100 kb/s H4 3 Mb/s R3 R4 H5 3 Mb/s 源站 (b) 各終點向源點返回 RESV 報文 表示 RESV 報文 IntServ 體系結(jié)構(gòu) 在路由器中的實現(xiàn) 路由選擇協(xié)議 路由選擇數(shù)據(jù)庫 RSVP接納控制

39、管理代理 通信量控制 數(shù)據(jù)庫 分類器 與 分組轉(zhuǎn)發(fā) 調(diào)度器 分組入 分組出 綜合服務 IntServ 體系結(jié)構(gòu) 存在的主要問題 (1) 狀態(tài)信息的數(shù)量與流的數(shù)目成正比。因此 在大型網(wǎng)絡中，按每個流進行資源預留會產(chǎn) 生很大的開銷。 (2) IntServ 體系結(jié)構(gòu)復雜。若要得到有保證的 服務，所有的路由器都必須裝有 RSVP、接 納控制、分類器和調(diào)度器。 (3) 綜合服務 IntServ 所定義的服務質(zhì)量等級數(shù) 量太少，不夠靈活。 8.4.4 區(qū)分服務 DiffServ (Differentiated Services) 1. 區(qū)分服務的基本概念 n由于綜合服務 IntServ 和資源預留協(xié)議 RSVP 都較復雜，很難在大規(guī)模的網(wǎng)絡 中實現(xiàn)，因此 IETF 提出了新的策略，即 區(qū)分服務 DiffServ 。 n區(qū)分服務有時也簡寫為 DS。因此，具有 區(qū)分服務功能的結(jié)點就稱為 DS 結(jié)點。 區(qū)分服務 DiffServ 的要點 (1) DiffServ 在路由器中增加區(qū)分服務的功能。 nDiffServ 將 IPv4 協(xié)議中原有的服務類型字段和 IPv6 的通信量