本節書摘來自異步社群《cisco qos認證考試指南（第2版）》一書中的第1章，第1.4節，作者 【美】wendell odom , michael j. cavanaugh，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
cisco qos認證考試指南（第2版）
你為什麼需要qos呢？qos能夠影響網絡的帶寬、延遲、抖動和丢包等屬性。不同的應用對于帶寬、延遲、抖動和丢包的要求也不相同。通過使用qos，網絡可以更好地為每種應用配置設定合理的qos資源。
接下來的三個小節涵蓋了語音流、視訊流和資料流。早期的qos考試中覆寫了更多有關語音、視訊和資料的qos特征；但目前qos考試所涉及的這部分知識并不深入。很多閱讀過本書前一版的讀者認為下面的小節介紹了很多很好的背景知識，值得通篇閱讀本章接下來的内容，但有關考試的更多重點内容将來自于本書的其他章節。如果你決定跳過本小節，請不要錯過名為“規劃和實施qos政策”的小節，它在本章“基礎小結”部分之前。
在未使用qos工具的網路中，語音流量的品質會衰減得很快。本章足夠詳細地介紹了語音流量，使大家能夠了解每種qos工具可以對語音産生的影響。
注釋：本書不會深入介紹語音，因為那些細節并不直接與qos相關。如需額外資訊，請參考以下資源：
deploying cisco voice over ip solutions，cisco press出版，davidson和fox著
ip telephony，惠普專業書籍，douskalis著
voice over ip fundamentals，cisco press出版，davidson和peters著1
ip telephony，mcgraw hill出版，goralski和kolon著
www.cisco.com/warp/public/788/voip/delay-details.html
若不使用qos，呼叫者會體驗到很差的語音品質，語音會變得斷斷續續或不知所雲。延遲會導緻可互動性降低，比如通話的雙方可能總是會同時說話，因為延遲會使人感覺對方已經說完了他/她想說的話。再比如聲音丢失，會使呼叫者聽到空白音。甚至呼叫還能能被中斷。
大多數qos問題都可以分為4個qos特性來進行讨論：帶寬、延遲、抖動和丢包。首先我們先介紹資料網絡中的語音基礎，接下來就這4種qos特性，來讨論針對語音流量實施的具體qos政策。
1．語音基礎
資料網絡中的語音包括：ip語音（voip）、幀中繼語音（vofr）和atm語音（voatm）。這3種資料語音技術都用來傳輸語音，但它們之間又有些微差别。在考試中，你見到的大多數問題都是與voip相關的，而不是vofr或voatm，因為在這3項技術中，voip是最普及的。cisco ip電話建立的所有呼叫都使用voip，而不是vofr或voatm。
請想象在圖1-17中，兩台模拟電話201和301之間建立了一通呼叫。
在對端電話能夠聽到聲音之前，會發生一系列事件。任一方使用者需要摘機并撥号，連接配接該電話的路由器會對号碼進行翻譯，然後使用信令的方式建立voip呼叫（本例中兩台電話分别連接配接在r1和r3的fxs模拟端口上，是以路由器使用h.323信令）。在信令的處理過程中，主叫方會聽到回鈴音，被叫方會聽到電話振鈴。當被叫方摘機後，呼叫建立完成。
實際的語音呼叫（相對于信令來說）使用的是實時傳輸協定（rtp）。圖1-18給出了使用rtp的ip資料包格式。
在兩台模拟電話之間建立呼叫的過程中，路由器首先會收集模拟語音，然後将語音數字化，再用一種語音編碼方式将語音進行編碼，最後将編碼後的語音放入圖1-18所示的負載字段中。舉例來說，r1會建立如圖1-18所示的ip資料包，将編碼後的語音比特放入語音負載字段，然後發送資料包。源ip位址是r1上的ip位址，而目的ip位址是r3上的ip位址。當r3接收到資料包後，它會執行反向操作，最終通過模拟電話播放出模拟聲波。
ip電話所經曆的的呼叫過程在概念上與之相似，但具體細節有些不同。ip電話所使用信令包括sccp（skinny用戶端控制協定，skinny client control protocol），該協定工作在ip電話與cucm2（cisco unified communications manager）伺服器之間。信令完成後，兩台ip電話之間建立rtp流。cucm并不直接參與實際的通話，它隻在呼叫建立和拆除階段介入（cucm為了實作控制，會與每台ip電話維護一個tcp連接配接）。r1和r3并不會代替ip電話來建立rtp資料包，因為ip電話自己負責建立rtp資料包。在r1和r3看來，ip電話發送的資料包隻是ip資料包。
最後，網絡管理者可以選擇voip呼叫所使用的編/解碼器（編碼）。編碼器負責處理入站的模拟信令，将其轉換為數字（二進制）信令。用來表示語音的二進制數值，根據管理者所設定的編碼，而有所不同。每種編碼都有多種特性，其中最重要的特性是所需帶寬，即裝置發送這種編碼建立的語音負載需要多少帶寬。表1-10給出了常用的編碼及其所需帶寬。
*負載包含數字化語音，但不包含傳輸語音流量所需的標頭和包尾
語音基礎（是的，非常基礎！）部分可以總結為以下内容。
多種語音信令協定可以通過響應使用者在電話上的撥出的号碼，在兩台電話之間建立rtp流。
rtp流用于在兩台電話之間（或在其voip網關之間）傳輸語音。
為什麼對語音的描述如此簡單？這是因為所有語音負載流都需要相同的qos特征，而所有語音信令流都需要相同的其他qos特征。通過每種類型的qos工具，本書會給出如何為“語音”實施qos工具，其中分兩類讨論，即語音負載（rtp資料包）和語音信令。表1-11對比了語音負載和語音信令所需的qos需求。
通過使用qos工具，管理者可以用不同的方式，分别對待語音負載和語音信令。是以每類qos工具都需要首先把語音資料包歸類到這兩種類型之中。為了分類，qos工具需要能夠定位資料包中的一個字段，這個字段表明這個資料包是語音負載、語音信令或者表明這是其他類型的資料包。表1-12列出了用于語音信令和語音負載的各種協定、定義該協定的文檔，并說明如何對其進行識别。
接下來的内容将針對4項qos特征，更詳細地介紹與語音相關的内容：帶寬、延遲、抖動和丢包。
2．語音帶寬考量
語音呼叫會建立一個擁有固定資料速率的流，即每個資料包之間具有相等的間隔。我們可以把語音資料流描述為等時的（isochronous），引用dictionary.com的解釋，意思是“具有相同時間間隔的特征，或在相同時間間隔發生。”請考慮圖1-19所示案例，模拟電話201和301之間建立了一通呼叫。
r1建立出ip/udp/rtp語音負載資料包并将其發送出去，預設發送間隔為20毫秒。由于cisco ios軟體在每個資料包中放入20毫秒的編碼語音，是以裝置需要每20毫秒發送一個資料包。這時，語音負載實際需要多少帶寬？真實帶寬需求量依賴于以下幾個方面：
編碼；
資料包開銷（ip/udp/rtp）；
資料鍊路成幀類型（取決于使用的資料鍊路）；
壓縮。
很多人将g.711呼叫按64 kbit/s計算，将g.729呼叫按8 kbit/s計算，這個帶寬值僅考慮了負載，忽略了資料鍊路、ip、udp和rtp頭部。
不同的編碼選擇以及是否使用rtp頭部壓縮，會導緻帶寬需求截然不同。壓縮rtp（crtp）會壓縮ip/udp/rtp頭部，并且當使用較低比特率的編碼時，帶寬需求會顯著降低。在使用g.711時，由于大多數帶寬需要承載的是語音負載，是以雖然crtp有助于減少帶寬需求，但從百分比來看，帶寬需求降低得并不明顯。不管編碼類型是什麼，隻要使用了crtp，就會增加延遲，因為處理器需要對標頭進行壓縮和解壓縮。
注釋：盡管實際中有很多編碼選擇，但本書在多數案例中僅對比g.711和g.729，需要注意的是，在使用其他編碼時，可能需要不同的qos政策。
atm會在語音資料包上添加可觀的資料鍊路開銷。每個atm呼叫都有5位元組的開銷；除此之外，隻有一部分承載了語音資料包的最後一個信元（cell）中，可能會有很多浪費的空間。舉例來說，g.729呼叫的資料包大小為60位元組，atm為其添加8位元組的幀開銷，之後将這68位元組的幀放到兩個信元中——其中一個占滿atm信元負載的48位元組，而另一個占用20位元組的信元負載，并“浪費”掉28位元組。是以為了發送一個大小為60位元組的語音“資料包”，将會有總大小為106位元組的兩個信元被發送到atm網絡中。有一個方法可以減少開銷，即在負載中包含30毫秒的g.729編碼語音，有趣的是這也隻需要兩個atm信元。
語音活動檢測（vad，voice activity detection）也會對語音負載實際使用的帶寬産生影響。當通話中沒有聲音時，vad可以讓語音資料包的發送方不發送任何資料包。由于人們在聆聽的時候通常不說話，是以對話是互動式的（我知道例外也總是存在的，就像我現在就能想到例外場景！），進而vad可以将實際帶寬減少60%左右。為每通呼叫節省的帶寬量是無法預測的，比如在吵雜的環境中通話，vad就無法生效了。同時vad也會使通話者感到不愉快。比如通話者有一段時間沒說話，當他再次開始說話時，根據vad的邏輯，前端語音有可能被剪切，也就是不發送最開始幾毫秒的語音。
表1-13全面對比了在不同的資料鍊路協定上，兩種編碼類型實際所使用的比特率。該表還分行顯示出這兩種常見編碼在每個資料包中承載預設20毫秒語音負載（每秒50個資料包）以及30毫秒語音負載（每秒33.3個資料包）的情況。
*第3層帶寬消耗是指資料包第3層標頭到資料（有效負載）部分所消耗的帶寬
表1-13呈現出一個有趣的事實：将g.729從50 pps（每資料包20毫秒負載）改為33 pps（每資料包30毫秒負載），在atm鍊路上會極大地節省帶寬。這是因為轉發60位元組的voip資料包（g.729的20毫秒負載）需要兩個atm信元，轉發80位元組的voip資料包（g.729的30毫秒負載）也需要兩個atm信元。
3．延遲考量
延遲過多會降低語音呼叫的品質，現象表現為語音斷斷續續，甚至導緻呼叫斷開。這種情況下，溝通也會變得困難，不知你是否曾經使用無線電話通話，感覺像在使用無線電？“嘿，弗雷德，我們去打保齡球吧。完畢。”“好的，巴尼，我們去打保齡球，貝蒂和威爾瑪去逛街。完畢。”如果延遲很大的話，可能無法知道何時該你講話了。
語音流量與其他資料包一樣，也會遭遇延遲，這些延遲來自于不同的源。表1-14有助于回顧前文講述的延遲組成。
圖1-20所示案例解釋了延遲的相關概念，并給出了延遲值（舉例）。如果延遲是可以忽略的，案例中将其列為0。圖中的數字表示延遲值，這些值是根據真實情況編造的。轉發延遲通常以微秒為機關，是以是可以忽略的。r1到r2之間的傳播延遲是以100千米鍊路為标準計算的。串行化延遲是以未經壓縮的g.729語音資料包為标準，且假設ppp為其資料鍊路協定。隊列延遲的可能範圍很大；本例在r1的56 kbit/s鍊路上給出了15毫秒——假設語音資料包前面排了一個105位元組的資料幀——這并不是一個很大的隊列延遲。50毫秒的網絡延遲是編造的，但這是一個非常合理的數字。本例中的總延遲是94毫秒，對于資料網絡工程師來說，這個延遲相當理想。
這樣就足夠了嗎？語音呼叫可以容忍多小的延遲？itu對合理的單向延遲預算進行了定義，但cisco有不同的想法。你可能會遇到這種使用者：為了省錢而忍受大延遲。舉例來說，有品質保證的國際呼叫需要每分鐘3美元，那麼你可能更傾向使用品質差的免費呼叫。表1-15列出了延遲預算的建議。
圖1-20中的呼叫滿足了g.114推薦的延遲預算。但對于語音流量來說，除了資料流量會遭遇的所有延遲類型之外，還有一些額外的延遲類型：
編解碼延遲（codec delay）；
封包化延遲（packetization delay）；
去抖動緩沖延遲（de-jitter buffer delay）（初始播放延遲，initial playout delay）。
警告：
很多圖書和網站使用不同的術語來表示這3種與語音相關的延遲類型。本書使用的術語與cisco課程一緻，是以也與考試一緻。
編解碼延遲和封包化延遲彼此相同。要了解它們的中心概念請看圖1-21，本例中問了一個問題，“從講話者說出的話，到裝置發送ip資料包，這之間經曆了多少延遲？”
考慮一下，在ip電話發送資料包之前，都會發生什麼。呼叫者撥号，之後呼叫建立。當呼叫建立後，ip電話開始發送rtp資料包。一旦ip電話開始發送資料包，它每20毫秒（預設）發送一個，也就是說每個資料包的語音負載中有20毫秒的語音。那麼從說話者發出聲音，到攜帶這部分聲音的資料包被發送出去，這之間需要多長時間？
請想象聲音波動了一瞬間。若你和我坐在同一間屋子裡交談，從你說話到我聽到，這段延遲是非常小的，因為你的聲音是以聲速傳播的，也就是大約1000千米每小時。在包交換電話通訊中，裝置需要把聲音轉換成模拟電子信号，後再轉換成數字電子信号，最後将這個數字信号（負載）放入資料包中，也就是說裝置需要時間來做上述操作。是以在講話者說話後，到裝置發送ip/udp/rtp負載資料包之前，将會有一些延遲，并且在這期間經曆的延遲如下所示：
封包化延遲；
編解碼延遲。
4．封包化延遲
ip電話或語音網關必須收集20毫秒的語音，才會将20毫秒語音負載放入一個資料包中（使用g.711和g.729的ip電話和cisco ios軟體網關預設會将20毫秒的語音放入一個rtp資料包中；管理者可以修改這個值）。是以，在本書的讨論中，我們總是在案例中使用20毫秒的标準。這也就是說，說話者必須說了20毫秒之後，裝置才會建立承載20毫秒語音的資料包。
5．編解碼延遲
編解碼延遲包含以下兩部分：
處理入站模拟信号并将其轉換成相應數字信号所花費的時間；
稱作先行控制（look-ahead）的特性。
先說說編解碼延遲中的第一個部分，這部分對于所有編解碼類型來說都是一樣的，ip電話或網關必須對入站的模拟信号進行處理，根據所使用的編解碼類型，将其編碼為相應的數字信号。舉例來說，g.729一次性處理10毫秒的模拟語音。這個處理過程确實需要花費時間，将模拟信号轉換成g.729 cs-acelp（共轭結構-代碼激勵線性預測）實際所花費的時間大約為5毫秒。根據編碼負載，cisco站點中的一些文章将這個數值取值在2.5～10毫秒。
編解碼算法可能會引入額外的延遲，這是由其名為先行控制（look-ahead）的特性所緻。在預知編碼類型的條件下，會用到先行控制。換句話說，就是通過利用人類聲帶的特性（無法從一種聲音瞬間轉換成另一種完全不同的聲音），使用更少的比特數來編碼語音。通過研究語音講話，并且知道在接下來的幾毫秒後，聲音不會發生顯著的變化，這時算法就可以用更少的比特數來編碼語音——這是将64 kbit/s的g.711呼叫發展成8 kbit/s的g.729呼叫的一種方法。然而，預知算法通常要求編解碼器在處理将被編碼的語音信号時，要連同接下來的幾毫秒語音一起處理。比如g.719編碼要處理10毫秒語音樣本，編解碼器需要收到全部的10毫秒語音，還要加上接下來的5毫秒，這是為了執行編碼算法中的預知部分。
是以g.729a編碼為語音帶來的延遲如下，以10毫秒樣本為例，從要被編碼的這10毫秒語音到達時開始算起：
5毫秒先行控制+5毫秒處理（平均）=10毫秒
paper09186a00800a8993.shtml）。
6．考慮封包化延遲和編解碼延遲帶來的影響
我們需要綜合考慮封包化延遲和編解碼延遲，因為它們也确實混雜在一起。舉例來說，封包化延遲會消耗20毫秒，用來等待20毫秒的語音傳來。但在這前20毫秒之間還發生了什麼？請看表1-16，這裡列出了各個事件發生的時間表，這個表是從講話者開始說話計算的。
需要注意的是，封包化延遲和編解碼延遲重疊在一起。盡管它們各自耗費20毫秒，但由于它們重疊在一起，是以資料包實際經曆的總延遲是30毫秒，而不是40毫秒。
7．去抖動緩沖延遲
去抖動緩沖延遲是語音延遲的第三個組成部分。抖動切實發生在資料網絡中，你可以控制它，為抖動敏感的流量最小化抖動，但你不能消除它。但為什麼要在介紹延遲的部分介紹抖動？因為緩解抖動帶來影響的重要工具——去抖動緩沖區（有時也稱為抖動緩沖區）會增加延遲。
去抖動緩沖區會收集語音資料包并稍後将其播放給收聽者，也就是延遲幾毫秒後在播放語音。通過這種做法，若下一個資料包遭遇了抖動，到達的時間延後了，這時去抖動緩沖區中的資料包就可以與這個遭遇了抖動的資料包同步播放，這可以使聲音聽起來品質更好。在汽車的cd播放器中也使用了相同的工具——cd播放器會預讀幾秒鐘，因為知道汽車可能會颠簸，而cd可能會遇到暫時不可讀的情況——但cd播放器可以持續播放儲存在固态記憶體中的音樂。同樣地，去抖動緩沖區也會在語音播放前，通過收集語音來進行“預讀”，這樣被延遲的資料包就不容易引起語音的中斷。
去抖動緩沖區必須在開始播放語音前填滿，這個延遲稱為初始播放延遲，詳見圖1-22所示。
本圖展示了去抖動緩沖區中的初始播放延遲。第一個資料包到達時間，與第三個資料包到達時間，之間的時間差是可變的，在本圖所示案例中，間隔40毫秒（cisco ios網關預設将初始播放延遲設定為40毫秒）。事實上，若把初始播放延遲設定為40毫秒，那麼無論接下來的幾個資料包是否抵達，延遲都是40毫秒。考慮圖1-23所示案例，本例更深入闡述了去抖動緩沖區的工作原理。
在圖1-23中，無視其他資料包的到達時間，開始播放語音的時間以靜态設定的播放延遲間隔為準，本例中為40毫秒。40毫秒的去抖動播放延遲允許語音遭遇抖動——畢竟我們知道抖動總會發生——它能夠維持一定的速率播放語音。
圖1-24彙總了語音呼叫中的所有延遲組成部分。本圖沿用了圖1-20中的一些延遲值，同時給出了語音相關的延遲：編解碼延遲、封包化延遲和去抖動緩沖延遲。
根據g.114建議，這個延遲有些超出了可接受的單向延遲範圍，但還在cisco建議的200毫秒範圍内。不考慮額外增加的語音延遲，150毫秒延遲預算看來還是可以達到的。然而編解碼延遲和封包化延遲共30毫秒，（合理的）預設去抖動延遲（實際為去抖動初始播放延遲）有40毫秒，這幾項就占去了150/200毫秒延遲中的70毫秒。如此一來，如何能将總延遲維持在可接受的延遲預算中？你可以針對可變延遲來實施政策。表 1-17 列出了不同的延遲組成部分，并标明了哪項是可變的。
8．語音抖動考量
前文介紹延遲的部分詳細介紹了語音流與抖動的技術細節。若抖動不會降低語音呼叫的品質，那麼它就不會成為一個問題。但無論抖動快速增加還是快速降低，都會影響接收語音的模式并且丢失聲音。以圖1-25為例，資料包3和4遭遇了抖動。
在圖1-25中，第二個資料包與第一個資料包遭遇的延遲相同。如何得出這個結論的？ip電話或cisco ios網關以20毫秒的間隔發送資料包；如果資料包每隔20毫秒到達一個，那麼它們的延遲也是相同的，也就是說沒有抖動。但本例中，資料包3在資料包2到達後40毫秒才到達，這意味着資料包3遭遇了20毫秒的抖動。資料包3到達後45毫秒，資料包4才到達，由于資料包4是在資料包3發送後第20毫秒發出的，是以資料包4遭遇了25毫秒的抖動。這種情況帶來的後果是去抖動緩沖區空了，并且會産生一段靜音。事實上，資料包4出現後，接收方會丢棄這個資料包，因為相對于短暫的靜音，播放遲到的語音會帶來更大的問題。
将去抖動緩沖區的大小可視化，可以參考圖1-26所示的方法。資料包到達的時間與圖1-25相吻合，去抖動緩沖區的大小由y軸表示。
是什麼導緻了抖動？是各種延遲類型。其中兩個最臭名昭著的可變延遲是隊列延遲和網絡延遲。隊列技術可以做到盡快服務語音資料包，進而能夠降低并穩定語音資料包的隊列延遲。管理者還可以使用lfi技術将大資料包分片為多個小資料包，并且允許語音資料包穿插在這些小資料包之前獲得服務。最終，管理者需要對這些超額訂閱的幀中繼和atm網絡進行重新設計，來減少延遲。與語音和qos相關的抖動概念可以總結如下：
抖動總是發生在分組網絡中；
接收側的去抖動緩沖區可以彌補一些抖動；
qos工具，尤其是隊列工具和分片工具，可以将抖動值降到足夠低，以便使去抖動緩沖區能夠有效地提供服務；
管理者可以通過設計幀中繼和atm網絡，來減少網絡延遲和抖動。
注釋：在ip電話上按下資訊（“i”）按鈕，可以檢視抖動的狀态資訊。
9．語音丢失考量
路由器會由于多種原因丢包，其中兩個最大的原因如下：
比特錯誤；
隊列排滿。
qos對于比特錯誤無能為力，但可以對隊列空間排滿造成的丢包産生極大的積極影響。圖1-27中對比了fifo隊列（單一隊列）和一種簡單的雙隊列機制，即一條隊列用于語音負載，另一條隊列傳輸其他所有流量。
假設有4個資料包幾乎同時到達，編号1～4，其中資料包1首先到達。在fifo機制中，路由器将這些資料包以其到達的順序放入fifo輸出隊列中。若輸出隊列如圖所示，僅能排列3個資料包，會發生什麼？第四個資料包會被尾部丢棄。
現在再假設第四個資料包是語音資料包，并且使用雙隊列機制，每條隊列都能夠排3個資料包。那麼在此案例中，路由器就不會丢棄語音資料包（資料包4）。事實上，假設路由器中配置有語音隊列，該隊中的資料包會被優先轉發，進而減少了語音資料包的延遲。
注釋：最大隊列長度為3也太短了；但在圖中表示40個資料包的隊列也未免有些繁複。
圖1-27底部的案例中，路由器沒有丢棄語音資料包。但稍微深入了解雙隊列機制，才會發現它真正的強勢之處。假設呼叫準入控制（cac）隻允許這台路由器并發兩路g.729呼叫，并且假設這台路由器不使用crtp。那麼每路呼叫所需帶寬為26.4 kbit/s，共計52.8 kbit/s。現在想像一下，隊列機制總是為語音資料包配置設定最高優先級，也就是當語音資料包到達後，将“目前正在發送的”資料包發送完成後，馬上發送語音資料包。然後假設隊列機制在這個128 kbit/s鍊路上，為語音隊列確定60 kbit/s帶寬。綜合上述所有特性，語音隊列永遠不會等待很長時間（假設使用以下參數）：
隊列機制總是将語音資料包置于最高優先級；
呼叫準入控制（cac）防止并發過多的語音呼叫；
lfi允許語音資料包穿插到大資料資料包的分片前；
這個接口上的語音隊列永遠不會排滿，語音資料包永遠不會被尾部丢棄。
另一種qos工具——呼叫準入控制（cac）——是避免丢包政策中一個非常重要的組成部分，繼而可以提高語音品質。基于路由器且作用于語音的最佳隊列工具包括一系列将一部分帶寬用于語音隊列的機制。當接口還排有其他資料包時，若隊列超過最大值，則超出部分的語音資料包會被丢棄。從字面上了解，超額建立一個呼叫，就會導緻所有語音呼叫的品質降低。是以仍需考慮cac的其他形式，以避免丢失所有呼叫。
最後，當一個單獨的語音負載資料包丢失時，有另一個特性可以提供幫助。g.729編碼會通過預測未來幾毫秒的語音，來壓縮語音的有效負載部分。g.729會使用相同的邏輯來執行一個名為自動填充（autofill）_的功能，這個功能是在呼叫接收側将數字信号轉換成模拟信号時應用的。g.729自動填充特性能夠在後續資料包丢失時，對後續幾毫秒的語音做一個學術猜測。自動填充特性做出學術猜測後，可以填充30毫秒“丢失的”語音。由于在使用g.729編碼時，ip電話和ios網關預設在每個資料包中發送20毫秒的語音，是以丢失一個資料包時，g.729自動填充算法會對丢失的語音資料包進行最佳猜測，并播放猜測的語音。
與語音丢失相關的内容可以總結如下：
路由器會由于多種原因丢棄資料包；最可控的原因是由于隊列排滿而導緻的尾部丢棄；
通過隊列技術，（等時地）将語音放入其他隊列，而不是放入排滿資料流量的隊列，可以降低語音資料包遭遇尾部丢棄的幾率；
qos工具有助于保障語音品質，尤其是隊列和lfi，它們會降低語音隊列排滿的幾率，進而避免尾部丢棄；
其他qos工具能夠針對其他類型的資料包進行控制，進而保障語音品質，cac通過語音資料包來保護語音流；
使用g.729時，單一的資料包丢失可以通過自動填充算法進行補償。
在未使用qos的環境中，視訊流通常品質不高：畫面可能會不清晰，動作可能會忽動忽停或看起來像慢動作，并且通常音頻會變得和視訊不同步。可能視訊已經完全看不了了，但音頻還在繼續播放。簡而言之，除非網絡為所有流量提供足夠的帶寬，否則視訊品質總是會降低的。
與本章前文介紹語音相同，本節也把視訊流量與4個qos特征關聯起來進行分析：帶寬、延遲、抖動和丢包。首先先介紹分組視訊的基本内容，然後根據這4個qos特征，分别介紹與視訊相關的細節内容。
1．視訊基礎
ip資料包視訊可以分為以下兩大類。
互動式視訊——包括h.323會議系統，比如cisco ip/vc 3500系列産品和微軟netmeeting桌面視訊會議産品。h.323視訊會議工具使用rtp協定來傳輸音頻和視訊負載，通常使用單獨的rtp流來發送音頻和視訊。
非互動式視訊——包括網絡教學視訊服務和流媒體，産品包括cisco ip/tv、微軟windows媒體技術産品和realnetworks産品。有些非互動式視訊使用h.323标準來完成視訊呼叫的建立和拆除，而有些則不是這樣；舉例來說，realnetworks最新的伺服器使用rtsp（實時流傳輸協定，real-time streaming protocol）來完成呼叫建立和拆除，并且根據所使用的視訊播放器，通過私有的realnetworks資料傳輸（rdt）協定或rtp協定來傳輸視訊負載。
與語音編碼相同，視訊編碼負責将模拟的音頻和視訊轉換為資料包的形式。與語音延遲一樣，視訊延遲中也包含編解碼延遲、封包化延遲和去抖動初始播放延遲。視訊會使用常見的語音編碼來轉換音頻信号，其中包括g.711和g.729，并将音頻信号與視訊信号分開發送。視訊會使用多種編碼類型來轉換視訊信号，其中包括itu h.261和流行的mpeg編碼（動态圖像專家組，moving pictures experts group）。圖1-28描述了一個建立在兩台h.323視訊會議系統之間的視訊會議。
在視訊會議開始前，會發生下列事件。
使用者必須設定/點選正确的應用程式設定選項，來申請參加一個會議，通常這個步驟非常簡單，比如告訴h.323應用程式一個特定的主機名，來表明你想要參加一個會議。
vc單元必須處理h.323/h.225呼叫建立消息。
必須建立兩個rtp流——一個用于音頻，一個用于視訊。
到目前為止，語音和視訊之間的相似性超過了差異性。它們之間最大的不同在于視訊對于帶寬的要求（下面的小節“視訊帶寬考量”中介紹了視訊對于帶寬的需求）。表 1-18中總結了視訊和音頻所需的qos特征類型。
正如語音一樣，很多qos工具的功能也是盡可能為視訊負載滿足它所需的qos特征。與此同時，你可能仍希望将視訊信令流與其他資料流差別開來，也希望将視訊負載流區分對待。為了進行流量分類，qos工具需要利用資料包中的一個字段來确定這個資料包是視訊負載、視訊信令，還是其他類型的資料包。表1-19列出了用于視訊信令和負載的各種協定、定義該協定的文檔，并說明如何對其進行識别。
接下來的内容将針對4項qos特征，更詳細地介紹與視訊相關的内容：
帶寬；
延遲；
抖動；
丢包。
2．視訊帶寬考量
與語音不同，同一個視訊流中的資料包大小和資料包速率不盡相同。大多視訊編碼利用一種普遍稱之為“預測”的機制，即發送編碼過的視訊幀（大資料包）後，跟着發送一系列矢量（小資料包），用來描述前面資料幀的變化。盡管這種算法及大地降低了視訊對于帶寬的需求，但它直接導緻視訊流中的資料包速率不統一，資料包大小不統一。然而一段視訊實際所需的帶寬取決于編碼複雜性，以及視訊中的物體移動次數。表1-20列出了4種流行的視訊編碼及其所需帶寬。
不同的編碼隻是通過衡量視訊品質和帶寬需求，為管理者提供了不同的選擇，并且各種編碼都需要對所有類型的應用提供支援。舉例來說，mpeg中包含了多個标準，每個标準都是針對不同的應用類型提出的。itu h.261為視訊會議提供了一個視訊标準，這個标準适用于參會者不太移動的情況！舉一個例子，若視訊會議中講話的人肢體語言很豐富，那麼與會者可能會從螢幕上看到斷斷續續的手部運動。所有這些編碼類型都使用動态帶寬和不同的資料包大小。圖1-29顯示出h.261視訊會議呼叫中，不同大小資料包所占的百分比。
如前所述，視訊流中的資料包大小和資料包速率并不統一。比如一個高品質的視訊會議可能平均需要768 kbit/s帶寬，而真實的資料包速率可能低到35pps，也可能高達120pps。此外，管理者還需要為持續發送的視訊信令流考慮一些額外的開銷。一些qos工具配置選項可能不僅受到帶寬需求（kbit/s）的影響，還受到資料包速率（pps）的影響。要記住，隊列大小是以資料包數量來計算的；是以為了避免尾部丢棄，視訊流隊列比語音流隊列需要大得多的隊列空間。此外，cisco建議在為視訊配置隊列工具時，管理者應該配置設定多于20%的平均帶寬，來處理這一小部分易變的視訊流。cisco還建議要為視訊流保留不超過33%的鍊路帶寬。表1-21總結了語音和視訊流量在帶寬需求上的主要不同點。
3．視訊延遲考量
雙向或互動式分組視訊會與語音呼叫遭遇相同的延遲類型。但單向或流媒體分組視訊能夠忍受相當大的延遲。請考慮圖1-30中的情況，一台分組視訊裝置正在接收一個單向流媒體視訊流。
在圖1-30所示案例中，最初的播放延遲花費了30秒——不是30毫秒，而是30秒。本例中不涉及互動，也沒有視訊流傳回視訊伺服器；是以這種環境中最重要的特性是：一旦視訊開始播放了，它就擁有很高的品質。通過配置30秒的去抖動緩沖區，可以積累30秒（不是毫秒）的抖動，這樣在播放期間就不會受到延遲或抖動的影響了。
對于雙向互動式分組視訊來說，延遲肯定會影響品質。前文介紹語音和語音延遲的部分已經為你提供了與視訊延遲相關的大部分内容。視訊會遭遇編解碼延遲、封包化延遲和去抖動（初始播放）延遲。要特别注意的是，視訊延遲預算通常要求高品質的視訊會議延遲在0～200毫秒，去抖動初始播放延遲在20～70毫秒。
4．視訊抖動考量
與延遲承受能力一樣，單向視訊比雙向互動式視訊能承受更多的抖動。在規劃qos時，對于雙向視訊的處理方法應該與語音相同，也就是最小化它的延遲。此外，建議正确且精确地配置設定/部署帶寬。管理者應該給予單向流媒體視訊足夠的帶寬，它能承受更多的延遲和抖動。
與視訊網絡相關的抖動考量可以總結如下：
為互動式視訊設定的去抖動緩沖區為幾十毫秒，允許發生影響視訊品質的小抖動；
為流媒體視訊設定的去抖動緩沖區為幾十秒，允許遭遇極大的抖動，但不會影響視訊品質；
qos 工具，尤其是隊列工具和分片工具，可以将抖動值降到足夠低，以便使去抖動緩沖區能夠有效地提供服務。
5．視訊丢包考量
丢包會降低視訊流的品質。由于丢失了資料幀，畫面會變得忽動忽停或停滞，音頻也可能便變得斷斷續續。總之，視訊無法忍受丢包。
路由器會由于多種原因丢包，由于隊列排滿導緻的丢包可以通過多種qos工具來解決。記住，尾部丢棄描述的是當隊列已排滿，路由器收到了一個要放入這個隊列的資料包，這時路由器就會丢棄這個資料包。你可以通過4種基本的qos政策來降低丢失視訊資料包的風險。
啟用隊列機制，将視訊資料包放入單獨的隊列，與擁塞的資料流分開；
将視訊隊列配置得長一些；
啟用cac，來防止視訊隊列中并發過多的視訊流。換句話說，cac能夠在視訊流中保護視訊品質；
在能夠容忍丢包的資料流（通常是資料，不是視訊！）中使用red（随機早期檢測，random early detect）工具，它會降低這些資料流的發送速度，進而降低接口總體的擁塞情況。
6．語音和視訊對比：總結
表1-22對比了視訊和語音對于qos的不同需求。
本書以及與本書相關的考試，都假設你在使用本書前，已經具有相當高水準的資料流知識。實際上，cisco的qos課程假設你已經至少學習過icnd和bsci課程，并且希望你還學習過bgp課程。在cisco qos課程設立之初，是希望學生在學習本課程前已經通過了ccnp認證。
qos一直以來都是很重要的，尤其随着資料、語音和視訊融合到單一的網絡中，qos就變得更為重要。與技術融合一樣，工作在網絡通信領域的專業人士也各自有着不同的背景。本節内容是為那些不具備資料背景的工程師準備的。
注意：
若你想了解更多有關tcp/ip協定的内容，可以閱讀douglas comer最新出版的internetworking with tcp/ip一書，本書第1卷非常适合網絡工程師閱讀。還可以選擇richard stevens的tcp/ip illustrated第1卷。
與本章語音和視訊的内容類似，本節也将資料流量與4項qos特征關聯起來介紹：帶寬、延遲、抖動和丢包。接下來先介紹資料應用流的基礎知識，然後介紹與4項qos特征相關的qos細節内容。
1．ip資料基礎
在語音和視訊應用中，首先進行的是信令互動，用來建立語音或視訊呼叫。盡管在資料流中不将其稱為信令，但也确實會發生類似的步驟——舉例來說，當你打開web浏覽器輸入www.cisco.com後，在網頁的第一部分顯示出來之前，會先發生幾件事。由于我們的重點在qos，是以本書專注于實際的負載流——真正的資料——而不是關注與此相關的信令。
大多應用會使用兩種tcp/ip傳輸層協定之中的一種：udp（使用者資料報協定）或tcp（傳輸控制協定）。編寫程式的人會為應用選擇其中一個傳輸層協定來使用。大多數情況下，程式員會選擇使用标準協定，也就是使用tcp或udp。比如web伺服器使用tcp，是以在編寫web應用時，程式員會使用tcp。
tcp可以進行錯誤恢複，udp不行。要進行錯誤恢複，tcp會發送一些初始化消息來建立一個tcp連接配接，與此同時，也會初始化一些計數器，并以此用來進行錯誤恢複。圖1-31所示案例為連接配接建立階段。
tcp會在tcp標頭中，以控制字段中的2比特來表示連接配接建立完成。這2比特的控制字段稱為syn和ack控制符，這2比特有特殊有趣的含義。syn表示“同步序列号”，它是初始化tcp連接配接的必要組成部分。ack控制符表示“這個標頭中的确認字段是有效的”。
當tcp三次握手完成後，tcp連接配接就建立了，也就可以執行錯誤恢複了。圖1-32描述了在連接配接建立後，序列号和确認号是如何工作的。
如圖所示，伺服器發送資料并為其标明序列号。web用戶端向伺服器發回的tcp標頭中的确認号（4000）表明了下一個将要接收的位元組；這被稱為轉發确認（forward acknowledgment）。實質上，浏覽器會用序列号1000、2000和3000來确認收到的所有3個包（在本例中，每個資料包都包含1000位元組的資料）。序列号表示分段中第一個位元組的号碼。要記住，若資料包的序列号是3000，位元組數是1000，那麼位元組3000～3999是包含在這個資料包中的——是以浏覽器應該期待接下來收到位元組4000。
tcp還會使用視窗來控制資料的發送速率。視窗字段指定了連接配接中所允許的未确認位元組的最大數量。圖1-32所示案例中目前視窗大小為3000，後來視窗大小增加為4000（請注意在本例中，每個tcp分段攜帶1000位元組的資料）。視窗大小會随着網絡性能進行“滑動”，變大或變小，是以有時稱之為“滑動視窗（sliding window）”。當發送方發送了目前視窗規定的最大位元組數之後，它必須等待對方的确認，這個機制對資料流實施了一定的控制。這個機制的效率很高，因為目前可用視窗的大小會随時随着發送的位元組數量增加而減小，并且随着收到的确認位元組數量增加而增加。
tcp和udp之間最大的不同之處在于tcp可以執行錯誤恢複。是以有些人認為tcp是可靠的，udp是不可靠的。要知道，語音流和視訊流使用rtp，同時也使用udp——為什麼語音和視訊要使用一個如此不可靠的協定呢？答案很簡單：若使用tcp來傳輸語音或視訊資料包，tcp能夠意識到資料包的丢失情況，并且在丢包時會進行重傳，這種機制會帶來過多的延遲，進而重新發送語音或視訊資料包是沒有任何意義的。然而對于資料應用來說，即使確定所有資料都到達可能會花費更多的時間，也要保證所有的資料都确實到達了連接配接的另一端，這種情況下，tcp就更為适用了。圖1-33給出了tcp錯誤恢複邏輯的基本概念。
圖1-33描述的傳輸案例中，第二個tcp分段丢失了，或存在錯誤。web用戶端的回應消息中的ack字段為2000，表示web用戶端接下來希望收到位元組數為2000的資料包。這時web伺服器中的tcp功能就可以恢複丢失的資料，也就是重新發送第二個tcp分段。tcp協定允許web伺服器隻發送這第二個分段然後等待，期望從web用戶端收到回應消息，并且确認值為4000。
最後，在去參加qos考試之前，你還應該了解tcp和udp的一個特性。這個特性與tcp和udp頭部中的字段相關，這部分字段稱為“源和目的端口号（source and destination port numbers）”。我們可以通過一個簡單的案例來了解端口号的作用；對于qos來說，端口号可以用來區分資料包，也就是說允許路由器或交換機針對不同的資料包應用不同的qos行為。在接下來的案例中，漢娜正在使用3項應用，伺服器傑西為這3項應用提供服務。這個公司編寫了一個廣告應用程式和一個電彙應用程式，目前都在使用中。此外，漢娜還正在使用一個基于web的應用程式，如圖1-34所示。
接收到資料包後，傑西需要知道将資料包中的資料交給哪項應用，但3個資料包來自同一個以太網和ip位址。你可能認為傑西會檢視資料包攜帶的是udp還是tcp，以此來進行區分，但從圖中可以看出，有兩項應用（電彙和web）都使用tcp。當然了，udp和tcp的設計者故意在tcp和udp頭部添加端口号字段，就是為了進行複用。“複用”這個術語通常用來表示一種能力：即能夠确定應用該從哪個資料包中擷取資料。每項應用使用不同的端口号，進而傑西知道如何為不同的應用提供資料，如圖1-35所示。
很多衆所周知的應用使用衆所周知的端口号，比如web、ftp、tftp、telnet、smtp、pop3等。如果在使用一項應用前，你需要詢問其他人，來獲得該應用使用的端口号，那也太麻煩了。正因為有了這些衆所周知的端口号，我們就可以假設（比如）這個web伺服器使用80端口。對于qos工具來說，若你想将web流量分類出來，隻需檢視使用端口80的資料包即可。
當然了，可能在你的職業生涯中，會不斷學習并使用tcp/ip架構中的所有協定。前述的簡短介紹僅為你提供了一點背景知識，有助于你繼續閱讀後續章節。表1-23列出了tcp和udp的重點内容。
接下來的内容将針對4項qos特征，更詳細地介紹與資料相關的内容：帶寬、延遲、抖動和丢包。
2．資料帶寬考量
語音需要消耗一定量的帶寬，視訊需要消耗一個小範圍内的帶寬，與上述兩者均不同，資料對于帶寬的需求範圍非常大。有些應用可能隻需要不到1 kbit/s的帶寬，而有些應用可能會消耗掉你能提供的所有帶寬。
對于資料帶寬來說，最大的問題是圍繞osi第8層——業務層提出來的。比如說應該為web流量配置設定多少帶寬？要知道，在很多辦公場所，web流量消耗了可用網絡帶寬的80%。那麼更好的問法可能是“應該為重要的業務web流量配置設定多少帶寬？”對于與财政計劃相關的web應用來說，通路espn.com（檢視最新比分）這類應用不應該具有很強的競争力。比如股票經紀商在檢視股票報價時會希望獲得最低延遲，而我可能隻需等待得稍微久一點，才能看到最新的體育比賽比分。
應該為資料應用流考慮的其他合理問題是：這個應用是否為互動式。互動式應用通常（不總是這樣！）比非互動式應用需要更少的帶寬。最常見的對比來自于telnet（使用非常少的帶寬）和ftp（消耗你提供的所有帶寬），這表明了互動式應用消耗較少的帶寬。當然了，現在很多互動式應用都是基于web的，如果web頁面中包含有大量圖檔，那麼它對于帶寬的需求也是相當可觀的。
資料流的帶寬、延遲、抖動和丢包考量會根據這些或那些因素而變化。實際上，同一個資料應用的qos特征可能會在兩個公司之間顯示出明顯差别！這是因為有太多的因素需要考慮并且這些因素會因網絡而異，是以沒有一組需求總是适用于所有環境。
但是不要絕望！你應該至少從一個方面來考量帶寬需求：商業角度。簡單地說，有些應用是關鍵業務，而有些則不是。是以qos政策至少應該包括：識别關鍵應用，并為其賦予所需要的qos特性。而其他資料流量則不在考慮之列，或者用qos術語來說，它們就是“盡力轉發（best-effort）”流量。表1-24總結了3種流量類型在帶寬需求上的主要不同。
3．資料延遲考量
與語音和視訊不同，資料應用的品質并不會由于突然增加了區區幾百毫秒的延遲而降低。事實上，相比于語音和互動式視訊，資料應用對于延遲的承受能力是非常強的。還有一點與語音和視訊不同，資料應用往往會對往返延遲有要求。
表1-25總結了會對資料應用的延遲産生影響的兩個因素。
由于資料對于qos的需求變化性很大，是以在決定如何為各種應用實施相應的 qos時，員工之間會進行更多的溝通。溝通增加了，傳達錯誤消息的幾率也增加了。比如在詢問一個并不關注網絡的員工的意見時，他可能會說“對于這個關鍵任務應用，我們需要穩定的1～3秒響應時間！”他的意思是說為了使使用者看到從應用發來的完整響應，雙方向上需要發送的所有資料包延遲在1～3秒。當使用者要求1～3秒的應用響應時間時，千萬别天真地認為他指的是一個資料包的單向延遲是1～3秒。
資料應用與語音和視訊流遭遇的延遲類型不同。前文介紹過了一些核心的延遲組成部分——隊列延遲、串行化延遲、傳播延遲、網絡延遲、處理延遲和整形延遲。資料流不會受到編解碼延遲、封包化延遲和去抖動緩沖延遲的影響。
4．資料抖動考量
與延遲相似，資料應用忍受抖動的能力也比語音和視訊強很多。互動式應用對于抖動的容忍能力很差。我是在ibm一個大型的sna網絡中學習的網絡互連技術，當調試路由和qos（早前内置在sna中，但這就另當别論了！）時，有一句諺語是這麼說的“隻要響應時間是同步的，就可以接受很長的響應時間”。出于某種原因，人類本性決定了在人們的互動中，連貫性遠遠比響應時間更為重要。
互動式資料應用無法像非互動式應用那樣忍受那麼多的抖動或延遲。而語音和視訊應用可以忍受的抖動或延遲甚至比互動式資料應用還要少。正因為語音和視訊無法忍受哪怕很小的延遲和抖動，工程師需要使用qos工具來為語音和視訊降低延遲——這樣做會反過來增加資料應用的延遲和抖動！舉例來說，如果路由器接下來要發送語音包而不是資料包，那麼語音包能夠獲得合理延遲預算的可能性就比資料包大——同時資料包會遭遇更多的延遲。由于知道了資料比語音能夠承受更多的延遲和抖動，工程師就可以在這方面做些折中。
資料網絡的抖動考量可以總結如下：
資料應用沒有去抖動緩沖區，使用者總是會經曆一定的抖動，他們僅僅會意識到響應時間不一緻；
互動式應用對于抖動的容忍度較低，但即使如此，幾百毫秒的抖動仍不會影響互動式應用；
在融合網絡中，管理者總是通過qos工具來增強（降低）語音和視訊流的抖動，這樣做帶來的負面影響是增加了資料應用的延遲和抖動。
5．資料丢包考量
與語音和視訊不同，資料應用并不總會受到丢包的影響。對于多數應用來說，它需要獲得所有資料；若丢失的資料包被重新發了過來，就并不會造成什麼實際損失。而另一些應用甚至根本不關心資料包是否丢失。為了透徹地分析，我們将資料應用分為以下 3 類：使用udp且執行錯誤恢複的應用、使用udp且不執行錯誤恢複的應用和使用tcp的應用。
使用udp且執行錯誤恢複的應用
有些應用需要錯誤恢複特性，但選擇通過應用代碼來實作錯誤恢複。比如nfs（網絡檔案系統）和tftp（簡單檔案傳輸協定）都是用udp，并且都在應用内部執行錯誤恢複。nfs允許從遠端檔案伺服器讀取并寫入資料，保證資料不丢失對于nfs來說極為關鍵！同樣地，tftp用來傳輸檔案，確定檔案的任何部分都不丢失也是極為重要的。是以這些udp應用會提供應用層錯誤恢複，來提高對丢包的耐受度。
使用udp且不執行錯誤恢複的應用
有些應用就是不需要錯誤恢複。最常見的這類協定有snmp（簡單網絡管理協定），它允許網路管理軟體查詢被管理裝置的資訊。網絡管理工作站檢索的資料量非常龐大，很多時候，偶爾錯過一些統計資料也并不會影響管理者使用管理軟體。snmp的設計者特意避免使用tcp和應用層錯誤恢複機制，就是為了確定snmp的簡單結構，進而使其更具備可擴充性，要知道snmp會應用在各種場合中。由于這種應用并不關心是否有丢包，是以它對丢包的耐受度很高。
使用tcp的應用
由于基于tcp的應用可以依賴tcp來恢複丢失的資料包，是以能夠接受較高的丢包率。盡管對于使用者來說丢包并重傳的過程是透明的，但由于重傳資料包而為網絡添加的負載也确實會加重網絡擁塞的情況。
6．語音、視訊和資料對比：總結
表1-26總結了資料對于qos的需求，并對比了語音和視訊的相關需求。
1該書第2版已由人民郵電出版社引進并出版，中文書名為《voip技術構架（第2版·修訂版）》。——譯者注
2 cisco unified communications manager曾稱為callmanager，本書使用縮寫cucm。——譯者注