其實 Linux 核心已經提供我們許多 queueing disciplines 了。到目前為止﹐應用最為廣泛的是 pfifo_fast 佇列演算法﹐也是預設使用的。這也解釋了為何這些進階功能如此強悍。他們除了只是 '另外的佇列' 以外﹐別無它物。
每一種佇列演算法都各有千秋。不過並非全部都經嚴密測試過的就是了。
望文生意﹐此佇列演算法就是先入先出(First In First Out)﹐接收到的封包﹐均一視同仁。這種佇列演算法有 3 個所謂的 'bands'。在每一個 band 中﹐均奉行 FIFO 的規則。然而﹐只有在 band0 中的封包處理完之後﹐才輪到 band1 裡面的﹔在 band1 和 band2 之間﹐也是同樣的情形。
一如前述﹐SFQ 也不是放之四海皆準的﹐但(平均來說)還是可用的就是了。它主要的好處是﹐它所佔用的 CPU 和記憶體都很少﹐而‘真正’的平等(fair) 佇列法需要核心追蹤所有運作中的連線。
在平等佇列演算法家族中﹐Stochastic Fairness Queueing (SFQ) 算是較為簡明的實作。雖然它不如其它演算法那麼精確﹐不過在保持相當平等的前提下﹐它所需要的運算也較少。
在 SFQ 中的關鍵詞是﹕會談(conversation)(或曰流程(flow))﹐在一連串的數據封包中找到足夠的公約數﹐以區分出不同的 conversation。IP 封包裡面都帶有來源和目的位址﹐以及協定號碼﹐此情形下﹐這些參數就派得上用場了。
SFQ 由動態分配的 FIFO queues 組成﹐一個 queue 負責一個 conversation。而 discipline 則以 round-robin 的形式執行､每次從一個 FIFO 中送出一個封包﹐這就是為何稱之為平等(fair)的原因了。SFQ 的主要好處﹐在於它讓不同的程式平等的分享連線﹐而避免頻寬被單一的客戶程式所佔據。然而﹐SFQ 卻不能從 bulk flows 中判定出互動(interactive)的部份 --- 這需要先在前面的 CBQ 進行篩選﹐然後才將 bulk 流量導入 SFQ 中。
Token Bucket Filter(TBF)是一種簡單的網路佇列演算法。當網路封包經過這個佇列時﹐就會受到一個預先設定的速率限制(封包數/時間)﹐利用這個﹐可以來減緩網路瞬增流量(buffer short bursts)所造成的網路效能降低。
至於 TBF 的實作﹐則由一個緩衝區(bucket) 構成﹐不斷的被一些虛擬資訊﹐稱為 tokens ﹐按特定的速率(token rate) 填充。而緩衝區的重要參數是其體積﹐也就是它所能存儲的 token 數目。
每一個抵達的 token 抵消一個離開佇列的傳入數據封包﹐然後從緩衝區中清掉。另外﹐有兩個流程(flow) 與此演算法息息相關的﹕ token 和 data﹐這一共會帶出三種狀況﹕
最後一種情形千萬不能掉以輕心﹐因為這會強行將頻寬撥給數據﹐而通過過濾器﹐吞舟是漏。至於 token 的積聚﹐則允許超出限制之瞬增流量仍可不被遺失地通過﹐但其後的持續過載﹐均會導致封包被持續的丟棄。
(譯者註﹕這個 TBF 其實不難理解﹐就是 no token no data 原則。token 的載入速率則是固定的﹐而 data 只有獲得相應的 token 才能通過 。)
Linux 核心看起來似乎超過此一規格﹐而且還允許我們限制瞬增流量的速度。然而﹐Alexey 警告我們說﹕
注意﹕TBF 的最高峰值(peak rate) 相當高﹕當 MTU 為 1500 的時候﹐P_crit = 150Kbytes/sec。
所以﹐如果您需要更大的峰值﹐使用 HZ=1000 的 alpha 機器囉 :-)
FIXME﹕不清楚是否仍有 TSC (pentium+) ﹖嗯﹐看來有那麼點兒
FIXME﹕若不然﹐要為提高的 HZ 另闢章節
RED 可算是身懷絕技。當一個 TCP/IP 連線建立起來的時候﹐連線兩端都不清楚到底頻寬會有多大。所以 TCP/IP 會先由低速開始然後逐漸加快腳步﹐最後受制於 ACKs 回應的延遲。
當一條線路滿載的時候﹐RED 就會開始丟棄封包﹐告知 TCP/IP 這條線路已達擁塞狀態﹐需要減低速度了。聰明之處在於 RED 會模擬真正的擁塞﹐同時在線路完全滿載之前開始丟棄封包。一旦線路完全飽和﹐它就擔當起交通警察的角色。
如需更詳細的資料﹐請參考 Backbone 那章。
如果您不想借助於 router 或其它 Linux 機器﹐而要限制特定的主機﹐那麼 Ingress qdisc 會是您的隨身暗器。當頻寬超過您所設定的比率的時候﹐您可以管制入向頻寬及丟棄封包。比方說﹐可以保護您的主機抵禦 SYN flood 的攻擊﹐而且也可以用來降低 TCP/IP 速度﹐也就是以丟棄封包的方法來減速。
FIXME﹕除了丟棄之外﹐我們是否可以將之分配給一個真實的 queue 呢﹖
FIXME﹕以丟棄封包來進行管制似乎並非上上之舉﹐倒不如用 token 緩衝區過濾器。不敢莽斷啦﹐Cisco CAR 也都用這個﹐而且人們似乎也受之若然。
請參考本文最後面的 IOS Committed Access Rate 。
簡而言之﹕您可以用之來限制您電腦下載檔案有多快﹐而騰出更多頻寬給其它用途。
請參考 幫貴主機抵禦 SYN floods 那章﹐那裡有一個例子告訴您它是如何做到的。
此一 qdisc 並不包括在標準的核心裡面﹐但可以從 這裡 下載。目前來說﹐此 qdisc 僅在 Linux 2.2 核心上面測試過﹐應該也可以在 2.4 核心工作的。
WWR qdisc 將頻寬以 weighted round robin 的形式分配給各類別。也就是﹐像 CBQ qdisc 那樣﹐它將類別(classes)包含在可插入的多樣化 qdiscs 中。所有類別均有足夠的請求能力獲得頻寬﹐再均衡的按比重分配給相關類別。比重通常可以用 tc 程式來設定。但是它們(比重)能夠自動的降低﹐以讓給進行大量數據傳送的類別使用。
此 qdisc 內建有一個分類器(classifier)﹐將來自或送往不同機器的封包分配至不同的類別裡去。無論 MAC 還是 IP､不管來源還是目的位址﹐都可以使用。不過﹐MAC 位址只能當這台 Linux 主機作為 ethernet bridge 的時候﹐才能使用。所有類別均自動的依據所見封包分配給不同的機器。
在那些像宿舍那樣的站台﹐存在為數眾多且又互不相干的個體分享同一 Internet 連線的環境中﹐此 qdisc 簡直是尚方寶劍。透過一套 script﹐為這樣一個站台設定出一個恰如其分的運轉狀態﹐正是 WRR 套件的精髓所在。