基地台與分享器 - 【請教】刷Tomato 後 Qos 的最佳化設定 - 電腦

前往內容


【請教】刷Tomato 後 Qos 的最佳化設定

刷了蕃茄以後 , 看到裡頭 Qos 的設定霧煞煞... 可否請達人分享一下最佳化的設定... 我主要是希望別人看 PPS 或
下載 BT & FOXY 不會影響到其他人上網、玩 GAME 就好了 ...

還是說上述的要求對於 Tomato 來說是不太可能的任務???

P.S : 我有爬文 , 但這類的分享真的很少... 機器是 BUFFALO WBR-G54 老機所改的...
你tomato是刷哪一版?就個人的經驗來說,1.25版以前的QoS似乎怪怪的,1.26以後的才正常。


簡單來說,tomato裡頭的QoS讓你最多可以定義出最多10個不同的等級(Highest ~ Class E),每個等級你可以設定兩個參數:保障頻寬和使用頻寬上限。


在保障頻寬方面,tomato會從優先權最高的等級開始檢視,看看是否已經滿足了該等級的基本需求(保障頻寬)?
若已達成,那就繼續檢視下一個等級,分配剩餘頻寬。
若還不夠,而且已經沒有剩餘頻寬了,那就去限制優先權較低的等級,壓榨出夠多的頻寬來滿足當前等級的需求。
假如還有剩餘頻寬,那表示目前的等級本身沒用到那麼高的頻寬,那就跳過不理它。

至於頻寬上限那就比較簡單,不准你用超過就對了,用超過就限速。



再來你可以設定條件(Classfication),看哪些狀況要歸類於哪個等級(優先權)。這些條件可以是特定的服務、特定的PORT、特定的電腦... 等等,至於要怎麼設定,真的要看每個人的使用環境而定,沒有一個通用的最佳化設定值。


你文中沒有提到你的網路環境,所以我用我這邊的狀況當例子:
我有一台獨立的NAS,上面會跑P2P軟體,也有開FTP server。另外有一台NB會使用到網路,但上面沒有跑一些常態性的服務。

所以我這邊的大原則也很簡單,在我人不在家的時候,我希望BT/P2P可以全速跑,充分利用到所有的上傳頻寬;但有時候我人在外面,會用FTP連回家中的NAS抓資料,這時我會不希望FTP的速度被P2P流量影響了,所以FTP的優先權要高一些。但當我人在家裡用NB上網時,我希望不管我在跑什麼程式,都不會被影響到,所以NB的優先權更高了。


於是,我設定一個優先權最低的等級給BT/P2P。我只保障它5%的頻寬,但頻寬上限可以用到100%。
FTP給它高一點的等級,保障它90%的頻寬,上限95%。
NB的等級又更高,保障80%的頻寬,上限100%。

這其中BT/P2P/FTP都是在NAS上,所以IP相同,在classfication時,就必需要以服務當過濾條件。
至於NB,因為我希望不管我在NB上做啥事,都能有最高的優先權,所以我可以用來源IP(甚至用MAC)當過濾條件就可以。


所以實際的運作狀況大概會是這樣:
雖然NB和FTP都有相當高的保障頻寬,但平常沒在用時,這些頻寬需求是不存在的,所以P2P可以很快樂的用滿100%上傳頻寬。

當FTP開始傳檔時,我保障它最少可以用到90%的頻寬,這樣傳起來才有效率。但為什麼不用到滿,還留了10%?因為我希望優先權較低的P2P還能糊口飯吃,保留基本的連線能力,這也是我給P2P一個5%的基本保障頻寬的用意。
基於優先權的原則,要是FTP的保障頻寬開到100%,那表示就沒有剩餘頻寬給優先權較低P2P使用,這時候就算你給P2P 50%的保障頻寬也沒用。

當我人在家裡,開NB上網時,雖然上傳頻寬基本上都是P2P拿去用了,但一旦NB有流量需求,P2P(甚至FTP)的流量會立刻被限制住,撥出足夠的頻寬給NB的即時需求使用,所以上網也不會lag。
因為NB上不會做什麼大事業,真正會用到的上傳頻寬其實也不大,所以保障80%頻寬只是用來應付一些臨時性的流量,比方說MSN/SKYPE傳檔給別人... 之類的。
前一篇都只是文字敍述,看了可能會一頭霧水,這裡我把實際的設定PO出來當例子。

首先,是Base Setting的部分:



這邊要注意的是,上傳頻寬不要設太高,要不然頻寬管理的效果會不好,甚至會沒有效果。
比方說我的網路是10M/2M,理論上Outbound rate應該可以設到2000 kbit/s。

但是QoS有一個基本概念,就是要把有限的資源做適當的分配。
Outbound rate設多少,就是告訴tomato你手上有多少的頻寬可運用。當你的流量需求超過你旳可用頻寬,tomato就會出面介入,著手頻寬的分配。

要是你的上傳頻寬,可能因為線路的品質、ISP的設限... 等等因為,實際上只能跑到1600 kbit/s,但你還是設定成2000 kbit/s,那你怎麼跑都不出2000 kbit/s以上的速度,那對QoS來說,是你的流量需求還沒到瓶頸點,你還有足夠的頻寬可以運用,所以它也不需要介入調停。但實際上,底下的程式已經為了那1600 kbit/s的總頻寬搶得你死我活了,這時候QoS就達不到保障頻寬的效果。

要是Outbound rate設得太接近極限,也有可能被實際頻寬的即時變化而影響,而導致QoS效果不是很理想。
比方說你實際上的上傳頻寬會在1900 ~ 2100 kbit/s之間波動,而你設定成2000 kbit/s。
當今天網路狀況比較好,頻寬有到2100 kbit/s時,QoS的工作就很正常,只是你吃不太到多出來的那100 kbit/s。
但要是網路狀況爛了一點,頻寬剩1900 kbit/s時,前一段所講的狀況就會出現了。

所以Outbound rate要設多少,可以用理論值當依據,再依實際的狀況去調整,找出一個最適值。
至於QoS的效果好不好,可以由Bandwith的MRTG圖表看出來。
正常來說,流量的狀況不應該有很大的波動(以下圖為例,藍色部分為上傳)。



至於什麼是波動很大的狀況,把Outbound rate設大,或把QoS關掉,然後全速上傳就知道了。



再來是Classification:



這個filter table的設定有個原則:它是照順序一條一條rule下去跑的,所以越明確、越容易判斷出來的條件,就盡量往前面排;越容易混淆,或是需要較多時間判斷的,就往底下排,這樣子可以增加每一條connection的辨識效率。

在最底下,則是擺一個Bulk Traffic。也就是不match上面所有的rules的,就歸到這一類來。所以,Bulk Traffic之下不要再有filter rule,否則當tomato判斷到Bulk Traffic時,就直接歸類了,之後的rule怎麼樣也判斷不到。

舉例來說,我判斷NB用的條件是MAC address,這是可以很明確判斷出來的,所以放在最前頭。
再來,一些DNS、WWW的連線,因為也有很明確的PORT可以判斷,所以擺中間。
最後則是一些P2P的判斷條件。因為P2P的連線很難用PORT去加以判斷,所以這時可以利用QoS所提供的L7 filter。
不過L7 filter在運作時,需要花一些時間分析pattern,而且命中率也不是百分之百。所以有些已知固定PORT的連線,可以獨立成一條rule,加速tomato的判斷。
或者是,有些連線你想有獨立的保障頻寬,所以必需要另外分類,你就要另外寫一條rule,免得被L7 filter通通歸在同一類。


另外有一點要提的是,有關Donkey/BT請照實際的狀況下去設定,別照抄圖中的值,有些PORT是我依需求有調整過的。


底下的圖表為網路閒置時的狀況:



可以看到絕大部分流量都是P2P/BT吃掉的。但因為我有保障Tomato Web GUI的頻寬,所以從外面連回去看tomato的狀況一樣是很順暢。


再來是有FTP上傳的情形:



大部分的頻寬都給FTP給佔去了,Class B、E都被限制到只剩保障頻寬,Class C、D因為本來流量就沒吃超過保障值,所以沒差。

不過由這個圖表看來,FTP連線是Class Medium,應該是要有90%的保障頻寬的,但實際上只吃了70%左右。
可能是ISP之間的關係,所以上傳的速度被限制住了;要不然就是Class A~E的優先權可能不是最低的,反而比Class Medium還高。這個問題點還有待確認。

Bomba 大,寫的太精采了,一定要複製下來。只可惜無法為你加分。

Bomba wrote:
簡單來說,tomato裡頭的QoS讓你最多可以定義出最多10個不同的等級
再補充說明一下Base Setting的部分:

Class Highest ~ Class E這十個class,完全是依照個人需求去設定。若使用環境很單純,也不用設定那麼多條。
不過class設定數目的多寡也無關效能,那只是分類依據而已。
有需要就分類細一點,沒需要就兩、三條簡單搞定。

由網路上所得到的資訊,Class A ~ E的優先權應該是比Class Lowest還低的(如有錯誤請指正)。

所以既然我需要把分類弄細一點,於是就把Bulk Traffic設到Class E去,Default Class也設成E,也就是新連線一進來,在還沒過濾出是哪個class之前,會先進Class E去吃大鍋飯,共享Bulk Traffic的剩餘頻寬,等pattern分析出來後才會依等級去享有或限制頻寬。
這邊再分享一下針對eDonkey和BT的頻寬限制的作法。

不管是eMule或BT,連線大概可分為兩種:一種是對server或其它client交換資訊,一種是用來傳遞資料。
對於前者,我會希望它保持暢通。這種連線佔的頻寬不多,但要是資訊交換得不順利,來源取得慢,速度就別想提昇。
至於後者,基於分享原則,我當然是要放頻寬給它,但我不希望它影響了正常的網路運作,所以我要適度的限制它。


要怎麼做?當然是想辦法把它們區分出來啦!



Rule 1~3是給BT用的,4~6則是針對eDonkey,作用如下:

1. 針對UDP封包,開L7 bittorrent,把BT的資訊交換連線過濾出來。
2. IP來源設定為BT所在的機器,PORT為BT PORT(此例為8080),TCP/UDP封包,把BT的上傳連線濾出來。
3. 針對TCP封包,開L7 bittorrent,前兩條rule沒濾出來的,視為BT資訊交換連線。
(rule有其先後順序關係)

4. IP來源設為eDonkey所在的機器,PORT為eDonkey PORT(此例為5839),TCP封包,先過濾出eDonkey的上傳連線。
5. IP來源設為eDonkey所在的機器,TCP/UDP封包,開L7 edonkey,過濾出eDonkey的資訊交換封包。
6. 對TCP/UDP封包,開L7 edonkey,撈剩下的漏網之魚,視為eDonkey的上傳連線。
(rule有其先後順序關係)




下圖是跑起來的成果:



Class A:BT的資訊交換連線。
Class B:eDonkey的資訊交換連線。
Class C:BT的上傳連線。
Class D:eDonkey的上傳連線。
Class E:Bulk Traffic。

以這樣子的作法,大概可以濾出9成5以上的eDonkey連線,最少在我這邊所觀察到的情況,具有"頻寬威脅"實力的連線,都有辦法被抓出來,丟到Class D裡去。在Bulk Traffic裡偶爾會看到幾條漏網的資訊交換連線,不過那已經無傷大雅了。

所以我只要控制Class D的頻寬限制,就可以掌握eDonkey在我網路裡的頻寬使用量,不需要在程式中另外限速。



至於BT,就比較頭大一點。因為BT是可以有加密連線的,一旦加密,就別指望L7 filter可以辨識出來。再加上BT用來傳資料的PORT也很動態,所以原則上也很難由PORT的範圍去加以過濾。
能被濾出來的,會被丟到Class C,剩下的,就只能當Bulk Traffic處理。

所以對於BT來說,我採取的是比較消極的作法,雖然規範了3條rule給它,但與其說是限制它的上傳頻寬,倒不如說是保障它的資料交換連線的順暢(給它Class A)。


所以在有BT的網路環境中,除非在BT程式端主動限速,不然很難在tomato上去限制BT所吃的上傳頻寬,除非你想對Bulk Traffic限速(但同時也限到其它未過濾的連線了)。
在這種情況下,針對你想要的網路服務進行頻寬保障,會是比較合理的作法。



PS. 從Class A和Class B的頻寬使用量來看,根本是可以合併在一起的。把它分開只是為了方便了解BT和eDonkey各別的連線數量狀況而已。

cal636633 wrote:
刷了蕃茄以後 , 看...(恕刪)


上了一課....
感謝大大無私的分享心得,推推推....
我要幫您推薦一下....
大大請加油....
Bomba wrote:
前一篇都只是文字敍述...(恕刪)



太感謝 Bomba大 了~
整個大原則的理念,對照實際設定都非常清楚得演繹出來
對我這個 100% 新手幫助太大了 Q_____Q

有兩個不理解的部分請 Bomba 指導一下~

首先看『底下的圖表為網路閒置時的狀況』的圓餅圖
發現 Low 這個分級並沒有任何連線數 (for BT tracker & WWW512K+)
是否代表 BT tracker port 6969 並不是 "對server或其它client交換資訊" 的port?
那如何知道真正「對server或其它client交換資訊」是落在 分類B或E 呢?
會不會有BT「傳遞資料」的頻寬偷跑進 class-B 而吃到 10% 保障頻寬?
B:10~25%,E:5~95%

另一個問題
Bomba大在實驗分析BT封包的時候
下載(分別UDP/TCP)在分類A統計,上傳在分類C統計(包含TCP/UDP)
從這兩種分類,怎麼得知哪些是 "對server或其它client交換資訊" 又哪些是 "傳遞資料" 呢?
(因為我對BT走的協定也不懂,是故意把BT程式上傳port限定在8080得知的嗎?)
分得出這兩種,才能把交換資訊擺class-B,傳遞資料擺class-E 是嗎?

謝謝唷

1頁 (共3頁)

前往




此文章的引用連結