Aug 3, 2007

regsvr32.exe 使用技巧解決你的Windows XP頭痛問題

資料來源: 中关村网友社区 http://www.newzgc.com/bbs/

有時候彈出應用程式:........- 應用程式錯誤: "0x......." 指令引用的 "0x........" 記憶體。該記憶體不能為 "written"或read 也可以在運行中輸入CMD 在用命令:for %1 in (%windir%\system32\*.dll) do regsvr32.exe /s %1註冊下所有的dll.也許可以幫你解決問題.Windows XP的“體重”比起其它系統,已經成為一個不折不扣的“大胖子”。各優化“瘦身”技巧早已佈滿各大IT報刊雜誌,望著Windows XP的“Windows”成百上千的DLL(動態連結程式庫)檔,為使系統更清爽,我們可以通過regsvr32.exe程式重新註冊修復和反註冊遮罩系統功能,以減少系統資源。很多朋友都用過Windows系統下提供的regsvr32.exe這個命令。不要瞧不起這個小命令。有時候它可能幫你解決大問題。

一、輕鬆修復IE流覽器
很多經常上網的朋友都有過這樣的經歷:IE不能打開任何新的視窗,。用滑鼠點擊超聯接也沒有任何的反應。這是一般情況下需要重新開機機器或者重新安裝IE就能解決問題。其實根本沒這麼 麻煩,使用regsvr32.exe命令就可以輕鬆搞定。在開始---運行裡輸入“regsvr32.exe actxprxy.dll”回車 確定;再次輸入運行Regsvr32.exe shdocvw.dll”回車。重新開機電腦後IE被輕鬆修復。上網一切正常如初。

二、解決windows無法線上升級的問題
windows漏洞很多。每隔一段時間都需要使用windows update來升級自己的系統。可這個程式總是出現無法使用的情況。這個時候使用regsvr32.exe有可以幫助我們解決這個問題。開始---運行--輸入regsvr32.exe wupdinfo.dll回車。這是系統重新註冊了UPDATE的元件。重新開機機器後有可以升級你的系統。

三、卸載 WIN XP中的雞肋功能
XP系統中有的服務不僅佔用系統資源嚴重,而且功能要強不強,要弱不弱。根本不如一些專業的軟體來的方便。比如它的圖片予覽功能和ZIP壓縮功能。這個時候我們就可以使用regsvr32.exe工具來卸載掉這些雞肋。開始--運行---輸入regsvr32.exe /u zipfldr.dll就可以卸載掉功能。如以後需要這個功能,只需要再次輸入regsvr32 zipfldr.dll即可。同樣,開始-運行---輸入regsvr32.exe /u thumbvw.dll就可以卸載掉圖片予覽功能。需要恢復時輸入regsvr32 thunbvw.dll

四、防範網路腳本病毒有新招
網路腳本病毒會在你流覽網頁的同時不知不覺的被感染。這種病毒有時候一般的殺毒軟體根本查不到。其實這種病毒很多情況下都是調用了FSO物件(file system object檔案系統物件)。因此我們只需要禁止FSO就可以有效的防止這種病毒的傳播。操作的方法也很簡單。開始-運行--輸入“regsvr32.exe /u scrrun.dll就可以禁用FSO。需要時輸入regsvr32.exe scrrun.dll即可。

相信很多朋友看見上面的介紹多少對regsvr32.exe都有了一些瞭解。其實這個命令是windows中控制項檔(副檔名為.dll ,.ocx,.cpl)的註冊和反註冊工具。這個命令在WIN98下的位置在/WINDOWS/SYSTEM中。其實一般情況下,所謂的註冊的意義就是把一些控制項檔放在它應該在的位置上(不嚴格的說)。而有一些系統的控制項或者其它情況下用這個命令就方便的多。關於這個命令的參數,請大家參考此貼的第一個圖。一般情況下只用到/U這個參數。

  regsvr32.exe使用詳解:regsvr32.exe是32位元系統下使用的DLL註冊和反註冊工具,使用它必須通過命令列的方式使用,格式是:
  regsvr32 [/u] [/s] [/n] [/i][:cmdline]] DLL檔案名
  命令可以在“開始→運行”的文字方塊中,也可以事先在bat批次處理文檔中編寫好命令。未帶任何參數是註冊DLL文件功能,其它參數對應功能如下:
  /u:反註冊DLL檔;
  /s:安靜模式(Silent)執行命令,即在成功註冊/反註冊DLL檔前提下不顯示結果提示框。
  /c:控制埠;
  /i:在使用/u反註冊時調用DllInstall;
  /n:不調用DllRegisterServer,必須與/i連用。
  單獨運行regsvr32.exe程式,可以看到彈出一“No DLL name specified”的錯誤提示框,並且可以看到參數原英文提示資訊。
 輸入DLL檔案名時,如果待處理的是非系統檔,必須在檔案名前添加檔絕對路徑,必須注意的是檔路徑不包含中文,否則很可能導致處理失敗。如果碰到regsvr32不能正常執行時,很可能系統檔遭到破壞,因為使用regsvr32.exe時會調用到 Kernel32.dll、User32.dll和Ole32.dll三個檔,在DOS模式或其它系統替換正常檔即可解決.

五、遮罩對壓縮檔的支持
  早在Windows千禧版(Me)時,微軟就在系統內置了對ZIP檔的支持,不過微軟似乎並不關心其功能,以至於在Windows Server 2003的ZIP功能也僅僅停留在把ZIP檔當成資料夾流覽、壓縮等支援。主流壓縮軟體WinRAR已經遍佈天下,Windows自帶的ZIP流覽自然有理由丟之門外。  點擊“開始→運行”,在運行輸入框中輸入“regsvr32 /u zipfldr.dll”(不包括引號,下同),回車即可。同樣,如果不喜歡系統查看CAB壓縮包,輸入“regsvr32 /u cabview.dll”來取消對cabview.dll的註冊。 系統內置了對ZIP檔的支援

六、遮罩視頻預覽和燒錄功能
  每當用資源管理器選中一個視頻檔時,XP會在左側面板預覽顯示,不過這對於較大的視頻檔時,往往要讀上半天。使用者在大多數情況下並不需要預覽,禁止的方法也非常簡單,在運行輸入框中輸入“regsvr32 /u shmedia.dll”即可撤銷視頻預覽。 選中一個視頻檔時,XP會在左側面板預覽顯示

七、遮罩Windows圖片和傳真檢視器
  預設情況下,Windows XP預設的圖片查看工具是“Windows圖片和傳真檢視器”,雖然通過安裝ACDSee等其它看圖軟體可以繞開圖片檢視器,但未真正“消滅”此工具。在運行輸入框中輸入“regsvr32 /u shimgvw.dll”,回車即可棄圖片檢視器於系統外。 安裝ACDSee等其它看圖軟體可以繞開圖片檢視器但未真正“消滅”此工具

八、拯救失落的“搜索”
  不知是與軟體的衝突還是優化錯誤,最近一些朋友的Windows XP的搜索介面空白無物,昔日的搜索助手已“不見蹤影”,右視窗仍然有檔清單方塊,使用其它系統功能正常。何故?  可以肯定,系統的搜索功能檔出錯,後來知道是urlmon.dll此程式庫註冊不正常,解決方法也相當簡單:在運行輸入框中輸入“regsvr32 urlmon.dll”,回車後,重新運行搜索視窗,即可恢復。 系統的搜索功能檔出錯

九、糾正IE保存mht網頁錯誤
  點擊Internet Explorer“文件→另存為”命令功能表,在“保存類型”中選擇“Web電子郵件檔案(.mht)”格式後保存檔錯誤。 在“保存類型”中選擇“Web電子郵件檔案(.mht)”格式後保存檔錯誤   在運行輸入框中輸入“regsvr32 inetcomm.dll”,回車即可解決。  如果在使用 OE時提示“無法啟動Outlook Express。應用程式無法創建字體緩存物件。電腦內容不足或磁片已滿。請與Microsoft支持部門聯繫以獲取更多的幫助。 (0x8007000E,14000)”,點擊“確定”後又彈出“MSOE.dll無法初始化,Outlook Express無法啟動。Outlook Express可能沒有正確安裝。”的提示框,從提示的資訊似乎是系統磁碟空間滿,其實這也是“inetcomm.dll”沒有正確連結導致,通過同樣方法解決。 使用 OE時提示無法啟動Outlook Express。

十、在使用Windows Update更新操作時,提示“IEXPLORE錯誤”,無法繼續更新操作。  首先在運行輸入框中輸入“regsvr32 /u wuv3is.dll”反註冊此程式庫,接著進入“X:\Program Files\Windows Update”(X為Windows XP的在盤符),刪除wuv3is.dll文件。最後重新執行Windows Update操作,系統會重新生成wuv3is.dll檔,錯誤提示也不會再彈出

Aug 2, 2007

Weighted Round Robin(WRR) vs Deficit Round Robin(DRR) vs Modified Deficit Round Robin(MDRR)

◎Weighted Round Robin(WRR)


佇列調度將每個interface分為多個輸出佇列,佇列之間輪流調度,保證每個佇列都得到一定的服務時間,WRR可為每個佇列配置一個加權值(依次為W3、W2、W1、W0),加權值表示獲取資源的比重。


如一個FE interface,配置它的WRR佇列調度算法的加權值為50、30、10、10(依次對應W3、W2、W1、W0),這樣可以保證最低優先等級佇列至少獲得10Mbits/sec頻寬,避免了採用PQ調度時低優先等級佇列中的封包可能長時間得不到服務的缺點。WRR佇列還有一個優點是,雖然多個佇列的調度是輪番進行的,但是對每個佇列不是固定地分配服務時間片段 - 如果某個佇列為空,那麼馬上換到下一個佇列調度,這樣頻寬資源可以得到充份的利用。
(借錢不還)



◎Deficit Round Robin(DRR)


Deficit Round Robin 機制與 WRR 相似,但可適合不同封包長度的應用,並解決了一些WRR頻寬分配不準確的問題(byte count and MTU ratio過大或過小)。DRR 也是和 WRR 一樣去掃瞄每一個有封包的佇列,只不過每次服務固定的 byte count,如果有剩下的byte count,則會被紀錄起來,等待下次再輪到這個佇列時還可使用。
(有借有還)



◎Modified Deficit Round Robin(MDRR)


當我們使用MDRR當成佇列策略時,非空的佇列會以輪流的方式(round-robin fashion)被一個接著一個被服務(發送出去)。每當一個佇列被服務時,一個固定數量的資料從佇列中被送出離開。這個演算法接著再去服務下一個佇列。當某佇列被服務時,MDRR會將被送出佇列的資料位元超出所設定數值的數量記錄下來。下一次,當該佇列被再度服務時,較少的資料會被送出佇列用以補償之前服務超過的資料數量。最後,每個佇列被送出的平均資料數量將會趨近於所設定的數值。附帶一說,MDRR中擁有一個可以被優先服務的優先佇列(Priority Queue)。

在每個MDRR的佇列中定義了兩個變數:

Quantum value – 這是每一輪被服務的平均位元數量。
Deficit counter – 這是用來紀錄每一輪中各佇列被傳送出去的位元數量。初始值等於Quantum value。

只要Deficit counter大於0,在佇列中封包就會被服務。每個封包被服務之後就會將Deficit counter減去封包的位元長度。當deficit counter變成0或是負數之後,該佇列就無法再被服務。在每一次新的循環中,每個非空佇列的deficit counter會被加上各個佇列的quantum value。

附註:總而言之,佇列的quantum size必定不可小於介面的maximum transmission unit (MTU)。這可確保在排程上每個非空佇列至少會服務一個以上的封包。

每個MDRR佇列可以被指定一個相對性的權重(weight),在一個群組中其中一個佇列被定義成一個優先佇列(Priority Queue)。當介面發生擁塞時,這個權重指派了每個佇列相對的可用頻寬。如果在佇列中有資料需要被傳送的話,MDRR演算法將會從每個佇列中以輪流的方式送出資料。

如果所有的標準MDRR佇列中都有資料的話,它們將會以下列方式被服務:

0-1-2-3-4-5-6-0-1-2-3-4-5-6...

在每一個循環週中,佇列可以被發送根據它所設定權重(weight)的位元數量(byte count/quantum)。在Engine 0和Engine 2的介面模板上,數量1就等於給予介面一個相當於它MTU長度的權重(weight)。每增量超過1時,佇列的權重就增加512個位元。比方如,如果特定介面的MTU長度為4470,佇列的權重被設定為3,每次通過循環時,4470 + (3-1)*512 = 5494位元將會被允許發送出去。如果兩個正常的DRR佇列,Q0和Q1,被使用時,Q0被設定的權重為1而Q1被設定的權重為9。如果兩個佇列都發生生擁塞,每次循環週期中,Q0將被允許傳送4470位元,而Q1將會被允許傳送[4470 + (9-1)*512] = 8566位元。這將使得Q0中的流量使用將近1/3的頻寬,Q1中的流量使用約2/3的頻寬。

Aug 1, 2007

Behavior Aggreagate(BA) VS Per-Hop-Behavior(PHB)

◎Behavior Aggreagate(BA)


DiffServ把基於相同PHB轉發的同一群組封包稱為行為聚集(Behavior Aggregate, BA)。每一種DSCP數值可辨識一種BA。


◎(Per-Hop-Behavior, PHB)


DiffServ將重點放在資料流匯集以及適用於整個網路服務等級的"逐跳行為(PHB)"上。我們可以根據預先確定的規則對資料流進行分類,進而將多種應用資料流匯集成有限的幾種資料流等級。核心路由器在調度轉發IP封包時以資料流匯集為服務對象,根據IP封包表頭不同的DSCP提供不同的轉發服務QoS,這種對不同類型的數據封包進行轉發的方式,稱為"逐跳行為"(Per-Hop-Behavior, PHB),實際上是一種相對優先等級機制。

Jul 31, 2007

RSVP Message 解析

RSVP supports the following messages:

1. Path message(PATH):
An RSVP path message is sent by each sender along the unicast or multicast routes provided by the routing protocol. A path message is used to store the path state in each node. The path state is used to route reservation-request messages in the reverse direction.

2. Reservation-request message(RESV):
A reservation-request message is sent by each receiver host toward the senders. This message follows in reverse the routes that the data packets use, all the way to the sender hosts. A reservation-request message must be delivered to the sender hosts so that the hosts can set up appropriate traffic-control parameters for the first hop. RSVP does not send any positive acknowledge messages.

"Each Reservation is Unidirectional"

3. Error and confirmation messages:
Reservation-request acknowledgment messages are sent as the result of the appearance of a reservation-confirmation object in a reservation-request message. This acknowledgment message contains a copy of the reservation confirmation. An acknowledgment message is sent to the unicast address of a receiver host, and the address is obtained from the reservation-confirmation object. A reservation-request acknowledgment message is forwarded to the receiver hop by hop to accommodate the hop-by-hop integrity-check mechanism.

- Path-error message result from path messages and travel toward senders. Path-error messages are routed hop by hop using the path state. At each hop, the IP destination address is the unicast address of the previous hop.

- Reservation-request error messages result from reservation-request messages and travel toward the receiver. Reservation-request error messages are routed hop by hop using the reservation state. At each hop, the IP destination address i the unicast address of the next-hop node. Information carried in error message can include the following:
  • Admission failure
  • Bandwidth unavailable
  • Service not supported
  • Bad flow specification
  • Ambiguous path




4. Teardown:
RSVP teardown messages remove the path and reservation state without waiting for the cleanup timeout period. Teardown messages can be initialed by an application in an end system (sender or receiver) or a router as the result of state timeout. RSVP supports the following two types of teardown messages:

- path-teardown: Path-teardown message delete the path state (which deletes the reservation state), travel toward all receivers downstream from the point of initiation, and are routed like path messages.

- reservation-request teardown: Reservation-request teardown messages delete the reservation state, travel toward all matching senders upstream from the point of teardown initiation, and are routed like corresponding reservation-request messages.

Jul 30, 2007

IntServ VS DiffServ

參考資料:http://www.iii.org.tw/ncl/document/Qos_web.htm

IntServ架構

在IntServ網路中,使用者必須透過RSVP通訊協定來宣告封包流 (packet flow,即一串具有相同來源與目的地之IP位址與port numbers的封包) 的特性 (透過PATH訊息之Tspec參數)以及作頻寬保留 (透過RESV訊息之Rspec參數)。路徑上的所有路由器都必須處理這些RSVP訊息,包括了記錄PATH訊息的路徑、參數,以及依據RESV訊息之參數和路由器資源與link頻寬使用的狀況對使用者要求之頻寬或服務執行允入控制 (admission control)。除了RSVP協定訊息之外,路由器還必須對每一封包執行Multi-Field (MF) calssification以辨識封包流,並對每一封包流執行policing與scheduling。換言之,在IntServ的架構裡,無論是core或edge路由器都必須要能夠辨識、記錄、並且管控每一封包流的狀態。如此一來,隨著網路的逐漸擴張,封包流大量增加,無論是在儲存設備或是處理速度方面對於路由器而言都是一大挑戰,這就是IntServ一直為人所詬病的scalability問題。

IntServ架構提供了定量 (quantitative) 與定性 (qualitative) 兩類服務品質保障 (當然,還有best-effort),它們分別是Guaranteed 以及Controlled Load。

Guaranteed Service提供嚴格的封包延遲與流失量保證,而Controlled Load Service則提供比較級的服務品質 – “Best-effort over uncongested network”,而無定量的保證。



DiffServ架構

DiffServ架構的精神在於它設法簡化core routers的複雜度,盡量將複雜的允入控制交由Bandwidth Broker負責、封包辨識工作交由edge routers負責,並且不提供per-flow QoS,而以比較粗略的per-class QoS取代。

在DiffServ架構中,一個DiffServ Domain可以是一ISP或一企業網路,DiffServ Domain與其使用者之間可以事先簽訂所謂服務品質協議(Service Level Agreement,SLA),DiffServ domain 的網路資源會預先依照SLA內容分配給予使用者。SLA也可以是動態更改的,即Dynamic SLA,此時使用者必須透過一signalling協定,如RSVP,向DiffServ domain要求網路資源,由DiffServ domain中的Bandwidth Broker依據網路狀態作允入控制。若該要求被允許,則bandwidth broker會透過例如COPS (Common Open Policy Service)等協定去調整該要求所經過路徑上的edge與core routers。不同DiffServ domains間的bandwidth brokers也可能會溝通彼此的網路狀態或傳遞使用者的允入要求。

封包在進入DiffServ domain時會先經由edge router區分其類別 (MF classification)、監控其流量、加上標籤 (即DiffServ Code Point,DSCP,或稱DS byte)、以及依其類別對其採取適當的封包排程行為 (即Per-Hop-Behavior,PHB)。之後,DiffServ domain中的core routers就僅依據封包標頭上的DSCP來給予該封包適當的PHB。DiffServ架構中一樣定義有定量與定性的PHB,即Expedited Forwarding (EF)Assured Forwarding (AF)


BE(Best Effort) 000000(0)

EF(Expedited Forwarding) 101110(46)

AF11 001010(10) Low Drop Precedence
AF12 001100(12) Medium Drop Precedence
AF13 001110(14) High Drop Precedence
AF21 010010(18) Low Drop Precedence
AF22 010100(20) Medium Drop Precedence
AF23 010110(22) High Drop Precedence
AF31 011010(26) Low Drop Precedence
AF32 011100(28) Medium Drop Precedence
AF33 011110(30) High Drop Precedence
AF41 100010(34) Low Drop Precedence
AF42 100100(36) Medium Drop Precedence
AF43 100110(38) High Drop Precedence

AFx class can be denoted by the DSCP `xyzab0,' where `xyz' is 001/010/011/100, and `ab' represents the drop precedence bits (RFC-2597).

Queueing機制的比較

參考資料:BDCOM QoS技术

依照我們常見的Queueing(佇列)技術,我們來一一介紹並且比較它們之間的差異性:

1. FIFO(Fist-In/Fist-Out Queue)

它不對Packet進行分類,當封包進入interface的速度大於interface的傳送速度時,FIFO按照封包到達interface的先後順序讓封包進入佇列,同時,在佇列的出口讓封包按照進入佇列的順序離開佇列。



2. PQ(Priority Queue)
將所有的Packet依據預先配置分成最多四類(High/Medium/Normal/Low),按照FIFO的方式分別進入四個優先等級不同的佇列。在封包離開佇列時,高優先等級的的佇列相對於較低優先等級的佇列具有絕對的優先權,等到高優先等級的佇列封包傳送完畢之後,較低優先等級的佇列才可以傳送封包出去,而且較低優先等級的封包在發生擁塞時會被較高優先等級的封包搶佔資源。因此採用這種佇列機制可以保證在網路發生擁塞的情況下,重要服務(設定成高優先等級)的數據傳輸可以得到絕對的優先傳送。但是如果較高優先等級的封包傳送速度總是大於interface的速度時,會使得較低優先等級的封包始終得不到發送的機會。



PQ是一種沒有量化的QoS/DiffServ服務,只定義了預先規定的高優先等級封包擁有優先轉發的權利,甚至有可能會導致較低優先等級的封包永遠沒有機會傳送出去。

3. CQ(Custom Queue)
根據設置將所有封包分成最多16類(Queue 1~16),然後按照FIFO的方式分別進入1個系統佇列(System Queue, Queue 0)和16個用戶佇列(Custom Queue, Queue 1~16)。在封包離開佇列的調度上,系統佇列具有絕對的優先權,系統總是先處理完該佇列後再處理用戶佇列(CQ);16個用戶佇列佔用出口頻寬的比例可以調整,CQ按照定義的比例使得各個佇列之間在佔用的interface頻寬上滿足管理者預先設置的比例關係。當擁塞發生時,CQ可以根據比例保持不同服務獲得相對應的頻寬使用,進而保證重要服務能夠獲得較多的頻寬,又不至於使得非重要服務無法得到頻寬(避免類似使用PQ時可能發生的問題)。



CQ是為了避免PQ在擁塞時,所有較低優先等級的流量資料都無法傳送的問題而發展出來的。

4. WFQ(Weighted Fair Queue)
對於進入路由器interface的封包按照資料流進行分類(相同來源地IP Address,目的地IP Address,來源地Port Number,目的地Port Number,Protocol Number,ToS數值相同的封包屬於同一個資料流),每一個資料流被分配到一個佇列。在離開佇列調度的時候,WFQ根據封包資料流的優先等級(Precedence)來分配每個資料流應該佔用的頻寬。優先等級(Precedence)數值愈小,所得到的頻寬愈少;優先等級(Precedence)數值愈大,所得到的頻寬愈多。在擁塞發生時,它能保證任何流量的資料流(服務),都能公平地得到一定的頻寬使用量,減少這個網路的延遲,並且當資料流(服務數量)的數目減少時,能自動增加現有資料流可佔用的頻寬。也就是說剩下仍在活動狀態的資料流會根據各自的優先權比例瓜分空出來的頻寬資源。

路由器的interface中同時存在8個資料流Sn(n=1~8),這些資料流的優先權Pn(n=1~8)分別為0、1、2、3、4、5、6、7,那麼第n個資料流所佔總頻寬的比重為:(Pn+1)/∑(Pn+1);如第二個資料流所佔總頻寬的比重為:(1+1)/(1+2+3+4+5+6+7+8)=2/36=5.56%。



一個資料流中,所有IP封包的ToS數值相同,所以某個資料流的優先權就是資料流中datagram的ToS值 - 一般情況下,絕大多數的IP封包的default值為0,也就是ToS值為000。

5. CBWFQ(Class-based Weighted Fair Queue)
根據類別加權公平佇列。對於IP封包,CBWFQ通常根據DSCP、input port、IP封包等資訊來對封包進行分類;不同類別的封包分別進入不同的BQ(Bandwidth Queueing)佇列中,如果不能匹配,則進入系統定義的預設佇列;除此之外,還有一個LLQ(Low Latency Queue),它是一個具有較高優先權的佇列,優先權僅次於二層協議佇列和RTP優先佇列。



在離開佇列調度時,如果LLQ中有封包,則總是優先發送LLQ的內容,直到LLQ為空或是超過為LLQ預留的最大頻寬時,才發送其他佇列中的封包 - 這一點和CQ的系列佇列、PQ的High佇列比較類似。

進入LLQ的封包,在interface沒有發生擁塞時(所有佇列中都沒有封包),所有屬於LLQ的封包都可以被發送;而發生擁塞時(佇列中有封包時),進入LLQ的封包能獲得空閒的頻寬,在interface擁塞的情況下,又可以保證屬於LLQ的封包不會佔用超出規定的頻寬,保障了其他封包的應得頻寬。另外,只要LLQ中有封包,系統就會發送LLQ中的封包,所以LLQ中的封包被發送的延遲最多是interface發送一個最大長度封包的時間,無論是時間延遲(Delay)或是抖動(Jitter),LLQ都可以將之降低為最低限度。這對於時間延遲敏感的應用如VoIP服務提供了良好的QoS保證。

BQ佇列在調度離開佇列時,按照用戶設定的頻寬數值將封包發送出去,可以實現各個類別佇列的公平調度。當interface中某些類別沒有封包時,BQ佇列的封包還可以公平地分享空閒的頻寬,大大提高了線路的利用率,當然,在擁塞的時候還可以保證各類別的封包可以得到用戶設定的最小頻寬。

當不能匹配用戶設定的所有類別時,封包會進入系統定義的預設類別(class-default),雖然允許為預設類別設置頻寬,使其作為BQ佇列進行以類別為基礎的佇列調度,但是更多的情況是為預設類別設置WFQ,使所有進入預設類別的封包進行以資料流為基礎的佇列調度。

6. RTP(Real Time Protocol)
這是一種用於解決即時服務(語音、視訊)QoS的簡單佇列技術,其原理就是將承載語音或視訊的RTP封包送入高優先級佇列,使其得到優先發送,保證最小的延遲和抖動。



RTP優先佇列可以同其他的佇列結合使用,它的優先等級是最高的,不過由於CBWFQ中的LLQ完全可以解決即時服務的QoS問題,所以不建議RTP與CBWFQ同時使用。

RTP對於進入的佇列的封包進行了限速,超出規定流量的封包將被丟棄,這樣在interface擁塞的情況下,也可以保證屬於RTP優先佇列的封包不會佔用超出規定的頻寬,保障了其他封包的應得頻寬,避免了PQ中高優先佇列的問題。