刷了蕃茄以後 , 看到裡頭 Qos 的設定霧煞煞... 可否請達人分享一下最佳化的設定... 我主要是希望別人看 PPS 或
下載 BT & FOXY 不會影響到其他人上網、玩 GAME 就好了 ...
還是說上述的要求對於 Tomato 來說是不太可能的任務???
P.S : 我有爬文 , 但這類的分享真的很少... 機器是 BUFFALO WBR-G54 老機所改的...
個人積分：31分
文章編號：21543240
簡單來說，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傳檔給別人... 之類的。
個人積分：11分
文章編號：21574686
個人積分：31分
文章編號：21589297
首先，是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還高。這個問題點還有待確認。
個人積分：263分
文章編號：21603882
個人積分：14分
文章編號：21633965
個人積分：31分
文章編號：21654979
Class Highest ~ Class E這十個class，完全是依照個人需求去設定。若使用環境很單純，也不用設定那麼多條。
不過class設定數目的多寡也無關效能，那只是分類依據而已。
有需要就分類細一點，沒需要就兩、三條簡單搞定。
由網路上所得到的資訊，Class A ~ E的優先權應該是比Class Lowest還低的(如有錯誤請指正)。
所以既然我需要把分類弄細一點，於是就把Bulk Traffic設到Class E去，Default Class也設成E，也就是新連線一進來，在還沒過濾出是哪個class之前，會先進Class E去吃大鍋飯，共享Bulk Traffic的剩餘頻寬，等pattern分析出來後才會依等級去享有或限制頻寬。
個人積分：31分
文章編號：21771627
不管是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各別的連線數量狀況而已。
個人積分：13分
文章編號：21997428
個人積分：28分
文章編號：22166787
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 是嗎？
謝謝唷
關閉廣告