PQ（Priority queuing優先級隊列）

PQ是一種具備嚴格的，分等級執行排程的隊列，它可以最多建立4個不同等級的隊列，分别是高、中、普通、低；然後根據對不同的資料流量分類，将不同的分類資料送入到4個不同等級的隊列。如圖X所示，然後以100%的使用帶寬的方式，首先服務于處于“高”隊列中的資料，直到“高”隊列中的資料全部發送完成，再服務于“中”隊列中的資料，以此類推，再服務于“普通”隊列，最後才是“低”隊列。按照這樣的邏輯，PQ隊列的最大特點是高優先級的隊列總是被服務，那麼這可能會導緻低優先級隊列中的資料被“餓死”，為什麼呢？如果高優先級隊列一直持續發送資料，那麼PQ的排程器，将保證高優先級的隊列資料發送完成後，才能輪到較低優先級的隊列發送，換而言之，處于“低”等級隊列中的資料，必須要等待“高”、“中”、“普通”這三個隊列的資料全部被發送完成後，“低”等級隊列中的資料才能發送。是以說處于“低”等級隊例的資料很容易被“餓死”，導緻該隊列中的資料一直得不到服務，最終的結果将是應用服務暫停或者終止。

<a href="http://s3.51cto.com/wyfs02/M01/54/5C/wKiom1SAE47jIzhkAAF2ZMgT594298.jpg" target="_blank"></a>

關于優先級隊列PQ的注意事項：

第一、PQ的隊列被充滿時，它将采取尾棄；第二、PQ的隊列長度可以被設定為0，如果把PQ的隊列長度設定為0，這是意味着隊列的長度不受限制，直到用完路由器的記憶體為止，當記憶體被用完後，那麼資料将不能被送入隊例，換而言之，記憶體沒被用完之前，資料包都能被送入隊列排隊，并且不會丢棄資料包，所認值0并不是說該隊列沒長度，但是請記住：别那麼幹，因為當路由器的記憶體被用完的後果，比資料包不能進入隊例更嚴重；第三、PQ中4個隊列預設的長度分别是：高20 中40 普通60 低80；第四、四個不同優先級的隊列中的資料排程時，從整體隊列這個角度講是從高到低，但是如果一串資料都屬于同一個級别的隊列，比如都屬于High隊列，那麼在這個high隊列中的資料将采取FIFO邏輯完成排程。第五、PQ使用三層的ACL或者接入接口、包大小、TCP和UDP的端口号來分類，沒有被明确申明的資料流量将被分類到“預設”類。

注意：如果沒有發生擁塞，從技術角度講就是硬體TX隊列沒有被充滿時，那麼資料将直接送入TX隊列，将不會使用PQ，請記住，隻有在硬體隊列被充滿時才會啟動軟體排隊。PQ 是一種很早、很傳統的隊列方式，當時産生PQ時還沒有後面所描述的CBWFQ和LLQ的産生，是以在在那一定年代中使用PQ來確定一些重要的服務被高品質的保障，但是現今使用PQ的機率已經很少了，因為它被本書後面将要描述的LLQ（低延遲隊列）所代替，這樣做的目标就是能保證重要資料首先被發送的同時，也不至于“餓死”其它隊列的資料。

驗證示範：配置PQ隊列及影響資料傳輸的效果

示範目标：

1模拟一個可能産生擁塞的低速鍊路，并在該鍊路中持續的發送高壓流量。

2驗證先進先出（FIFO）隊列對該環境假定的重要資料（ICMP）傳輸的不良影響。

3 配置PQ隊列将重要資料分類到“高”優先隊列。

4 再次觀察重要資料的傳輸延遲，确定PQ對資料傳輸的影響

5 使用debug工具驗證不同的實時資料分類被送到了不同等級的隊列。

示範環境：仍然使用“驗證示範：FIFO隊列影響資料傳輸的效果”相同的實驗環境。

示範步驟：

R1(config)#access-list 101 permit icmp host192.168.2.100 host 192.168.4.2

R1(config)#access-list 101 permit udp anyany eq rip

R1(config)#priority-list 1 protocol ip highlist 101  

R1(config)#priority-list 1 protocol httpmedium

R1(config)#priority-list1 protocol pppoe normal

R1(config)#priority-list 1 default low

R1(config)#intes1/0

R1(config-if)#priority-group 1

R1(config-if)#exit

<a href="http://s3.51cto.com/wyfs02/M02/54/5B/wKioL1SAFMTSq_KNAALl3n9y4xA855.jpg" target="_blank"></a>

本文轉自 kingsir827 51CTO部落格，原文連結：http://blog.51cto.com/7658423/1586336，如需轉載請自行聯系原作者