QoS：說好一起到白頭，你卻偷偷焗了油

本文轉載自微信公眾號“ 標哥說天下”(ID：bgstx001)，作者：李宗標。

本文僅僅涉及 IPv4 和MPLS 網路(以下簡稱 IP/MPLS)的 QoS，不會涉及其他網路。另外，本文期望從基本概念與原理入手，而不是深入到具體的網路協議細節和演算法細節，能給出一個淺顯易懂而又不失其本質的 QoS 講述，使您能比較輕鬆地掌握 QoS 基本知識。

由於筆者水平有限，難免掛一漏萬，即使限定在 IP/MPLS，筆者仍然覺得本篇文章不夠全面。筆者爭取後面再寫兩篇文章，一篇是 QoS 綜述，另一篇是QoS 的網路協議和演算法，分別從寬度和深度兩個角度來探討 IP/MPLS 的QoS 體系。

這一篇，就讓我們 Happy 一下吧——希望能給您帶來快樂!

一、從使用者體驗看 QoS

網路不生產內容，它只是內容的搬運工。網路的運營者，比如中國移動等，稱為網際網路服務提供商(ISP，Internet Service Provider)。既然是服務提供商，那就得講究服務質量。在這個層面，DaaS(東莞就是服務)曾經是服務行業中的質量的典型代表。非常遺憾，這個典型代表已經被當作典型給那啥了。

在網路從業人員的口中，QoS(Quality of Service，服務質量)專指網路的服務質量。

在早期，網路上傳輸的一般是資料業務，比如檔案傳輸，email等，這些業務對 QoS 的要求一般就是網路頻寬(更專業一點的術語叫網路“吞吐量”)和可用性(不能動不動就斷網)。

現在網路上傳輸的業務是豐富多彩，比如語音、影片、網遊等等，這些業務除了對頻寬、可用性有要求以外，還對網路的時延、丟包、抖動有嚴格的要求。

對於語音而言，當時延超過300毫秒時，互動式會話(雙方打電話)會變得非常麻煩，一方會以為另一方沒有說話。

　　延時太大，接聽方會以為說話方沒有說話

抖動是時延的變化。A 勻速對 B 說“XYZ”三個字母，如果三個字母的時延相同，比如都是100ms，那麼 B 聽到的聲音也是勻速連貫的，雖然有時延。但是如果三個字母的時延分別是50ms、200ms、150ms，B 所聽到的聲音就會產生不連貫的效果。

由於抖動，說話者和接聽者所感受到的斷句是不同的。丟包對於語音來說，也不可接受，比如“XYZ”傳到 B 那裡，由於丟包的原因，誇張點說，會變成“XZ”，中間漏了一個“Y”。對於影片來說，丟包會產生馬賽克，非常影響影片體驗。

總的來說，各種應用對於 QoS 的要求，可以總結為表1所示：

　　表1：各種應用對 QoS 的要求

表1僅僅是一個概括性的表述，不能當做絕對真理。比如檔案傳輸，當然也是希望頻寬越大越好啊。

　　永遠不要忽略一輛卡車的頻寬

產生時延的因素很多，主要包括編碼、包化、佇列、序列化、和傳播時延等。模擬訊號(比如聲音)要被編碼成數字訊號，需要時間，這就是編碼時延。數字化以後，還需要打成 IP 報文，這個時間就是包化時延。路由器在傳輸 IP 報文時，需要將報文放置到各個佇列中然後排程，這其中所花費的時間就稱為佇列時延。報文被排程傳送時，可能會等待上一個大報文先傳送出去，這個等待時間就是序列化時延。這些時延，可以隨著技術的進步而最佳化減少，但是傳輸時延則是無論如何也無法減少的，因為傳輸速度不能超過光速。光速1秒鐘30萬公里，那麼300公里1ms的時延，是無論如何也減少不了的。

　　傳輸時延是無法避免的

本文講述的是 IP/MPLS 的 QoS，所以下文會重點講述佇列時延。實際上，丟包也與佇列有著密切的關係，下文會一併講述。

二、IP/MPLS 協議對 QoS 的標記

如果網路頻寬無限大，網路轉發無限快，那麼拋開前文所說的“編碼、包化”不談(不是本文主題)，網路的時延(包括丟包、抖動)除去無法克服的傳輸時延以外，就會等於0，一切都很美好。

可是，這是不可能的，最起碼目前來看，是不可能的。這就存在競爭的問題：不同的業務流對有限的網路資源的競爭問題。

在這個競爭中，網路對於各個業務流是否公平對待呢?答案是否定的。既然不是公平對待，那麼網路是如何做到厚此薄彼的呢?這就涉及到網路整體的QoS 解決方案。本小節首先講述這個解決方案中很重要的一環：IP/MPLS 協議對 QoS 的標記。

所謂標記，就是讓網路知道一個業務流是重要還是不重要。在人類社會，要想被別人喜歡，男人靠事業，女人靠事業線。在網路社會，卻沒有這一套，要想讓路由器知道你很重要，必須得有所標記。IP/MPLS 中不同的協議，對QoS 的標記有所不同，下面我們逐一講述。

1、IP 報文對 QoS 的標記：IP 優先順序(IP Precedence)

在 IP 報文裡，IP 優先順序(IP Precedence)位於 IP 報文頭中的 ToS 欄位，如圖1所示：

　　圖1：ToS 在 IP 報文頭中的位置

ToS 的欄位長度是8 bits。根據RFC1122的定義，IP優先順序(IP Precedence)使用最高3位元，可以定義8個服務等級。第3到第5位元由RFC791定義，後來RFC1349又擴充套件到第6位，3~6為位元被稱為稱為DTRC(Delay，Throughput，Reliability，Cost)位，。最後1位元必須為0(Must Be Zero)。如圖2所示：

　　圖2：ToS 欄位的定義

IP優先順序佔用 ToS 最高的3個bit，一共可以取8個值，這8個值的含義，如表2所示：

　　表2：IP 優先順序的含義

DTRC(Delay，Throughput，Reliability，Cost)位，忙活了半天，一會3個bit，一會4個bit，但是並沒有什麼卵用，QoS 並沒有採用它，不過我們還是列舉一下它的含義吧。第3到6位元的含義如下：

0000--normal service

1000--minimize delay

0100--maximize throughput

0010--maximize reliability

0001--minimize monetary cost

2、IP 報文對 QoS 的標記：DSCP(Diffserve Codepoint)

ToS 欄位一共8個bit，IP 優先順序只使用了其中3個bit，一共只能定義8個優先順序(QoS 沒有采用 DTR)，這似乎少了一點。RFC2474重新定義 IPv4報頭中ToS 欄位，它使用了高6為bit，後2位保留，如圖3所示：

　　圖3：DSCP 的定義

RFC2474 把高6為稱為差分服務程式碼點(DSCP，Differentiated Services Code Point)。簡單理解，DSCP 也是表示優先順序，由於使用了6個bit，可以表達64個優先順序。

64個優先順序，是對原來的8個優先順序的一種細化，不是顛覆，所以它們之間有一定的對應關係，如表3所示：

表3：IP 優先順序與 DSCP 的對應關係

當然，提出 DSCP 的概念，絕不是為了與 IP 優先順序有一個對應關係，而是為了對 IP 優先順序的細化。由於 DSCP 優先順序有64個，數字太多，不好記憶，於是 DSCP 還有另外一種表達方法，方便人的閱讀和理解。(個人觀點，64個其實不多，多一種表達方法，多一種概念，增加了人們的學習成本，其實不太好)

DSCP 的數值 0~63，分為四類，如表4所示：

表4：DSCP 的含義

可以看到，DSCP 雖然取值範圍是0~63，但是實際上只使用了24個值。

有一個快速理解 DSCP 的方法：(雖然是快速理解，但是還需要仔細閱讀)

(1)如果 DSCP 為0，則為 BE;如果為46，則為 EF。

(2)將 DSCP 的值，除以8，其商為服務優先順序(對應IP 優先順序)，如果其餘數為0，則為 CS，記作 CSn(n為商)，比如24，記作CS3。

(3)將 DSCP 的值，除以8，其商服務優先順序(對應IP 優先順序)，如果其餘數不為0，則為 AF。餘數為2、4、6，分別表示丟包優先順序為Low、Middle、High，用數字1、2、3表示。整體記作 AFmn(m為服務優先順序，n為丟包優先順序)。比如 DSCP = 34，記作 AF41。

DSCP 的數值與 IP 優先順序以及其所適用的業務型別，如表5所示：

表5：DSCP 與 IP 優先順序的對應關係及適用的業務型別

3、802.1P 對 QoS 的標記：Priority

IEEE 802.1P 是一個有關 LAN 二層的流量優先順序的 QoS/CoS() 的協議(LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization )。802.1P 是 IEEE 802.1Q (VLAN 標籤技術)標準的擴充協議，它們協同工作。IEEE 802.1Q 標準定義了為乙太網 MAC 幀新增的標籤。VLAN 標籤有兩部分：VLAN ID (12位元)和優先順序(3位元)。 IEEE 802.1Q VLAN 標準中沒有定義和使用優先順序欄位，而 802.1P 中則定義了該欄位，如圖4所示：

　　圖4：802.1P 中的優先順序

802.1P 定義的優先順序(Priority)位於 802.1P 的報文頭中，佔用3個bit，一共可以表示8個優先順序。最高優先順序為7，應用於關鍵性網路流量，如路由選擇資訊協議(RIP)和開放最短路徑優先(OSPF)協議的路由表更新。優先順序6和5主要用於延遲敏感(delay-sensitive)應用程式，如互動式影片和語音。優先順序4到1主要用於受控負載(controlled-load)應用程式，如流式多媒體(streaming multimedia)和關鍵性業務流量(business-critical traffic)。優先順序0是預設值。

我們可以把802.1P 定義的優先順序簡單理解為 IP 協議中的 IP優先順序(IP Precedence)。另外，乙太網(比如 802.1P)中一般說CoS(Class of Service，服務等級)，這個與 QoS 還是有所不同，這裡我們不做這個方面的細究，也簡單理解為一個意思。

4、MPLS 對 QoS 的標記：Experimental

MPLS 對 QoS 的標記，使用的是 MPLS 頭部的 Experimental 欄位，這個欄位佔有3個 bit，雖然號稱是實驗欄位，但是一般被 MPLS 用作 QoS/Cos 的標記，如圖5所示：

　　圖5：MPLS 中的 Experimental 欄位

MPLS 的 EXP 欄位佔用3個 bit，能夠表達8個優先順序，我們也可以將其簡單理解為與 IP優先順序(IP Precedence)是對等的。但是這樣不夠準確，更準確的理解應該是與 IP 的 DSCP 相對應。不過 DSCP 最多等表達64個優先順序(實際使用了24個)，而 MPLS 的 EXP 卻只能表達8個優先順序，這是 MPLS 的退化還是另有玄機呢?答案是後者(另有玄機)，具體的描述我們放在後面再介紹。

5、IP/MPLS 協議對 QoS 的標記的小結

我們介紹了 IP/MPLS 協議對 QoS 的標記，由於 VLAN 是一個非常普遍使用的協議，所以我們也介紹了 802.1P 對 QoS 的標記。它們的小結，如表6所示：

表6：IP/MPLS 協議對 QoS 的標記的小結

透過以上介紹，我們知道：從 A 發往同一個地方(比如 B)的兩條流，由於兩者的業務型別不同，賦予它們的優先順序也會不同。網路針對這兩條流，會採取不同的轉發策略，從而有可能使兩者的 QoS 會有很大的不同。優先順序低的流，不僅有可能時延會相對變大，還有可能會丟包。網路中的流如果有感情的話，不知道它們會怎麼想!

說好一起到白頭，你卻偷偷焗了油！網路偏愛焗了油的流，那麼它是怎麼偏愛的呢?

三、路由器的 QoS 模型

網路作為一個整體，它有一整套的 QoS 解決方案，在這個解決方案中，每一個路由器都有它的角色和行為。本節我們先介紹單個路由器的 QoS 模型，下一節再整體介紹網路的解決方案。

對於單個路由器而言，它針對 QoS 的行為包括如下幾個方面：

(1)流的佇列機制(含流分類與丟包機制)

(2)流的監管和整形機制

下面我們分別展開講述。

1、流的佇列機制

路由器並不是一根管子，業務流從這端流入，從那段流出，它總要做一些處理(具體是哪些處理，與本文主題無關，就不描述了)。為了做這些處理，業務流需要在路由器裡呆一小段時間(很不幸，這一小段時間就產生了時延)。業務流在路由器所呆的空間，就是記憶體。把記憶體按照一定的規則分塊，這些分塊就稱為佇列。

什麼樣的流進入什麼樣的佇列，不同佇列中的流誰先被髮送出去，如果佇列滿了，新來的流該如何處理，這些問題的答案都與路由器的流佇列機制相關，也與 QoS 密切相關。一個路由器抽象的流佇列機制，如圖6所示：

　　圖6：路由器的抽象佇列機制

為了易於描述和理解，圖6簡化了模型，僅僅是表達了從一個入口(A)到一個出口(B)的佇列機制。

一個流從入口進入路由器後，在佇列機制層面，會經過如下過程：

(1)首先經過流分類器。流分類器根據一定的規則，將流分配到不同的佇列中。

(2)佇列也不是無條件接收流分類器轉過來的流，因為它自己如果佇列滿的話，也是無能無力。如果能夠接納流，則流還存在一個在佇列中如何排隊的問題(排隊靠前的，會被先轉發出去)。

(3)流進入佇列以後，還得等待佇列排程器排程。排程器也根據一定的規則，決定各個佇列的流先後轉發順序。

(4)佇列被排程以後，佇列中的流會被從出口轉發出去。

根據流分類規則、丟棄規則、排程規則等的不同，IP/MPLS 網路有FIFO、PQ、CQ、WFQ、CBWFQ、LLQ、IP RTP Priority 等幾種佇列，下面分別展開描述。

1.1、FIFO 機制

FIFO，First In First Out，先入先出佇列。顧名思義，FIFO 佇列就是“六親不認”，管你是什麼型別的流，管你有沒有焗油，它根本就沒有流分類器，它的排程器就是隻管按照流到達的先後順序，誰先來，誰先走，揮一揮衣袖，不挽留。FIFO 佇列的示意圖，如圖7所示：

　　圖7：FIFO 佇列示意圖

從圖7可以看到，即使是緊急報文，它只要來晚了，也得老老實實在那排隊，乾著急也沒用。

FIFO 佇列採用尾丟棄策略(Tail-Drop polocy)，即如果佇列滿了，那麼後來的報文將被丟棄。

FIFO 非常簡單，它的缺點，表面上看也是很明顯的，對於時延敏感的報文，它並不能提供有效的保障。不過如此簡單的 FIFO 卻能給我們很多思考：(1)FIFO 在 QoS 層面，並不是一無是處，正是因為省略了流分類機制以及它的極簡的排程機制，它反而還節省了處理時間，減少了時延。如果能在一個區域網內保證網路的能力，FIFO 反而有可能時最佳選擇。

(2)公平從來不是簡單的問題。表面上看，FIFO 講究先來後到，好像很公平。但是即使不做深入探討，即使只考慮現實生活中的“女士優先”、“緊急通道”等場景，我們就會發現如果只考慮先來後到，並不意味著就是公平。

不過無論如何，FIFO 這種六親不認的表現，還是高度體現了一種二桿子精神。哥不扶牆，舅扶你!

1.2、PQ 機制

PQ，Priority Queuing，優先佇列，從某種意義上說是對 FIFO 的一種糾正，不過好像有點用力過猛，矯枉過正。透過 FIFO 的描述我們知道，在當前網路的能力下(能力不足)，FIFO 對於時延敏感的業務流，是不能提供有效的保障的。PQ 的使命，好像就是為了保證某些流的時延而生的。

PQ 的原理示意圖，如圖8所示：

　　圖8：PQ 原理示意圖

PQ 將佇列分為4種型別，分別是：high、medium、normal、low，優先順序是由高到低。

PQ 的佇列排程演算法是：先從最高優先順序佇列 high 佇列排程，待 high 佇列裡面的報文傳送完畢以後，再排程 medium 佇列，以此類推，最後排程 low佇列裡的報文。(如果在排程低階佇列時，高階佇列如果有報文來到，高階佇列會搶佔低階佇列，先被轉發出去)。

PQ 的佇列分類演算法，相對固定，而又有一定的靈活性。相對固定的意思是：如果是 IP 報文，無非是根據流的五元組(源IP地址、源埠、目的IP地址、目的埠、傳輸層協議)和 IP 優先順序/DSCP 等欄位將流進行分類;如果是MPLS 報文，就是根據 EXP 欄位將流進行分類。有一定的靈活性是指：在這些分類條件中，使用者可以選擇其中一個或多個進行組合。

PQ 有4個佇列，針對每一個佇列內部，它仍然採取 FIFO 策略和尾丟棄策略。

可以看到，PQ 對於時延敏感的業務流，有著非常好的保障，只須把該型別業務流分類到 high 佇列，它們就有著無法比擬的優勢得到先發。但是，PQ 也有著非常明顯的缺點，對於那些不幸排在 low 佇列的流來說，可能永無機會被髮送出去，產生所謂的“餓死”現象。這就是網路世界的“朱門酒肉臭，路有凍死骨”吧。

1.3、CQ 機制

CQ，Custom Queuing，定製佇列。也許是覺得 PQ 有點過分吧，CQ 是對PQ 的一種改進。它的流分類機制，與 PQ 一樣，只不過它提供了17個佇列，可以分得更細。CQ 的原理示意圖，如圖9所示：

　　圖9：CQ 原理示意圖

CQ 是絕對優先排程佇列0，待佇列0排程傳送完以後，再排程其他16個佇列。所以，流分類時，一般是將路由協議報文分類到佇列0。

對於其他16個佇列，CQ 是按順序按比例迴圈排程傳送。按比例的意思是將每個佇列分配一定的頻寬比例(嚴格地說，不是頻寬，而是位元組數。這裡用頻寬來類比，是為了易於描述和理解)，比如佇列1分配2M，佇列2分配3M......，那麼佇列1排程傳送1M的報文後，就會轉而排程佇列2......以此類推。

CQ 有17個佇列，針對每一個佇列內部，它仍然採取 FIFO 策略和尾丟棄策略。

CQ 從某種意義上說，解決了 PQ 的極端不公平的“餓死”現象，不過這不是絕對的。因為 CQ 中每個佇列的比例，是可以自由配置的，比如把佇列1配置為1000，佇列16配置為1，其他佇列配置為100，那麼佇列16也是很大機率會“餓死”。

可以這麼理解，CQ 比 PQ 的分類更細，排程原則更靈活一點，但是仍然可能會存在“分配不公”的現象。當然，所謂分配不公，是人類對網路業務流的一種“擬人”的說法，在實際應用中，如果網路資源不夠，必須有所取捨的時候，那就不是所謂的公平的問題，而是丟卒保車的問題。如何丟卒保車?你的地盤你做主!

1.4、WFQ 機制

WFQ，Weight Fair Queuing，加權公平佇列。WFQ 最大的特點還不是“加權公平”這幾個字，而是它不允許使用者透過 ACL 對流進行分類(前文介紹的幾個佇列機制，都是由使用者自己對流進行分類)，而是它自己分類。

當然，WFQ 的流分類原則，也沒有什麼特殊的，無非還是五元組之類的內容。但是，WFQ 是將一個流歸結到一個佇列，所以 WFQ 所需要的佇列數量很多，它最多可以有4096 個佇列。

WFQ 關於佇列的排程策略，正如其名字所暗示的：Fair，公平;Weight，加權。首先不考慮加權，WFQ 對於每個佇列(其實也就是每條流)的排程是公平的，也就是迴圈平等排程。然後再考慮加權，WFQ 考慮的是每個流的 IP 優先順序的權重。它的計算方法是：

一條流的權重 = (該流的 IP 優先順序 + 1)/ sum(所有流的優先順序 + 1)。

正是這種加權、公平的思路，對 IP 優先順序高的業務的時延有一定的保證，也能對優先順序較低的業務，不至於“餓死”。

為了實現這個思路，WFQ 有一個演算法，這個演算法不復雜，不過筆者猶豫了半天，決定還是不介紹了，這對綜合理解 QoS 沒有多少幫助，反而還有點陷入細節。

WFQ 最多可以有4096 個佇列，針對每一個佇列內部，它仍然採取 FIFO策略。但是它的丟棄策略，所採用的不是尾丟棄策略，而是對尾丟棄的一種改進，我們稱之為 WFQ 丟棄策略吧。WFQ 丟棄策略的演算法與 WFQ 的排程演算法強相關，這裡也不再詳細介紹，只須這麼簡單理解：當一個佇列滿的時候，它可以丟棄其他佇列的報文(從而搶佔該佇列的記憶體空間)。這也是為了保證高優先順序的業務質量。

1.5、CBWFQ 機制

CBWFQ，Class-Based WFQ。其實基於這個這個名字，反而不好理解。更直觀，更好的理解方法是：把 CBWFQ 當作前面介紹的 CQ(Custom Queuing)的擴充套件版本。CBWFQ 的原理示意圖，如圖10所示：

　　圖10：CBWFQ 示意圖

說 CBWFQ 是 CQ 的擴充套件版，是因為：

(1)兩者的流分類方法是一樣的，只不過 CQ 只有17個佇列，而 CBWFQ有 65 個佇列。CBWFQ 可以將流明確地分為64類，分別歸入到佇列1~佇列64，然後再將其他所有的流歸為佇列0。

(2)CBWFQ 的65個佇列，與 CQ 的16 個佇列(佇列1~佇列16)的排程策略幾乎是一樣的：CQ 給每個佇列分配位元組數，CBWFQ 給每個佇列分配頻寬比。不看細節的話，這其實沒有什麼不同，兩者都是給每個佇列分配一定的比例。

不過，兩者還是有一定的不同：

(1)針對每一個佇列，CQ 都是 FIFO 和尾丟棄策略。CBWFQ 的 1~64 佇列，必須是 FIFO，而佇列0卻可以是 FIFO 或者 WFQ。如果是 FIFO 的話，CBWFQ 的每一個佇列都可以選擇尾丟棄策略或者是 WRED 策略(WRED：Weighted Random Early Detection，先記住這個詞，下文會解釋其含義，這裡暫時不糾結)。佇列0如果選擇 WFQ 的話，那麼它的丟棄策略，當然也是 WFQ 丟棄策略。

(2)CQ 有一個佇列0，一個絕對優先順序的佇列，可以為路由協議(也可以包括語音影片等)的轉發服務，而 CBWFQ 沒有這樣一個明確的佇列。

可以看到，CBWFQ 花了不少心思，將 CQ 和 WFQ 做了疊加，並且在丟棄機制上還引入了 WRED，但是好像失去了 CQ 和 WFQ 的精髓：

(1)CQ 有佇列0，可以保證相關業務流的時延，CBWFQ 丟失了這個特性

(2)WFQ 是基於 IP 優先順序的加權，也能在一定程度上保證相關業務流的時延，CBWFQ 也失去了，雖然它的佇列0可以採用 WFQ 機制，但是相對於一共65個佇列而言，那毫無意義。

1.6、LLQ 機制

LLQ，Low Latency Queuing，低時延佇列。如果說不知道 CBWFQ 想幹嘛，那麼 LLQ 則用它的名字明確地告訴你它想幹嘛!

嚴格來說，LLQ 並不是一個獨立的佇列機制，它是對 CBWFQ 的一種增強——是的，增強!

前文說過，CBWFQ 費了半天勁，吃力沒討好，邏輯複雜，卻不能保證時延敏感的業務。LLQ 則是在 CBWFQ 的基礎上增加了1個或多個優先順序佇列。這幾個優先順序佇列之間，不再區分優先順序，而是採用迴圈排程的方式。但是這幾個佇列相對於其他佇列而言，則有絕對的優先順序，與 PQ 類似，這幾個優先順序佇列必須先排程轉發。與 PQ 不同的是，LLQ 的這幾個優先順序佇列設定了閾值，也就是說優先排程這幾個佇列，但也不是無限優先，它們被排程轉發一定的資料包以後，就可以轉發其他佇列。這樣能防止 PQ 機制所產生的“餓死”現象。

天下沒有免費的午餐，如果要想保證其他佇列不餓死，那麼優先順序佇列就可能傳送能力不足，從而產生丟包現象，這又與 LLQ 的初衷相違背。糾結......

1.7、IP RTP Priority 機制

IP RTP Priority 與 LLQ 一樣，它的目的也是明確地寫在名字上。為了解釋這個機制，首先稍微解釋一下 RTP。

RTP 全名是Real-time Transport Protocol(實時傳輸協議)。它是IETF提出的一個標準，對應的RFC文件為RFC3550(RFC1889為其過期版本)。RTP用來為IP網上的語音、影像、傳真等多種需要實時傳輸的多媒體資料提供端到端的實時傳輸服務。RTP位於UDP之上，UDP雖然沒有TCP那麼可靠，並且無法保證實時業務的服務質量，需要RTCP(Real-time Transport Control Protocol，實時傳輸控制協議)實時監控資料傳輸和服務質量，但是，由於UDP的傳輸時延低於TCP，能與影片和音訊很好匹配。因此，在實際應用中，RTP/RTCP/UDP用於音訊/影片媒體，而TCP用於資料和控制信令的傳輸。RTP在埠號1025到65535之間選擇一個未使用的偶數UDP埠號(埠號5004和5005則分別用作RTP和RTCP的預設埠號)。

IP RTP Prioritization 與 LLQ 的機制也基本一樣，有所不同的是，LLQ是基於 CBWFQ 的增強，而 IP RTP Priority 既可以基於 CBWFQ，還可以基於WFQ 進行增強。兩者的對比情況，如表7所示：

表7：IP RTP Prioritization 與 LLQ 的對比

1.8、流的佇列機制小結

前文一共介紹了7種流的佇列機制，總結如表8所示：

表8：流的佇列機制小結

可以看到，這些佇列機制，除了 FIFO 有王之蔑視根本不管什麼優先順序不優先順序的、CBWFQ 忙活了半天不知道幹嘛的二哈之謎以外，其餘的佇列機制，基本上是為低時延業務操碎了心!

不過在網路資源有限的情況下，這些佇列機制告訴我們：

公平是沒有的，兼顧是不可能的!網路的世界，也是人類的世界!人類爭奪有限的資源時，會有戰爭，會有殺戮!網路世界一樣有殺戮。當網路擁塞時，報文就會被丟棄。

2、網路防擁塞機制：報文的丟棄

在前文講述流的佇列機制時，提到了丟棄策略，有的是尾丟棄(Tail Drop)，有的是 WRED。

路由器丟棄過多的報文，是一個很正常的行為。佇列，歸根結底是一塊塊記憶體，總是有一定的大小範圍，不可能無限大。當報文流入的速度大於流出的速度時，路由器的記憶體充滿時，要麼丟棄，要麼記憶體溢位——造成當機。我想路由器只能選擇丟棄。

唉，這麼說，一下子把報文丟棄的逼格降低到地板以下了。高逼格的說法是：網路防擁塞機制。

不過，無論是低逼格說法還是高逼格說法，網路防擁塞的本質是丟棄報文。丟棄報文主要有幾種策略：尾丟棄(Tail Drop)、WFQ 改進、RED(Random Early Detection)、WRED(Weighted Random Early Detection)。

尾丟棄策略比較簡單和直觀，就是佇列滿了以後，期望再進入佇列的報文將被丟棄。WFQ 改進的丟包策略，前文說過，與 IP 優先順序的加權有關，不過涉及到一點數學公式，本文不打算涉及到這些細節，只須簡單理解為它是尾丟棄策略的一種改進，如果一個佇列滿了，它有可能丟棄其他佇列的報文。WFQ改進的丟包策略，不是重點，我們點到為止。

本節重點介紹 RED 和 WRED。WRED 是對 RED 的一種改進，也是引入了IP 優先順序作為一種加權。所以我們需要首先介紹 RED。

RED，Random Early Detection，直譯為隨機早檢測。要想理解 RED，就得首先理解尾丟棄策略的問題。

網路中存在很多的TCP連線，這些連線中的報文段通常是複用路由路徑。若發生路由器的尾部丟棄，可能影響到很多條TCP連線，如圖11所示：

　　圖11：多條 TCP 經過同一個路由器的示意圖

尾丟棄策略所造成的結果就是這許多的TCP連線在同一時間進入慢開始狀態。這在術語中稱為全域性同步。全域性同步會使得網路的通訊量突然下降很多，而在網路恢復正常之後，其通訊量又突然增大很多。突然增大很多後，很有可能再次造成網路擁塞，然後再引發全域性同步......週而復始，惡性迴圈。

RED 丟棄策略，就是為了解決尾丟棄策略所產生的“全域性同步”問題而做的一種改進。簡單地說，它不是等到佇列滿以後才開始丟棄，而是佇列差不多的時候，就開始隨機丟棄，這也是 RED -- Random Early Detection 這個名字的由來：提早檢測、隨機丟棄。

什麼叫佇列差不多呢?就是將佇列設定兩個門限(threshold)：THmin、THmax。當佇列的平均長度低於 THmin 時，所有報文都不丟球;當報文平均長度大於 THmax 時，所有新來的報文都丟棄;當報文平均長度介於 THmin 和 THmax 之間時，則機率性地隨機丟棄一些報文，如圖12所示：

　　圖12：RED 丟包策略示意圖

前文提到了平均佇列長度，這裡我們只給出一個公式，而不再深究：

平均佇列長度 =(以前的平均佇列長度×(1-1/(2的n次方)))+(當前佇列長度×(1/(2的n次方)))

其中n可以透過命令配置。佇列平均長度既反映了佇列的變化趨勢，又對佇列長度的突發變化不敏感，避免了對突發性資料流的不公正待遇。

RED 的精髓是“隨機”，因為這個隨機丟包，從而避免網路的全域性同步。為了做到“隨機”，則必須要提前。如果是等到佇列滿，那就不是隨機了，而是全體相關的 TCP 連線同時被丟包了。

RED 比較有效地解決了網路全域性同步的問題，但是它的隨機丟包仍然是丟包，這對於語音、影片等業務流，仍然是會產生不好的影響。為了解決這個問題，一個是要慎重考慮是否要引入 RED 機制，另一個是對 RED 做改進(當然改進以後，仍然要慎重考慮，畢竟有些東西失去了，就再也回不來了)。

對 RED 的改進方法，就是引入權重，這也是 WRED 名稱的由來。引入什麼權重呢?IP 優先順序(或者 DSCP)!

RED 為了避免網路的全域性同步而引入了隨機丟包，隨機不是目的，目的是使多個 TCP 連線錯開時段丟包，而不是同時丟包。如果能先丟低優先順序報文的包，後丟高優先順序的包，一個是能緩解高優先順序丟包的機率，還有一個很可能由於低優先順序的包丟過以後，網路擁塞程度緩解了，高優先順序的報文就不需要丟棄了。

所謂 WRED，其實也很簡單直接，那就是將高優先順序報文的 THmin 設定的比低優先順序報文的 THmin 要大，讓低優先順序的報文先被丟棄，如果13所示：

　　圖13：WRED 原理示意圖

WRED，總結為一句話就是：你醜你先睡，我美無所謂!

3、流量監管和流量整形

報文的丟棄機制，無論是為丟棄，還是 RED，或者是 WRED，都是在網路擁塞時，一種佇列丟棄機制，但是這種丟棄是不是有點憋屈?為什麼這麼講?因為為了丟棄一個報文，做了太多的工作，最後不過是丟棄報文而已。有沒有一些場景可以簡單粗暴地直接將報文丟棄呢?

一種場景是：明知不可為，那就不為!如果一個路由器的處理能力是 2M/秒(只是打個比方，不必糾結這個數字)，而入口頻寬是 3M，那還糾結個啥，直接先丟掉 1M 再說。

當然，還有一種情況更加直接。你花了100元錢購買了 100M的頻寬，結果傳送速率是 200M/秒，那不丟你丟誰?你真是想得美，你當運營商是傻子啊?

當然網路中報文的傳送並不能保證是勻速的，有時候也會突發。如果偶爾的突發，都會被丟棄，那麼這個網路顯得有點不太友好。所以網路也需要具有容忍短時突發報文的能力。

在報文進入流分類器之前，對頻寬過大的報文進行丟棄(或者打標記)的行為成為流量監管，對報文進行一定的緩衝和平滑處理，叫作流量整形。當然，在報文流出路由器時，也可以做流量監管和流量整形，這沒有絕對應該在哪裡做，不應該在哪裡做。

從命運把握在自己手裡的角度來講，不管別的路由器有沒有做，只要是進入自己的流量都做一下流量監管或者整形，乃是一個完全之策。

不過需要澄清的是，並不是每一個路由器都需要這麼做，一般在網路的邊界路由器上做如此動作即可。網路邊界上的路由器，像一個個門神，把好網路的大門，限制好進入網路的流量，網路內的路由器就可以安心地做個美男子了。當然，這也不絕對。具體如何配置，還需要看實際網路的情況。

無論是流量監管還是流量整形，都用到了令牌桶演算法，本文一如既往，不深究演算法本身，點到為止，只要能把監管和整形基本講明白即可。

3.1 流量監管

流量監管(traffic policing)的典型作用是限制進入或流出某一網路的某一連線的流量與突發。在報文滿足一定的條件時，如果某個連線的報文流量過大，流量監管就可以對報文采取不同的處理動作，如丟棄報文或者重新設定報文的優先順序等。通常的用法是使用 CAR 來限制某類報文的流量。

CAR(Committed Access Rate，承諾訪問速率)，首先對報文進行分類，然後：

(1)有的報文不需要監管(哪種報文需要監管，是由使用者配置)，那就直接轉發(中間還會經過入佇列、排程，然後才是轉發);

(2)有的報文需要監管，則會分為3種情形：

(A)直接轉發——對評估為“符合”流量規定的報文繼續正常轉發。

(B)直接丟棄——丟棄“不符合”流量規定的報文。

(C)修改報文優先順序後再轉發——對評估結果為“部分符合”的報文，將之標記為更低優先順序別的流後再進行轉發。

CAR 的基本原理圖，如圖14所示：

　　圖14：CAR 基本原理示意圖

報文做了 CAR 以後，其流量效果，如圖15所示：

　　圖15：CAR 的效果示意圖

3.2 流量整形

流量整形(traffic shaping)的典型作用是限制流出某一網路的某一連線的流量與突發，使這類報文以比較均勻的速度向外傳送。流量整形通常使用緩衝區和令牌桶來完成，當報文的傳送速度過快時，首先在緩衝區進行快取，在令牌桶的控制下，再均勻地傳送這些被緩衝的報文。

流量整形的效果，如圖16所示：

　　圖16：流量整形效果示意圖

流量整形通常採用的技術是 GTS(Generic Traffic Shaping，通用流量整形)，GTS 的基本原理示意圖，如圖17所示：

　　圖17：GTS 的基本原理示意圖

4、物理介面總速率限制

物理介面總速率限制，英語是 Line Rate，簡稱 LR。嚴格來說，LR 也是流量整形的一種技術。不過，無論是 CAR 還是 GTS，都是在 IP 層實現(也說明了，不是 IP 的報文，這兩者也不起作用)，而 LR 則是在物理介面層面進行限制。

LR 可以在一個路由器的物理介面層面限制介面傳送報文的總速率(包括緊急報文)。LR 的處理過程仍然採用令牌桶進行流量控制。如果使用者在路由器的某個介面上配置了 LR，規定了流量特性，則所有經由該介面傳送的報文首先要經過 LR 的令牌桶處理。如果令牌桶中有足夠的令牌可以用來傳送報文，則報文可以傳送。如果令牌桶中的令牌不足，則報文進入 QoS 佇列等待下一次傳送機會。

LR 相較於 GTS 的區別是，LR 進入的等待佇列是 QoS 佇列，所以佇列排程機制更加靈活。LR 的基本原理，如圖18所示：

　　圖18：LR 基本原理示意圖

5、路由器 QoS 模型的小結

哎呀，終於寫到小結了，可把我累壞了，有點瞌睡了，趕緊照照鏡子。

對於單個路由器來說，實施 QoS 的方法，有如下幾點：

(1)基於業務的分析與報文標記：QoS中的幾乎所有控制手段都是基於對業務的分類，及不同業務流的標記。

(2)多種方法結合使用：預防策略——LR、CAR、GTS、RED、WRED;排程策略：各種佇列排程方案。

路由器的 QoS 模型，如圖19所示：

　　圖19：路由器的 QoS 模型

路由器的 QoS 模型比較複雜而且全面，但是同時我們也必須要認識到QoS 策略的侷限性和副作用：每一種策略都會消耗裝置的系統資源，導致裝置的總體效能下降;並非使用了QoS就可以高枕無憂，可能裝置異常繁忙導致無法處理配置的各種策略。

天下武功，唯富不破。最有效的QoS手段是增加頻寬和提高裝置的處理能力。

四、IP 網路 QoS 解決方案

上一節介紹了單個路由器的 QoS 模型，那麼網路作為一個由多個路由器(也包括交換機等其他裝置)，它是如何構建一個端到端的解決方案呢?

提到端到端，忽然間開始想念一位印度朋友。在過去的一年，我們一起做開源工作，我用蹩腳的英語教會了他流利地說出中文“端到端”。當然，不是我教的好，而是他的語言天賦比較高。

好吧，不感慨了，回到本文主題。網路的 QoS 解決方案，有三種模型：

(1)Best-Effort service，盡力而為服務模型。

(2)Integrated service，綜合服務模型，簡稱Intserv。

(3)Differentiated service ，區分服務模型(有時候也翻譯為差分服務模型，這個翻譯顯得逼格高一點，^_^)，簡稱Diffserv。

下面我們分別介紹這三種模型。

1、Best-Effort service

Best-Effort service 是一個單一的服務模型，也是最簡單的服務模型，應用程式可以在任何時候發出任意數量的報文，而且不需要事先獲得批准，也不需要通知網路。對 Best-Effort 服務，網路盡最大的可能性來傳送報文，但對時延、可靠性等效能不提供任何保證。 Best-Effort 服務是現在Internet的預設服務模型，它適用於絕大多數網路應用，如 FTP、 E-Mail 等。其實Best-Effort 並非是什麼 QOS，就是網際網路的簡單資料傳輸方式而已，有什麼傳什麼，阻塞也就阻塞了，丟且也就丟棄了。

寫到這裡，免不了有感慨一下。一個人會不會說話，真的很重要。Best-Effort，明明是啥也沒幹，卻說自己是盡力而為!唉，這逼裝得也是沒誰了!

2、Integrated service

Intserv，整合服務模型，可以滿足多種 QoS 需求。這種服務模型在傳送報文前，需要向網路申請特定的服務。應用程式首先通知網路它自己的流量引數和需要的特定服務質量請求：包括頻寬、時延等。應用程式一般在收到網路的確認資訊，即確認網路已經為這個應用程式的報文預留了資源後，才開始傳送報文，同時應用程式發出的報文應該控制在流量引數描述的範圍以內。

網路在收到應用程式的資源請求後,執行資源分配檢查，即基於應用程式的資源申請和網路現有的資源情況，判斷是否為應用程式分配資源，一旦網路確認為應用程式的報文分配了資源，則只要應用程式的報文控制在流量引數描述的範圍內，網路將承諾滿足應用程式的 QoS 需求。

在IntServ服務模型中，負責傳送 QoS 請求的信令是RSVP(Resource Reservation Protocol，資源預留協議)，它通知路由器應用程式的 QoS 需求。RSVP 是在應用程式開始傳送報文之前來為該應用申請網路資源的。

Intserv 實際上是一種對服務的預定機制，透過申請來獲取相應得服務，這裡面主要依靠的就是RSVP。

RSVP，我們不深入介紹它的協議細節(那又是洋洋灑灑一大篇文章，以後有時間再寫吧)，只是簡單畫個示意圖吧，如圖20所示：

　　圖20：RSVP 示意圖

圖20中，傳送方沿著傳送路徑請求網路資源(頻寬2M)，從接收方開始，沿著路徑回去，沿途各個路由器表示同意(它們透過計算，發現自己可以滿足這個頻寬需求)，一直傳遞到傳送方。這樣傳送方就可以愉快地玩耍了：按照2M的頻寬約定，進行報文傳送。

Intserv/RSVP 看起來很美好，然並沒有什麼卵用。因為 Intserv 是基於每條流的。想一想 WAN 網路上有多少條流，再想一想 WAN 網路上這些流是動態變化的......Intserv 所面臨的是一個不可能的任務。

所以雖然 Intserv/RSVP 發展迅速，但是到目前為止，並沒有在任何一種網路上得到證實，它的應用只侷限在小的測試的 Intranet 上。

3、Differentiated service

看到 Differentiated service，很自然地就會想到DSCP(Differentiated Services Code Point)。沒錯，DSCP 就是為Diffserv(Differentiated service)服務的。不過我們暫時先忘記 DSCP，先看看Diffserv 的架構，如圖21所示：

　　圖21：Diffserv 架構示意圖

圖21中，由於執行策略的不同，整個網路被劃分為不同多個 Diffserv 域(DS 域，圖中畫出了2個)。為了簡化模型和易於理解，關於 DS 域我們點到為止，不再描述也不再糾結這個概念，就當作只有一個 DS 域。

在 DS 域中，路由器分為兩種角色，一種是邊緣節點(圖中的A、B、C、D)，另一種是內部節點(圖中的 X、Y、Z)，也叫核心節點。兩種角色的行為是不一樣的，這個下文會描述。

要想實施 Diffserv，首先需要運營商和使用者之前簽訂一定 SLA 合同，這既是商業的基礎，也是 Diffserv 的技術基礎。這裡我們不談商業，只談技術。從技術角度來說，意味著不同的型別的業務，其所對應的 IP 報文的 DSCP 就可以定義下來。

這個非常關鍵。當使用者的業務流傳送到 DS 的邊緣路由器時，邊界路由器的行為有：流量監管、整形、分類標記、佇列排程(含丟棄)。其中流量的監管和整形，就是我們前文介紹的內容，可以採取 CAR、GTS 等技術完成。流量的分類標記，就是根據 SLA 協議，給 IP 報文的 DSCP 賦值!給 IP 報文的DSCP 賦值!給 IP 報文的 DSCP 賦值!重要的事情講三遍。分類標記以後，就是前文講述過的佇列排程(含丟棄)和轉發，因為它總得轉發出去。

當報文轉發到 DS 的核心路由器時，它就不需要那麼複雜，只需要按照報文的 DSCP 值做相應的動作即可。Diffserv 把這個相應的動作稱為 PHB(Per Hop Behavior，每一跳行為)。PHB 並不神秘，它其實是與 DSCP 是一一對應的。重點不是 PHB 與 DSCP 的一一對應，而是每一個 PHB，需要有合適的佇列排程機制(含丟棄)能夠承載。佇列排程機制就是我們前文介紹的 PQ、CQ等7種，具體選擇哪一種，是一種綜合考慮的結果。

可以看到，Diffserv 不存在 Intserv 的那些問題，在工程上，在 Internet的範疇內，還是可以實施的。當然，它也必須能夠實施，因為網路一共就三種模型，第一種說的好聽是盡力而為，其實是無所作為，第二種理想很豐滿，現實很骨感，根本沒法實施。這第三種如果再不能實施，那......

五、MPLS 網路 QoS 解決方案

在談 MPLS 網路 QoS 解決方案之前，我們首先要思考一個問題，MPLS 專線為什麼比 Internet 專線貴?是因為轉發技術的不同，應該不是，使用者管你是用什麼技術轉發呢，你如果牛逼，你用順豐都行。是因為專線技術的不同，應該也不是。MPLS 技術雖然天生適合做專線(VPN)，但是 Internet 在 IP 技術上疊加 IPSec，也差不到哪去。

思來想去，應該還是因為 QoS!MPLS 的 QoS 解決方案，有兩種模型：Diffserv 和 MPLS-TE。

1、MPLS 的 Diffserv

MPLS 的轉發模型與 IP 網路的 Diffserv 模型非常的想象。MPLS 的轉發角色分為邊緣路由器與核心路由器，IP 網路的 Diffserv 模型分為邊緣路由器與核心路由器。所以，MPLS 如果要提供 QoS 的 Diffserv，那是有天然優勢的。

所要解決的問題是，IP 報文的 DSCP，到了 MPLS 網路的核心路由器就不可見了。前文說過，MPLS 報文中能夠表達 QoS 等級的只有 EXP 欄位。不幸的是，EXP 欄位只有3個bit，只能表達8個優先順序，而 DSCP 有6個bit，可以表達64個優先順序(當前只使用了24個)，這裡面存在一個對映的問題。

如果運營商與使用者簽訂的 SLA 中，只有8個(甚至少於8個)業務等級，那麼很簡單，只需要將這些業務等級(也即 DSCP/PHB 實際只取8個值)一一對映到 EXP 欄位即可。

如果運營商與使用者簽訂的 SLA 中，多於8個和業務等級，那麼沒有辦法，MPLS 只能用不同的路徑(LSP，Label Switch Path，標籤交換路徑)來表示不同的 DSCP/PHB。

這也沒什麼，反正能表達 SLA 就行。解決了 SLA 的標識方法以後，再看MPLS 的 Diffserv 就非常簡單了。與 IP Diffserv 的邊緣路由器一樣，MPLS 的邊緣路由器的 QoS 行為也是包括：流量監管、整形、分類標記、佇列排程(含丟棄)。只不過分類標記是標記 MPLS 報文頭的 EXP 欄位或者選擇不同的 LSP而已。同理，MPLS 的核心路由器，也僅僅是負責 PHB。

應該說，MPLS 的 Diffserv 與 IP 的 Diffserv，沒有本質的不同，兩者達到的 QoS 效果也是一樣的。

2、MPLS 的 TE

MPLS 的 TE(Traffic Engineering，流量工程)的概念超出了本文的範圍，我們不談它。這裡只須知道，MPLS TE 透過流量工程擴充套件的資源預留協議(RSVP-TE)、基於約束的標籤分配協議(CR-LDP)、基於約束的路由協議(QoS路由技術)等技術，為流量提供頻寬保證，透過MPLS TE技術傳輸的流量不會由於鏈路頻寬不夠而被丟棄。

從效果上來講，這其實就是 IP 的 Intserv。現在有一個小問題，為什麼IP 網路的 Intserv 無法實施，而 MPLS 網路就可以實施了呢。這裡面要看到本質的不同：IP 的 Intserv，是為每一條流預留資源，保證頻寬及其他 QoS 屬性，而 MPLS 是為路徑(LSP)預留資源，這兩者的差距不可同日而語!

MPLS TE 同時還帶來了另外一種好處，那就是利用 MPLS TE，可以實現FRR(Fast Reroute，快速重路由)。在發現鏈路或者路由器故障以後，MPLS TE透過硬體直接切換鏈路，可以做到從鏈路故障到快速重路由切換成功的延時小於50ms。

3、MPLS 與 IP 的 QoS 解決方案比較

在進行兩者比較之前，讓我們再回憶一下本文開頭所說的 QoS 所包含的屬性：頻寬、可用性、時延、抖動、丟包。

基於這些屬性，以及網路的 QoS 模型，兩者的比較，如表9所示：

表9：MPLS 與 IP 的 QoS 解決方案比較

透過表9，我們可以看到，MPLS 的 QoS 與 IP 相比，有著非常大的優勢，MPLS 線路比 IP 線路(Internet)價格貴，那是有道理的!