WFQ加權公平隊列(每個隊列的計算原則與權重比關係）
及加權效果取證
加權公平隊列（Weighted FairQueuing），它不允許用戶使用MQC語句來手工完成對流量的分類，因爲WFQ的分類是自動完成的，它基於每一種不同的流（flow）來分類，然後將不同的flow送入不同的隊列。在實施WFQ的隊列調度時主要是爲了兩個目標：一、爲不同的數據流提供公平的服務；二、它可以爲具備高優先級（較高IP優先級或者DSCP值）的數據提供更多的帶寬，使其得到更好的服務。現在首先來理解如下五個重要的知識點：
1、WFQ如何自動去完成對不同流（flow）的分類，這依賴於數據中的那些關鍵因素？
2、WFQ如何爲不同的流提供公平的服務？
3、WFQ如何爲高優先級的流提供更多的帶寬？
4、WFQ的計度計劃與SN的計算公式，先轉發誰？再轉發誰？
5、WFQ的丟棄策略、隊列數量和隊列長度
6、WFQ調度器的總體執行流程
1 WFQ如何自動去完成對不同流（flow）的分類，這依賴於數據中的那些關鍵因素？
WFQ是不能通過用戶配置策略ACL或者數據的TOS字段去匹配數據來完成分類的，它將自動將相同的流分配到同一個類別中，那麼什麼是相同的流？很簡單，一般而言，只要具備相同的源IP地址、目標IP地址、相同的傳輸層協議（TCP或者UDP）、源端口、目標端口這五個關鍵的因素，那麼WFQ會認爲這是同一個流，會將其規劃到同一個類別中。WFQ這種分類的方式是不能被人工干預的，而且這種分類隨時都可能變，因爲流活躍和變化都非常的迅速，也就是說可能用戶通過show queue查看當前WFQ分類的排隊信息的時候，活躍的流已經發生變化了。
因爲WFQ是基於不同的流來完成自動分類，然後將針對不同的類產生隊列，事實上也就是每一個流一個隊列，那麼WFQ最多可以支持4096個隊列，可看出WFQ所支持的隊列數非常龐大。另外一個問題就是很多時候，用戶會提出疑問：WFQ分類時爲什麼不去關注TOS字段，因爲該字段中包含着IP優先級和DSCP值？事實這個問題並不重要，因爲在一個良好的網絡設計中屬於同一個流的TOS字段中的IP優先級或者DSCP值是相同的。
2 WFQ如何爲不同的流提供公平的服務？
這種情況是一種很理想的情況，WFQ將爲網絡中不同的流分配相同的帶寬，打個比喻：假設整個鏈路具備256K的帶寬，如果網絡中存在10個不同的流（事實上也就是10個分類）那麼，在理想狀態下，這10個流將每個分別獲得25.6K的帶寬。爲什麼說它是理想的狀態?依照上述的分配原則，那麼這10個流的必須是具備相同的優先級、相同的數據包長度、相同的權重等因素，才能保證它們每個能公平的分得25.6K的帶寬，因爲WFQ爲不同的流分配帶寬時，會考慮權重（Weighted），實其從WFQ的名稱就不難看出，它叫加權公平隊列，而權重又直接和IP優先級和DSCP值有關，關於這一點在後面部分會詳細描述。
在目前所描述的WFQ爲不同流提供公平服務的環境中，可以得出這樣一個結論：如果流量體積越小，那麼它所獲得的服務質量就越高，反之，流的體積越大它所能獲得的服務質量就越低。爲什麼呢？仍然遵守上面的描述，假設現在每個流可以分得25.6K的帶寬，如果此時流1需要10K的帶寬來轉發數據，那麼流量1的數據將能得到迅速轉發，因爲WFQ可以爲流1提供25.6K的帶寬，而它的轉發只需要10K，相反如果流2需要40K的帶寬來轉發數據，那麼相對於流1而言流2就不能得到更好的服務質量保證，因爲WFQ爲每個流公平的分配了25.6K的帶寬，而流2需要的帶寬超過了其本身隊列分配的25.6K，所以流2會被延遲。當然WFQ調度程序可以將流量1沒有使用的多餘帶寬分配給其它的流。根據上面的描述，不難看出WFQ很像時分複用系統（TDM）。
3、WFQ如何爲高優先級的流提供更多的帶寬？
WFQ可以高優先級的流量提供更多的帶寬，它根據優先級+1來計算帶寬分配的比率，打個比方說：現在網絡中一共有10個流，其中5個使用默認的優先級盡力而爲（也就是0），另外5個使用IP優先級1，那麼根據IP優先級加1的計算原則是(1+1):(0+1)=2:1,也就是說此時5個使用IP優先級1的流量將獲得比5個使用IP優先級0的流要多一倍的帶寬。關於這一點在計算機SN號的時候可以被體顯出來，後面會有實例作詳細分析。如果網絡現在的總體帶寬爲256K，那麼使用IP優先1的流將使用大約170K左右的帶寬，而IP優先級爲0的將使用大約85K左右的帶寬。
根據上面的描述，不難得到一個關於WFQ的結論：如果不考慮IP優先級，那麼體積較小的流將得到比體積效大的流更好的服務，如果考慮IP優先級，那麼高IP優先級的流將比低IP優先級的流得到更好的服務，如果體積很小，同時IP優先級也很高的流，那麼它將得到最好的服務，通常是指這類流的帶寬／延遲／抖動／丟棄都會得到最大化的改善。
注意：關於WFQ能爲高優先級的流量提供更多的帶寬將在“取證演示:配置WFQ隊列及影響數據傳輸的效果”部分作描述。
4、WFQ的調度計劃與SN的計算公式，先轉發誰？再轉發誰？
WFQ會給自動劃分的每個流一定帶寬的帶寬比例，但是這個比例隨時都可能發生變化，而且變化得很快，所以不是很好統計和分析，爲什麼呢？因爲一個流是即時的，發送完成就不存在了，而且這個時間相對於人類的感觀而言，非常的短暫。說明這個觀點的目的是爲了指引出一個原則：不能簡單的將WFQ理解爲：假設鏈路256K的帶寬，被分給10個流，每個流就是25.6K的帶寬，這個描述僅於初次理解WFQ時對它的“公平性”進行一個形象的比喻，因爲的確最佳的比喻方式就是實例化和數字化。但這並不是WFQ最真實的工作機制。或者讀者現在可以進一步的理解WFQ是在網絡發生擁塞時，它能讓每個隊列的數據都得到儘量可能公平的服務，也就是說WFQ的調度器能讓每個隊列的數據都得到調度，而不像PQ那樣工作。至於這個調度機制是否滿足用戶網絡的服務特點，那就必須針對特定的情況了，但是現在應該來理解WFQ如何去調度不同隊列的數據。
WFQ調度原則：
當路由器硬件隊列空閒或者還有空間時，WFQ將具備最小SN（sequence Number序例號）的數據包調度進入硬件隊列發送，那麼什麼是SN，如何計算SN就是關鍵？
SN的計算公式與演示實例
當前數據包的SN=前一個數據包SN+(權重*當前數據包的長度)
權重=32384/(IP優先級+1)
假設被送入TX硬件隊列的前一個數據包的SN爲200，而當前數據的長度爲1500，優先級爲1，那麼首先應該計算當前數據包的權重，即32384除以（1+1）等於16192，然後用當前數據包的權重16192乘以當前包的長度1500等於24288000，最後再加上前一個包的SN200就等於24288200。所以當前數據包的SN=24288200.
爲了體現WFQ關於SN的計算及權重所引發的公平性問題，及參入優先級後WFQ會提供更多轉發機率的問題，現在舉一些更復雜些的實例。
實例1：優先級相等，較小的數據包能得到更好的服務質量保證
假設有如圖所示的4個流，第個流中有4個數據包，第個流的數據包都有不同的數據長度，而且所有數據包的IP優先級都是0，因爲在這裏筆者將首先討論全部數據包優先級都是0的情況下，WFQ的調度過程。爲了在理論下分析方便，目前假設每一個流的第一數據包前面的SN號都是0。
那麼使用上面所描述的關於SN的計算機公式，可以得到圖中關於從D1…….A4，總共16個數據包的SN，然後再根據WFQ首先調度低SN號的原則，那麼在圖所示的環境中，WFQ執行這樣這個調度順序：D1、D2、D3、D4、C1、B1、C2、A1、C3、B2、C4、A2、B3、B4、A3、A4。根據這樣的調度順序，不難看出WFQ在數據的優先級都相等的情況下，體積越小的數據包越容易得到更好的服務，比如圖中的流D中的數據包得到最先的轉發，流C次之，流B和流A更次之。但是也可以看出至少不同4個流中的數據在不同程度都能得到服務，不至於“餓死”隊列中的數據，這是WFQ所謂“公平”之處。記住優先級相同，那麼數據包的尺寸最大，所產生的SN就越大，被立即調度的可能性就會靠後。
實例2：優先級較高的數據包能得到更好的服務質量保證
如果此時將流C數據的IP優先級設爲3，而其它條件都不變的情況下，如圖所示，明顯可看出流C的每個數據的SN號被降低，也就是說流C被優先調度的可能性增大，然後按照WFQ優先調度低SN的原則，目前的調度順序是：D1、C1、D2、C2、D3、C3、D4、C4、B1、A1、B2、A2、B3、A3、B4、A4。通過這個優先調度低SN的原則，可以對比先前沒有更改優先級時的調度順序，不難發現：流C的IP優先級被設置爲3後，它獲得了更多的調度，也就是它可以使用更多的帶寬，因爲優先級變高，權重就會變小，那麼通過SN計算公式得出的SN號就會更小，所以它更容易被調度。
此時流C的IP優先級爲3時比它的IP優先級爲0時獲得了多4倍的帶寬，爲什麼這樣講？大家是否還記得在筆者在描述“3、WFQ如何爲高優先級的流提供更多的帶寬”提到過一個公式：(X+1):(0+1)，X表示當前的IP優先級，使用這個公式可以計算機出流C的IP優先級爲３時和它爲０時對帶寬使用比例的公式：（３＋１）：（０＋１）＝４：１，也就是說當流C的IP優先級變爲3時是IP優先級爲0時使用帶寬的4倍，而且數學就是一個很有趣的工具，爲什麼呢？ 如圖所示：你會發現流C的IP優先級爲3時計算出來的SN正好比IP優先0時計算出的SN小４倍，請記住喲：WFQ是先調度較小SN的原則，這意味着什麼不言而喻！
通過上面的各種演算實例可以看出WFQ的幾個特性：
1權重與優先級是成反比的，優先級越高，權重最小，那麼生產的SN就越小，就越容易被WFQ優先調度，這個特性源於，WFQ總是爲高優先級的數據分配更多的帶寬。
2如果優先級相同，那麼大體積的數據相較於小體積的數據不能得到更好的服務質量。
3如果數據包體積較小，並且IP優先級較高，那麼這種數據將得到最佳的服務質量。
4 WFQ可以爲每一個流都提供服務，不管服務的質量是好或者差，至少不至於“餓死”不同隊列中的數據，這是它和PQ最大的不同。
5、WFQ的隊列數量、隊列長度、丟棄策略
WFQ支持4096個隊列數量，關於WFQ隊列的長度，它有兩種可能，因爲WFQ爲每個流可以規劃一個隊列，所以WFQ爲每個流，實際上就是針對不同流的每個隊列規劃了一個CDT（CongestiveDiscard Threshold擁塞丟棄門限值），用戶可以把該值理解爲針對每個流隊列的長度，默認情況下每個隊列的CDT值最大爲4096；另一種是將全部隊列設置了一個絕對長度，通常也稱呼該長度爲排隊限制（Hold-QueueLimit）；這個排隊限制的最大長度值也是4096。關於配置整體隊列長度、最大的針對每個流隊列的數量、CDT如下所示：
配置整體隊列長度和CDT：
R1(config)#intes1/0
R1(config-if)#hold-queue1500 out * 設置所有隊列的整體長度爲1500
R1(config-if)#fair-queue120 64
*每個針對流的具體隊列的CDT爲120，也就是當達到該值時，具體針對不同流的隊列爲了避免擁塞開始丟棄該隊列中的數據包；可以最多有64個針對不同流所創建的動態隊列，注意其實在64後面還有一個參數叫“Reservable Conversation Queues（可預留的會話隊列）”這是一個讓RSVP讓WFQ爲每個RSVP預留流，創建隊列的選項，由於該配置關聯到RSVP的知識點，它不在路由交換類CCNP的範圍，所以這裏不作更多描述。
可以通過show inte s1/0接口，如圖所示，可以看到整體輸出隊列的大小爲1500，每個隊列的CDT丟棄門限爲120，允許一個接口最多能創建64個動態隊列。當然用戶也可以通過執行Show queueing fair指令來查看加權公平隊列，具體顯示如圖所示，也可以看到允許的最大隊列數及隊列的CDT丟棄門限值，但是這裏需要注意的是在顯示中出現了8個Link queues（鏈路隊列），這8個隊列是爲路由器產生的開銷流量提供服務的，也就是在許多文檔中所描述的WFQ維護的8個隱式隊列。
注意：在配置WFQ的隊列時，用戶只能在16-4096這個範圍進行配置，而且必須是16的倍數，比如：16、32、64、128……等這些值將是有效的，爲什麼會有這樣的一個限制呢？主要的原因是WFQ要使用hash算法來分類，由於某些數學原因，只有將隊列的數量配置爲16的倍數時，纔可能運行hash算法。
在理解WFQ的隊列長度及丟棄門限後，不得不討論的一個問題就是WFQ的丟棄策略，WFQ它仍然是使用“尾棄”策略，但是這個“尾棄”策略是經過調整後的“尾棄”，爲什麼這樣講？如圖所示，首先WFQ對全部隊列作了一個排隊限制（Hold-Queue Limit），當某一個數據包的到來，並且排隊限制（即整體全部的隊列）已經滿載，那麼這個數據包將被丟棄，但是這個丟棄決定並不是針對某一個單一的隊列（因爲不同流會有不同的隊列）作出的。那麼就還有一種情況，就是到來新的數據包時，排隊限制（即整體全部的隊列）還未滿載，那麼IOS系統將計算新數據包的SN，然後決定某個針對具體流的單獨隊列是否滿載，實際上也就是看某個具體的隊列是否達到了CDT門限，如果沒有達到具體隊列的CDT門限，就將該數據包送入具體的某個隊列排隊，如果此時該具體隊列已經滿載，注意此時WFQ將不僅是執行簡單的“尾棄”，而是去查看其它的針對不同流的隊列中是否排入了一個比當前數據包具備更大SN編號的數據，如果有WFQ則轉而去丟棄那個比當前數據包更大SN的數據，這樣做的一個目的是WFQ在已經達到CDT值時爲較低SN數據包服務，避免較低SN的數據包不能得到排隊處理而被“餓死”。
6、WFQ調度器的總體執行流程
現在對WFQ的零散知識點分別做了相關的描述，剩下來的事情就是將上面描述的各個零散知識點組織成一個完整的關於WFQ的整體調度流程。如圖所示：可以看出在這個過程中，數據包在接入路由器後，被WFQ根據流（flow）的五個關鍵因素所分類，注意這個分類是WFQ自動完成分類，管員不能手工配置，然後判斷是否達到整體隊列長度（絕對長度）然後計算SN值，再交給丟棄策略做決定，這裏的丟棄策略是指隊列滿載時（當然這裏針對的是具體的流隊列），值得一提的是計算SN是在丟棄策略判斷之前進行計算的，因爲丟棄策略會考慮SN的大小。如果隊列沒有滿載，那麼WFQ優先調度具備較小SN的數據包，然後將其輸送到硬件隊列。
取證演示：配置WFQ隊列及影響數據傳輸的效果
演示目標：
1 仍然是首先模擬低速鏈路，該環境爲56K。
2 將隊列配置爲FIFO，觀察環境中的大體積流量“壟斷”帶寬現象，小體積流量延遲很大
3配置隊列爲WFQ，在持續大體積流量傳輸時，再次觀察小體積流量的延遲變化
4完成採樣在未使用優先級加權時，WFQ隊列下小體積流量的平均延遲。
5配置小體積流量具備更高的優先級來加權WFQ隊列，再次採樣加權優先級後的平均延遲
6 觀察WFQ隊列的關鍵顯示，自動分類情況、隊列長度、CDT值、丟棄情況等。
演示環境：如圖所示。
演示步驟：
第一步：
R1(config)#intes1/0
R1(config-if)#nofair-queue
R1(config-if)#exit
R1(config)#intes1/0
R1(config-if)#fair-queue
R1(config-if)#exit
通過把192.168.2.101和客戶機之間的ICMP流量的IP優先級調高，此時主機到192.168.2.101的流量被WFQ最優先調度的可能性就越大，未加權時如下圖所示。
R1(config)#access-list 101 permit icmp host192.168.2.101 host 192.168.4.2
R1(config)#class-map icmp
R1(config-cmap)#match access-group 101
R1(config-cmap)#exit
R1(config)#policy-mapqos
R1(config-pmap)#classicmp
R1(config-pmap-c)#set ip precedence 7
R1(config-pmap-c)#exit
R1(config)#intee2/0
R1(config-if)#service-policy input qos
R1(config-if)#exit
加權後的延遲：
完成實驗取證後總結WFQ隊列的優勢與不足：
WFQ具備最少的配置，能爲不同的流量自動分類，並最大公平的分配帶寬，這樣所有進入網絡設備的流量都能得到服務，不至於“餓死”某個隊列中的數據，所以它符合在低速鏈路上作爲一種默認隊列方式被啓動，因爲默認所有的流量被平等對待，這恰好引出了WFQ的不足，至少WFQ具有如下幾個天生的缺點：
１、它不能被用戶以“應需而動”的原則執行基於用戶期望的流量分類
２、它不能爲不同類別的流量去申明使用用戶所期望的鏈路資源（帶寬）
３、它過於公平，無法滿足一些特定環境的流量訂製計劃。
由於上述的三個重要原因：所以必須要產生一種能突破上述三個原因的隊列工具，而後
繼緊接着將要描述的隊列工具CBWFQ能破突這些限制。