第8章 互聯網上的音頻/視頻服務

8.1概述

📝 多媒體信息： 包括聲音和圖像信息

多媒體信息最主要的兩個特點：

• 第一，多媒體信息的信息量往往很大。
• 第二，在傳輸多媒體數據【邊傳輸邊播放】時，對時延和時延抖動均有較高的要求。

📌 抖動的核心概念

1. 等時 vs. 非等時
   對模擬信號要經過采樣和模數轉換變為數字信號，然后將一定數量的比特組裝成分組進行傳送。

   • 等時（Isochronous）：發送端按嚴格固定間隔發送分組（如數字音頻、視頻流）。
   • 非等時（Anisochronous）：分組在網絡中因擁塞、路由變化、排隊延遲等因素，到達時間不可預測（傳統IP網絡的特性）。

   

   分組：

   • 由于分組的到達可能不按序，但將分組還原和播放時又應當是按序的。因此在發送多媒體分組時應當給每一個分組加上序號。
   • 在每一個分組增加一個時間戳(timestamp)，讓接收端知道所收到的每一個分組是在什么時間產生的。

2. 抖動（Jitter）

   是指在數據傳輸過程中，分組到達接收端的時間間隔不穩定，導致數據流不均勻或不規則的現象。

3. 抖動的表現

   • 延遲變化（Delay Variation）：比如，第一個數據包耗時 20ms，第二個 50ms，第三個 10ms → 抖動發生。

   • 數據堆積或斷續：導致音頻卡頓、視頻跳幀、實時通話不連貫。

   • 例如：

     理想情況：|--A--|--B--|--C--|（等時到達）
     實際情況：|---A---|C|--B----|（抖動導致亂序+延遲不均）
     

📊 抖動的影響

場景	抖動的影響
實時音視頻（VoIP/直播）	聲音斷續、畫面卡頓
網絡游戲	操作延遲、卡頓
金融交易系統	數據不同步，影響決策

📚 抖動問題的解決

在接收端設置適當大小的緩存【先進先出的隊列】"，當緩存中的分組數達到一定的數量后再以恒定速率按順序將這些分組讀出進行還原播放。【消除了時延的抖動，但付出的代價是增加了時延。】

非等時 => 等時：

緩存使所有到達的分組都經受了遲延。由于分組以非恒定速率到達，因此早到達的分組在緩存中停留的時間較長，而晚到達的分組在緩存中停留的時間就較短。從緩存中取出分組是按照固定的時鐘節拍進行的，因此，到達的非等時的分組，經過緩存后再以恒定速率讀出，就變成了等時的分組

💻 傳輸實時數據特點：

丟失容忍(loss tolerant)：寧可丟失少量分組(不能丟失太多)，也不要太晚到達的分組。【在連續的音頻或視頻數據流中，很少量分組的丟失對播放效果的影響并不大(因為這是由人來進行主觀評價的)，因而是可以容忍的。】

?? 目前互聯網提供的音頻/視頻服務大體上可分為三種類型:

流媒體(streaming media)：流式音頻/視頻

• 流式(streaming)存儲音頻/視頻
  • 先把已壓縮的錄制好的音頻/視頻文件(如音樂、電影等)存儲在服務器上。用戶通過互聯網下載這樣的文件。但用戶并不是把文件全部下載完畢后再播放，而是能夠邊下載邊播放，即在文件下載后不久(例如，一般在緩存中存放最多幾十秒)就開始連續播放。
  • 特點：
    ? 內容預先錄制并存儲在服務器（如MP4文件）。
    ? 采用漸進式下載或自適應流媒體（如HLS/DASH）。
    ? 允許暫停、快進、緩沖，容忍較高延遲。
  • 例子：愛奇藝/騰訊視頻/Netflix 等
• 流式實況音頻/視頻
  • 是一對多(而不是一對一)的通信。它的特點是:音頻/視頻節目不是事先錄制好和存儲在服務器中的，而是在發送方邊錄制邊發送(不是錄制完畢后再發送)。在接收時也要求能夠連續播放。接收方收到節目的時間和節目中事件的發生時間可以認為是同時的(相差僅僅是電磁波的傳播時間和很短的信號處理時間)。流式實況音頻/視頻按理說應當采用多播技術才能提高網絡資源的利用率，但目前實際上還是使用多個獨立的單播。
  • 特點：
    ? 內容實時采集并廣播，無存儲回放（或短暫延遲）。
    ? 需要低延遲。
    ? 可能使用UDP + 協議優化（如RTMP、WebRTC）。
  • 例子：抖音直播/快手直播 等
• 交互式音頻/視頻
  • 用戶使用互聯網和其他人進行實時交互式通信。例如：互聯網電話或互聯網電視會議。
  • 特點：
    ? 端到端實時雙向通信，延遲極低。
    ? 嚴格抗抖動和丟包（如FEC、抖動緩沖）。
    ? 通常基于UDP + RTP/RTCP或WebRTC。
  • 例子：微信語音/視頻通話、騰訊會議 等

特性	流式存儲	流式實況	交互式
內容來源	預存文件	實時采集	實時雙向傳輸
延遲要求	高容忍（秒級）	中低（秒級）	極低（毫秒級）
協議典型用例	HTTP/HLS/DASH	RTMP/WebRTC	WebRTC/RTP
用戶控制	可暫停/跳轉	僅觀看（無回放）	實時交互
抗抖動技術	大緩沖區	CDN + 小緩沖	動態抖動緩沖

8.2 流式存儲音頻/視頻

媒體播放器(media player)：一個用來【播放音頻/視頻節目】的【單獨】的【應用程序】。

媒體播放器具有的主要功能：管理用戶界面、解壓縮、消除時延抖動和處理傳輸帶來的差錯。

8.2.1 具有元文件的萬維網服務器

元文件(meta file)：是一種非常小的文件，描述或指明其他文件的一些重要信息。這里的元文件保存了有關這個音頻/視頻文件的信息。

8.2.2 媒體服務器

媒體服務器：是專門為播放流式音頻/視頻文件而設計的，常被稱為流式服務器(streaming server)。

傳送音頻/視頻文件可以使用TCP，也可以使用UDP。觀看實況轉播，最好首先考慮使用UDP來傳送。

采用UDP 會有以下幾個缺點：

• 發送端按正常播放的速率發送流媒體數據幀，但由于網絡的情況多變，在接收端的播放器很難做到始終按規定的速率播放。
• 很多單位的防火墻往往阻攔外部UDP分組的進入，因而使用UDP傳送多媒體文件時會被防火墻阻攔掉。
• 如果在用戶端希望能夠控制媒體的播放，如進行暫停、快進等操作，則還需要使用另外的協議RTP和RTSP。增加了成本和復雜性。

YouTube 和Netflix，都 采用 TCP 來傳送，主要步驟：

• 如果用戶暫停播放，那么圖中的三個緩存將很快被填滿，這時TCP發送緩存就暫停讀取所要傳送的視頻文件，否則就會引起視頻數據的丟失。
• 當用戶繼續播放時，媒體播放器每讀出n bit，TCP發送緩存就可以從存儲的視頻文件再讀取n bit。如果客戶機中的兩個緩存經常處于填滿狀態，就能夠較好地應付網絡中偶然出現的擁塞。
• 如果步驟②的傳送速率小于步驟④的讀出速率，那么客戶機中的兩個緩存中的存量就會逐漸減少。當媒體播放器緩存的數據被取空后，播放就不得不暫停，直到后續的視頻數據重新注入進來后才能再繼續播放。

8.2.3 實時流式協議 RTSP

實時流式協議 RTSP(Real-Time Streaming Protocol）

• RTSP是 IETF 的 MMUSIC 工作組(Multiparty Multimedia Session Control WG，多方多媒體會話控制工作組)開發的協議

• RTSP現在是2.0版本

• 又稱帶外協議(out-of-band protocol)：RTSP本身并不傳送數據，而僅僅是使媒體播放器能夠控制多媒體流的傳送

• 又稱互聯網錄像機遙控協議：用來使用戶在播放從互聯網下載的實時數據時能夠進行控制，如:暫停/繼續、快退、快進等。

• RTSP以客戶-服務器方式工作

• RTSP是一個應用層的多媒體播放控制協議

• RTSP的語法和操作與HTTP協議的相似——所有的請求和響應報文都是ASCII 文本。但與HTTP不同的地方是RTSP是有狀態的協議(HTTP是無狀態的)。

• RTSP記錄客戶機所處于的狀態——初始化狀態、播放狀態或暫停狀態

• RTSP控制分組既可在TCP上傳送，也可在UDP上傳送

• RTSP沒有定義音頻/視頻的壓縮方案

• RTSP沒有規定音頻/視頻在網絡中傳送時應如何封裝在分組中

• RTSP沒有規定音頻/視頻流在媒體播放器中應如何緩存

• 在使用 RTSP 的播放器中比較著名的是蘋果公司的QuickTime和Real Networks 公司的 RealPlayer。

工作過程：

8.3 交互式音頻/視頻

8.3.1 IP 電話概述

狹義和廣義IP電話：

共同點: 在 IP 網絡上進行操作。【所謂“IP 網絡”就是“使用IP協議的分組交換網”的簡稱。這里的網絡可以是互聯網，也可以是包含有傳統的電路交換網的互聯網，不過在互聯網中至少要有一個IP網絡。】

不同點：

• 狹義 - 僅能電話通信
• 廣義 - 不僅僅是電話通信，還可以是進行交互式多媒體實時通信(包括話音、視像等)，還可以即時傳信IM(Instant Messaging)。

🌐 交互式多媒體實時通信：指通過IP網絡實現的 語音、視頻、數據協同傳輸，并支持用戶之間的 實時互動。平臺：Zoom、微信視頻等

🌐 即時傳信是一種基于IP網絡的 實時文本/多媒體消息交換 服務，支持用戶或群組間的 低延遲通信，通常集成了狀態管理（在線/離線）、消息回執、文件傳輸等功能。平臺：微信，Slack，釘釘等

💡關鍵差異的直觀對比

維度	狹義IP電話	廣義IP電話
業務形態	單純語音通話	語音+視頻+IM+協作（如共享白板）
典型設備	IP話機、SIP軟電話	智能手機App、瀏覽器、智能音箱

IP電話網關

IP電話網關(IP Telephony Gateway): 它是公用電話網與IP網絡的接口設備。

IP電話網關的作用就是:

• 在電話呼叫階段和呼叫釋放階段進行電話信令的轉換
• 在通話期間進行話音編碼的轉換

IP電話通話質量

電路交換電話網的通話質量：

• 當電路交換電話網的通信量太大時，無法撥通電話(聽到的是忙音)，即電話網拒絕對正在撥號的用戶提供接通服務。
• 只要撥通了電話，保證滿意的通話質量。

IP電話的通話質量，主要由兩個因素決定：

• 通話雙方端到端的時延和時延抖動，

• 話音分組的丟失率。【“丟失掩蔽算法” 對丟失的話音分組進行處理】

? 但這兩個因素都是不確定的，而是取決于當時網絡上的通信量。若網絡上的通信量非常大以致發生了網絡擁塞，
? 那么端到端時延和時延抖動以及分組丟失率都會很高，這就導致IP電話的通話質量下降。

端到端的時延

端到端的時延不應超過250ms，否則交談者就會感到不自然。陸地公用電話網的時延一般只有 50~70ms。但經過同步衛星的電話端到端時延就超過250ms。

IP電話端到端時延是由以下幾個因素造成的:

1. 話音信號進行模數轉換要產生時延。【取決于 話音編碼 的方法。】
2. 已經數字化的話音比特流要積累到一定的數量才能夠裝配成一個話音分組，這也會產生時延。【取決于**話音編碼**的方法。】
3. 話音分組的發送需要時間，此時間等于話音分組長度與通信線路的數據率之比。【當采用高速光纖主干網時，該時延也不大。】
4. 話音分組在互聯網中經過許多路由器的存儲轉發時延。
5. 話音分組到達接收端在緩存中暫存所引起的時延。
6. 將話音分組還原成模擬話音信號的數模轉換也要產生一定的時延。【取決于**話音編碼**的方法。】
7. 話音信號在通信線路上的傳播時延。【一般都很小(衛星通信除外)，通常可不予考慮】
8. 由終端設備的硬件和操作系統產生的接入時延。

• IP電話網關引起的接入時延約為 20~40ms
• 用戶PC聲卡引起的接入時延為20~180ms
• 有的調制解調器(如 V.34)還會再增加 20~40ms的時延(由于進行數字信號處理、均衡等)。

話音編碼

目前適合IP電話使用的ITU-T標準——話音編碼統一的國際標準：

• G.729話音速率為8 kbits 的共軛結構代數碼激勵線性預測 CS-ACELP(Conjugate-Structure Algebraic-Code-Excited Linear Prediction)聲碼器。
• G.723.1話音速率為 5.3/6.3 kbit/s 的線性預測編碼 LPC(Linear Prediction Coding)聲碼器。

標準	比特率(kbit/s)	幀大小(ms)	處理時延(ms)	幀長(字節)	數字信號處理 MIPS
G.729	8	10	10	10	20
G.723.1	5.3/6.3	30	30	20/24	16

• 比特率是輸入為64 kbits 標準 PCM 信號時在編碼器輸出的數據率。
• 幀大小是壓縮到每一個分組中的話音信號時間長度。
• 處理時間是對一個運行編碼算法所需的時間。
• 幀長是一個已編碼的幀的字節數(不包括首部)。
• 數字信號處理MIPS(每秒百萬指令)是用數字信號處理芯片實現編碼所需的最小處理機速率(以每秒百萬指令為單位)。

接收端緩存空間和播放時延的大小對通話質量的影響

Skype IP 電話

• 使用互聯網低比特率編解碼器iLBC (internet Low Bit rate Codec)，進行話音的編解碼和壓縮。

• Skype支持兩種幀長:

  • 20ms(速率為15.2kbits，一個話音分組塊為304bit)
  • 30ms(速率為13.33 kbits，一個話音分組塊為400bit)。

• Skype對話音分組的丟失進行了特殊的處理，因而能夠容忍高達 30%的話音分組丟失率，通話的用戶一般感覺不到話音的斷續或遲延，雜音也很小。

• Skype采用了P2P和全球索引(Global Index)技術提供快速路由選擇機制。

• Skype 還采用了端對端的加密方式，保證信息的安全性。Skype 在信息發送之前進行加密，在接收時進行解密，在數據傳輸過程中保證了中途不被竊聽。

• 戶數據主要存儲在P2P網絡中，Skype對公共目錄中存儲的和用戶相關的數據都采用了數字簽名，保證了數據無法被篡改。

8.3.2 IP電話所需要的幾種應用協議

8.3.3 實時運輸協議 RTP

實時運輸協議 RTP(Real-time Transport Protocol)：為實時應用提供端到端的運輸，但不提供任何服務質量的保證。需要發送的多媒體數據塊(音頻/視頻)經過壓縮編碼處理后，先送給RTP封裝成為RTP分組(也可稱為RTP報文)，分組裝入運輸層的UDP用戶數據報后，再向下遞交給IP層。

可以視為應用層的一部分

• 在應用程序的發送端，開發者必須編寫用RTP封裝分組的程序代碼，然后把RTP 分組交給 UDP套接字接口。
• 在應用程序的接收端，RTP分組通過 UDP 套接字接口進入應用層后還要利用開發者編寫的程序代碼將RTP分組中把應用數據塊提取出。

可以視為運輸層的一部分

• 封裝了多媒體應用的數據塊，并且由于RTP向多媒體應用程序提供了服務(如時間和序號)

RTP分組

RTP分組只包含RTP數據，而控制是由另一個配套使用的 RTCP 協議提供的。

RTP端口號

• RTP 在端口號1025 到 65535 之間選擇一個未使用的偶數 UDP端口號
• 在同一次會話中的 RTCP 則使用下一個奇數 UDP端口號
• 端口號 5004 和 5005 則分別用作RTP和 RTCP 的默認端口號。

RTP首部格式

在RTP分組的首部中，前12個字節是必需的，而12字節以后的部分則是可選的。

• 有效載荷類型(payload type)，占7位。這個字段指出后面的 RTP 數據屬于何種格式的應用。
  • 對于音頻有效載荷：μ律PCM(0)，GSM(3), LPC(7)；A律PCM (8),G.722(9),G.728(15)等。
  • 對于視頻有效載荷：活動 JPEG (26)H.261 (31),MPEGI (32),MPEG2 (33)等。
• 序號，占16位。對每一個發送出的RTP分組，其序號加1。在一次RTP會話開始時的初始序號是隨機選擇的。序號使接收端能夠發現丟失的分組，同時也能將失序的RTP分組重新按序排列好。
• 時間戳 - 媒體時間戳，占32位。時間戳反映了RTP 分組中數據的第一個字節的采樣時刻。
  • 在一次會話開始時時間戳的初始值也是隨機的。即使在沒有信號發送時，時間戳的數值也要隨時間而不斷地增加。
  • 接收端使用時間戳可準確知道應當在什么時間還原哪一個數據塊,從而消除時延的抖動。
  • 時間戳還可以用來使視頻應用中聲音和圖像同步。
• 同步源標識符，占 32位。同步源標識符SSRC(Synchronous SouRCe identifier)是一個數，用來標志 RTP 流(stream)的來源。
  • SSRC與IP地址無關，在新的 RTP 流開始時隨機地產生。
  • RTP使用UDP傳送，因此可以有多個RTP流復用到一個UDP用戶數據報中。
• 參與源標識符，占 32位。
  • 參與源標識符CSRC(Contributing SouRCe identifier)，最多可有15個。用來標志來源于不同地點的 RTP 流。
  • 在多播環境中，可以用中間的一個站(叫作混合站mixer)把發往同一個地點的多個 RTP 流混合成一個流，在目的站再根據CSRC的數值把不同的RTP流分開
• 參與源數，占4位。參與源標識符的數目。
• 版本，占2位。當前使用的是版本2。
• 填充P，占1位。P置1，表示這個RTP分組的數據有若干填充字節。在數據部分的最后一個字節用來表示所填充的字節數。
• 擴展X，占1位。X置1，表示在此RTP首部后面還有擴展首部。
• 標記M，占1位。M置1，表示這個RTP分組具有特殊意義。

8.3.4 實時運輸控制協議RTCP

實時運輸控制協議 RTCP(RTP Control Protocol) 主要功能是:

• 服務質量的監視與反饋、
• 媒體間的同步(如某一個RTP發送的聲音和圖像的配合)，
• 以及多播組中成員的標志。

RTCP分組

• RTCP分組(也可稱為RTCP報文)也使用 UDP來傳送，但 RTCP 并不對音頻/視頻分組進行封裝。
• 由于RTCP 分組很短，因此可把多個 RTCP分組封裝在一個UDP用戶數據報中。
• RTCP分組周期性地在網上傳送，它帶有發送端和接收端對服務質量的統計信息報告(例如，已發送的分組數和字節數、分組丟失率、分組到達時間間隔的抖動等)。

RTCP分組類型

類型	縮寫表示	意義
200	SR	發送端報告
201	RR	接收端報告
202	SDES	源點描述
203	BYE	結束
204	APP	特定應用

結束分組 BYE 表示關閉一個數據流。

特定應用分組 APP 使應用程序能夠定義新的分組類型。

接收端報告分組 RR 用來使接收端周期性地向所有的點用多播方式進行報告。

• 發送RR分組有兩個目的:

  • 第一，可以使所有的接收端和發送端了解當前網絡的狀態;
  • 第二，可以使所有發送 RTCP 分組的站點自適應地調整自己發送 RTCP分組的速率，使得起控制作用的RTCP分組不要過多地影響傳送應用數據的RTP分組在網絡中的傳輸。

• 接收端每收到一個 RTP流(一次會話包含有許多的RTP流)就產生一個接收端報告分組RR。

• RR分組的內容有:

  • 所收到的RTP流的SSRC；
  • 該RTP流的分組丟失率(若分組丟失率太高，發送端就應當適當降低發送分組的速率);
  • 在該RTP流中的最后一個RTP分組的序號；
  • 分組到達時間間隔的抖動等。

發送端報告分組SR 用來使發送端周期性地向所有接收端用多播方式進行報告。

• 發送端每發送一個RTP流，就要發送一個發送端報告分組SR。
• SR分組的主要內容有:
  • 該RTP流的同步源標識符 SSRC;
  • 該RTP流中最新產生的RTP分組的時間戳和絕對時鐘時間(或墻上時鐘時間 wall clock time);
    【要傳送視頻圖像和相應的聲音就需要傳送兩個流。絕對時鐘時間就可進行圖像和聲音的同步。】
  • 該 RTP 流包含的分組數；
  • 該 RTP 流包含的字節數。

源點描述分組SDES 給出會話中參加者的描述，它包含參加者的規范名NAME(Canonical NAME)。規范名是參加者的電子郵件地址的字符串。

8.3.5 H.323

H.323 概述

H.323 是互聯網的端系統之間進行實時聲音和視頻會議的標準。

H.323不是一個單獨的協議而是一組協議。

H.323 包括系統和構件的描述、呼叫模型的描述、呼叫信令過程、控制報文、復用、話音編解碼器、視像編解碼器，以及數據協議等。

H.323 核心構件

組件	功能	類比
H.323 終端（Terminal）	發起/接收音視頻的設備（IP 電話、視頻會議終端） 【可以是一個PC，也可以是運行H.323程序的單個設備】	參會者
網關（Gateway）	連接 H.323 網絡與傳統電話網（PSTN） 【連接到兩種不同的網絡，使得H.323 網絡可以和非H.323 網絡(如公用電話網)進行通信。僅在一個H.323網絡上通信的兩個終端就不需要使用網關。】	翻譯官
網閘（Gatekeeper）	負責地址解析（地址轉換）、帶寬管理、訪問控制（授權）和計費功能 還可以幫助 H.323 終端找到距離公用電話網上的被叫用戶最近的一個網關。	調度員
多點控制單元MCU（Multipoint Control Unit）	多方會議控制（混音、視頻切換） 【管理會議資源、確定使用的音頻或視頻編解碼器】	會議主持人

H.323 體系結構

• 音頻編解碼器 H.323要求至少要支持G.711(64kbits的PCM)。建議支持如G.722(16 kbit的ADPCM),G.723.1(5.3/6.3的LPC),G.728(16 kbits 的低時延 CELP)和 G.729(8 kbit/s的CS-ACELP)等。
• 視頻編解碼器 H.323 要求必須支持 H.261標準(176x144 像素)。
• H.255.0登記信令，即登記/接納/狀態 RAS(Registration/Admission/Status)。H.323終端和網閘使用RAS來完成登記、接納控制和帶寬轉換等功能。
  • 終端注冊/注銷：終端向網閘注冊自身的聯系信息（如 IP 地址、別名），加入 H.323 網絡管理域。
  • 地址解析：網閘將終端的別名（如電話號碼 “1001”）映射為網絡地址（IP:Port）。
  • 權限認證：驗證終端身份（如密碼、證書），防止非法接入。
  • 狀態維護：定期發送心跳消息（Keepalive），監控終端在線狀態。
• H.225.0呼叫信令，用來在兩個 H.323 端點之間建立連接。
• H.245 控制信令，用來交換端到端的控制報文，以便管理 H.323端點的運行。
• T.120 數據傳送協議 這是與呼叫相關聯的數據交換協議。用戶在參加音頻/視頻會議時，可以和其他與會用戶共享屏幕上的白板。由于使用TCP協議，因此能夠保證數據傳送的正確(在傳送音頻/視頻文件時使用的是 UDP，因此不能保證服務質量)。
• 實時運輸協議 RTP 和實時運輸控制協議 RTCP。

H.323是在以已有的電路交換電話網為基礎，增加了IP電話的功能(即遠距離傳輸采用IP網絡)。H.323的信令也沿用原有電話網的信令模式，因此與原有電話網的連接比較容易。

8.3.6 會話發起協議 SIP

會話發起協議SIP(Session Initiation Protocol)

• SIP 以互聯網為基礎，而把IP 電話視為互聯網上的新應用。
• SIP 使用文本方式的客戶-服務器協議。
• SIP 是基于報文的協議。SIP使用了HTTP的許多首部、編碼規則、差錯碼以及一些鑒別機制。
• SIP 還有一個配套協議是會話描述協議SDP(Session Description Protocol)——使電話會議的參加者應當能夠動態地加入和退出。
• SIP 系統只有兩種構件：
  • 用戶代理(user agent)兩個程序
    • 用戶代理客戶 UAC(User Agent Client)，用來發起呼叫，
    • 用戶代理服務器 UAS(User Agent Server)，用來接受呼叫。
  • 網絡服務器(network server)兩個程序
    • 代理服務器(proxy server)。接受來自主叫用戶的呼叫請求(實際上是來自用戶代理客戶的呼叫請求)，并將其轉發給被叫用戶或下一跳代理服務器，然后下一跳代理服務器再把呼叫請求轉發給被叫用戶(實際上是轉發給用戶代理服務器)。
    • 重定向服務器(redirect server)。不接受呼叫，它通過響應告訴客戶下一跳代理服務器的地址，由客戶按此地址向下一跳代理服務器重新發送呼叫請求。
• SIP地址可以是電話號碼，也可以是電子郵件地址、IP地址或其他類型的地址。SIP的地址格式，例如:
  • 電話號碼 sip:zhangsan@8625-87654321
  • IPv4 地址 sip:zhangsan@201.12.34.56
  • 電子郵件地址 sip:zhangsan@163.com
• SIP 會話

8.4 改進“盡最大努力交付”的服務

8.4.1 使互聯網提供服務質量

服務質量 QoS 是服務性能的總效果，此效果決定了一個用戶對服務的滿意程度。服務質量可用若干基本的性能指標來描述，包括可用性、差錯率、響應時間、吞吐量、分組丟失率、連接建立時間、故障檢測和改正時間等。

路由器分類：

分類(classification)，即路由器根據某些準則對輸入分組進行分類，然后對不同類別的通信量給予不同的優先級。

路由器管制：

路由器能夠對某個數據流進行通信量的管制(policing)，使得這個數據流不要影響其他正常的數據流在網絡中通過。

路由器調度：

調度，能夠決定數據的發送順序。

呼叫接納(call admission)：

數據流預先聲明它所需的服務質量，然后或者被準許進入網絡(能得到所需的服務質量)，或者被拒絕進入網絡(當所需的服務質量不能得到滿足)

8.4.2 調度和管制機制

1、調度機制

“調度”就是指排隊的規則

默認排隊規則就是先進先出FIFO(First In First Out)

• 當隊列已滿時，后到達的分組就被丟棄。
• 最大缺點就是不能區分時間敏感分組和一般數據分組。
• 不公平，排在長分組后面的短分組要等待很長的時間。

按優先級排隊。假定優先級分為兩種，因此有兩個隊列:高優先級隊列和低優先級隊列。

• 在到達路由器后就由分類器(又稱為分類程序)對其進行優先級分類，然后按照類別進入相應的隊列。

• 只要高優先級隊列中有分組在內，就從高優先級隊列中按照鏈路速率取出排在隊首的分組。

• 只有當高優先級隊列已空時，才能輪到低優先級隊列中的分組輸出到鏈路上。

• 缺點：在高優先級隊列中總是有分組時，低優先級隊列中的分組就長期得不到服務。

  

公平排隊FQ(Fair Queuing)。

• 公平排隊是對每種類別的分組流設置一個隊列，然后輪流使每一個隊列一次只能發送一個分組。
• 對于空的隊列就跳過去。
• 缺點：長分組得到的服務時間長，而短分組就比較吃虧，并且公平排隊并沒有區分分組的優先級。

加權公平排隊 WFQ(Weighted Fair Queuing)。

• 分組到達后就進行分類，然后送交與其類別對應的隊列(假定分為三類)。

• 三個隊列按順序依次把隊首的分組發送到鏈路。遇到隊列空就跳過去。

• 根據各類別的優先級不同，每種隊列分配到的服務時間也不同。

  可以給隊列 i 指派一個權重 w_i 。隊列 i 得到的平均服務時間為 w_i / (Σw_j) ，這里 ∑w_j 是對所有的非空隊列的權重求和。

  若路由器輸出鏈路的數據率(即帶寬)為R，那么隊列 i 將得到的有保證的數據率 R_i 應為 R_i = (R × w_i) / (Σw_j)

  

2、管制機制

對一個數據流，我們可根據以下三個方面進行管制:

• 平均速率：是指在一定的時間間隔內通過的分組數。但這個時間間隔的選擇也說明了這個指標的嚴格程度。

  限定數據流的平均速率為每秒50個分組和平均速率為每分鐘3000個分組，雖然這兩個指標的平均值都一樣，但其嚴格程度卻不同。假定有一個數據流，有一秒鐘通過了1000個分組，但一分鐘平均下來仍不超過 3000個，那么這個數據流的平均速率符合后面一個指標，但卻遠遠不滿足前面的指標。

• 峰值速率：限制了數據流在非常短的時間間隔內的流量。“非常短的時間間隔”需要指明時間間隔是多少。峰值速率也同時受到鏈路帶寬的限制。

  例如，限定數據流的平均速率為每分鐘3000個分組，但同時限定其峰值速率不超過每秒1000個分組。

• 突發長度：網絡也限制在非常短的時間間隔內連續注入到網絡中的分組數。

漏桶管制器(leaky bucket policer)(可簡稱為漏桶) 可對進入網絡的分組流按以上三個指標進行管制：

• 漏桶是一種抽象的機制。

• 漏桶中 最多可裝入b個權標(token)。只要漏桶中的權標數小于b個，新的權標就 以每秒r個權標的恒定速率加入到漏桶 中。但若 漏桶已裝滿了b個權標，則新的權標就不再裝入 ，而漏桶的權標數達到最大值b。

• 漏桶管制分組流進入網絡的過程如下:

  • 分組進入網絡前，先要進入一個隊列中等候漏桶中的權標。

    • 若漏桶中有權標，就可從漏桶取走一個權標，然后就準許一個分組從隊列進入到網絡。

    • 若漏桶已無權標，就要等新的權標注入到漏桶，再把這個權標拿走后才能準許下一個分組進入網絡。

      【“準許進入網絡”不等于“已經進入了網絡”，分組進入網絡還需要時間，取決于輸出鏈路的帶寬和分組在輸出端的排隊情況。】

  • 假定在時間間隔t 中把漏桶中的全部b個權標都取走，但在這個時間間隔內漏桶又裝入了rt個新的權標，因此在任何時間間隔t內準許進入網絡的分組數的最大值為rt+b。控制權標進入漏桶的速率r就可對分組進入網絡的速率進行管制。

3、漏桶機制與加權公平排隊相結合: 管制 + 調度

把漏桶機制與加權公平排隊結合起來，可以控制隊列中的最大時延

假定有n個分組流輸入到一個路由器，復用后從一條鏈路輸出。每一個分組流使用漏桶機制進行管制，漏桶參數為 b_i 和 r_i，i=1,2,…,n

當分組流通過漏桶后等待 WFQ服務時，一個分組所經受的最大時延?

分組流i。

• 假定漏桶i已經裝滿了b_i個權標。表示分組流i不需要等待就可從漏桶中拿走b_i個權標，因此6個分組可以馬上從路由器輸出。
• 分組流i 得到的數據率R_i = (R × w_i) / (Σw_j)。
• b_i個分組中最后一個分組所經受時延最大，等于傳輸這b_i個分組所需的時間 d_max，即 b_i 除以傳輸速率: d_max = [b_i · (Σw_j)] / (R × w_i)

8.4.3 綜合服務IntServ與資源預留協議RSVP

綜合服務IntSery和資源預留協議RSVP都較復雜，很難在大規模的網絡中實現

綜合服務IntServ(Integrated Services)： 可對單個的應用會話提供服務質量的保證

IntServ 特點

• 資源預留。一個路由器需要知道給不斷出現的會話已經預留了多少資源(即鏈路帶寬和緩存空間)。

• 呼叫建立。在一個會話開始之前必須先有一個呼叫建立(又稱為呼叫接納)過程，它需要在其分組傳輸路徑上的每一個路由器都參加。每一個路由器都要確定該會話所需的本地資源是否夠用，同時還不要影響到已經建立的會話的服務質量。

  一個需要服務質量保證的會話: 在源點到終點路徑上的每一個路由器預留足夠的資源，以保證其端到端的服務質量的要求。

IntServ 定義了兩類服務:

• 有保證的服務(guaranteed service)，可保證一個分組在通過路由器時的排隊時延有一個嚴格的上限。
• 受控負載的服務(controlled-load service)，可以使應用程序得到比通常的“盡最大努力”更加可靠的服務。

IntServ 共有以下四個組成部分:

• 資源預留協議RSVP，是 IntServ 的信令協議。
• 接納控制(admission control)，用來決定是否同意對某一資源的請求。
• 分類器(classifer)，用來把進入路由器的分組進行分類，并根據分類的結果把不同類別的分組放入特定的隊列。
• 調度器(scheduler)，根據服務質量要求決定分組發送的前后順序。

資源預留協議 RSVP(ReSource reserVationProtocol)

會話聲明它所需的服務質量，以便使路由器能夠確定是否有足夠的資源來滿足該會話的需求。

RSVP協議是面向終點的

RSVP 協議不是運輸層協議而是網絡層的控制協議，RSVP不攜帶應用數據。

資源預留協議RSVP工作原理：

• 資源預留協議RSVP在進行資源預留時采用了多播樹的方式。

• PATH 報文

  • 發送端發送PATH 報文(即存儲路徑狀態報文)，給所有的接收端指明通信量的特性。

  • 每個中間的路由器都要轉發 PATH報文。

• RESV報文

  • 接收端用RESV報文(即資源預留請求報文)進行響應。

  • 路徑上的每個路由器對RESV報文的請求都可以拒絕或接受。

    • 當請求被某個路由器拒絕時，路由器就發送一個差錯報文給接收端，從而終止了這一信令過程。
    • 當請求被接受時，鏈路帶寬和緩存空間就被分配給這個分組流，而相關的流(ow)狀態信息就保留在路由器中。

?

IntServ 體系結構分為前臺和后臺兩個部分。

• 組成部分：

  • 前臺部分，包括兩個功能塊，即分類器與分組轉發，分組的調度器。每一個進入路由器的分組都要通過這兩個功能塊。

  • 后臺部分，包括四個功能塊和兩個數據庫。這四個功能塊是:

    • 路由選擇協議，負責維持路由選擇數據庫。由此可查找出對應于每一個目的地址和每一個流的下一跳地址。

    • RSVP協議，為每一個流預留必要的資源，并不斷地更新通信量控制數據庫

    • 接納控制，當一個新的流產生時，RSVP就調用接納控制功能塊，以便確定是否有足夠的資源可供這個流使用。

    • 管理代理，用來修改通信量控制數據庫和管理接納控制功能塊，包括設置接納控制策略。

• 存在的主要問題:

  • 狀態信息的數量與流的數目成正比。在大型網絡中，按每個流進行資源預留會產生很大的開銷。
  • IntServ 體系結構復雜。
    若要得到有保證的服務，所有的路由器都必須裝有 RSVP、接納控制、分類器和調度器。這種路由器稱為RSVP路由器。在應用數據傳送的路徑中只要有一個路由器不是RSVP路由器，整個的服務就又變為“盡最大努力交付”了。
  • 綜合服務 IntServ 所定義的服務質量等級數量太少，不夠靈活。

8.4.4 區分服務DiffServ

1、區分服務的基本概念

區分服務 DiffServ (Differentiated Services), 有時簡寫為DS。 是 網絡流量分類管理 的一種方式，通過 給分組打標簽（標記優先級），讓路由器根據標簽提供不同的服務質量（QoS）。

有區分服務功能的節點就稱為DS節點。

區分服務 DiffServ的要點:

• DiffServ 不改變網絡的基礎結構，在路由器中增加區分服務的功能。

  DiffServ將IP協議中原有8位的IPv4的服務類型字段和IPv6 的通信量類字段重新定義為區分服務DS。路由器根據DS字段的值來處理分組的轉發。利用DS 字段的不同數值就可提供不同等級的服務質量。

  • DS字段現在只使用其中的前6位，即區分服務碼點DSCP(Differentiated Services Code Point),
  • 后面的兩位目前不使用，記為CU(Currently Unused)。

? 由 DS 字段的值所確定的服務質量實際上就是由 DS 字段中 DSCP 的值來確定的。

• 網絡被劃分為許多個DS域(DS Domain), 一個DS域在一個管理實體的控制下實現同樣的區分服務策略。DiffServ將所有的復雜性放在DS 域的邊界節點(boundary node)中而使 DS 域內部路由器工作得盡可能簡單。
• 邊界路由器 的功能較多，可分為分類器(classifier)和通信量調節器(conditioner)兩大部分。
  • 調節器又由標記器(marker)、整形器(shaper)和測定器(meter)三個部分組成。
• 提供了一種聚合(aggregation)功能。DiffServ是把若干個流根據其DS值聚合成少量的流。路由器對相同DS 值的流都按相同的優先級進行轉發。不需要使用 RSVP 信令。

2、每跳行為 PHB

“行為”就是指在轉發分組時路由器對分組是怎樣處理的。例子:“首先轉發這個分組”或“最后丟棄這個分組”。

“每跳”是強調這里所說的行為只涉及本路由器轉發的這一跳的行為，而與下一個路由器怎樣處理無關。

定義了兩種 PHB：

• 迅速轉發PHB(Expedited Forwarding PHB) 可記為EF PHB，或 EF。對應于EF的區分服務碼點DSCP的值是101110。

  • EF指明離開一個路由器的通信量的數據率必須等于或大于某一數值。
  • 用來構造通過 DS 域的一個低丟失率、低時延、低時延抖動、確保帶寬的端到端服務(即不排隊或很少排隊)——又稱為Premium(優質)服務。

• 確保轉發 PHB(Assured Forwarding PHB) 可記為 AF PHB 或 AF。

  • DSCP的第0~2位把通信量劃分為四個等級(分別為001，010，011和100)，并給每一種等級提供最低數量的帶寬和緩存空間。

  • 對于其中的每一個等級再用DSCP的第3~5位劃分出三個“丟棄優先級”(分別為010，100和110，從最低丟棄優先級到最高丟棄優先級)

    當發生網絡擁塞時，對于每一個等級的AF，路由器就首先把“丟棄優先級”較高的分組丟棄。

對比維度	區分服務（DiffServ）	綜合服務（IntServ/RSVP）
核心思想	基于類（Class-Based）：分組按 DSCP 標記分類處理	基于流（Flow-Based）：為每個連接預留資源（端到端保障）
資源管理	無嚴格預留，僅優先級調度	嚴格預留帶寬/延遲（通過 RSVP 信令協議）
復雜度	? 低（路由器只需處理少數 PHB 行為）	? 高（需維護每一條流的狀態）
擴展性	? 強（適合大規模網絡，如互聯網）	? 弱（僅適用于小規模網絡，如企業內網）
服務質量保證	? 相對保障（依賴優先級標記）	? 絕對保障（硬性預留資源）
標記方式	使用 IP 頭部 DSCP 字段（6 位編碼）	依賴 RSVP 信令協議（PATH/RESV 報文）
典型應用	互聯網 ISP、多業務企業網	視頻會議專線、高要求實時業務
擁塞處理	通過優先級調度緩解擁塞	直接拒絕無法滿足 QoS 的新流

---

參考教材：

計算機網絡（第8版） (謝希仁) (Z-Library).pdf