The Wonder Shaper

奇蹟整形是一個很大的特點非常特殊的網絡腳本成型機。在Linux 2.4及更高版本。
進球
我試圖創建的制勝法寶：
*保持對interfactive交通低延遲在任何時候。
這意味著，上傳或下載文件不應該打擾SSH或遠程登錄連。這是最重要的事情，即使是200ms的延遲是呆滯地工作過。
*允許“衝浪”以合理的速度，同時向上或下載
儘管HTTP是'大頭'流量，其他流量不應淹沒了太多。
*請務必上傳不傷害下載，和周圍的其他方式
這是一個非常觀察到的現象，其中上游業務只是破壞的下載速度。原來，這一切都是可能的，在帶寬的一點點的費用。即上傳，下載和ssh傷害海誓山盟的原因是大型隊列像電纜或DSL調製解調器國內眾多接入設備的存在。
為什麼它默認情況下不正常工作
互聯網服務供應商知道他們是如何快的人可以下載單獨基準。除了可用帶寬，下載速度由丟包，嚴重阻礙了TCP / IP的性能影響很大。大隊列有助於防止packetloss，加快下載。因此，互聯網服務供應商配置大型隊列。
然而，這些大隊列損壞互動。 A擊鍵必須先前往上游的隊列，這可能是秒（！）長，去你的遠程主機。它然後顯示，這導致分組回來，那麼它必須遍歷下行隊列，位於您的ISP，它出現在屏幕上之前。
這個HOWTO教你如何裂傷和處理在許多方面的隊列，但遺憾的是，並不是所有的隊列訪問美國。隊列在ISP處是完全禁地，而上游隊列可能住電纜調製解調器或DSL設備內部。你可能會或可能不能夠對其進行配置。最有可能不是。
那麼，接下來呢？由於我們無法控制的任何隊列，它們必須被淘汰，並移動到你的Linux路由器。幸運的是，這是可能的。
限制上傳速度有點
通過限制我們的上傳速度略低於真正的可用率，沒有隊列建立在我們的調製解調器。該隊列現在轉移到Linux上。
限制下載速度
這是稍微複雜一些，因為我們無法真正影響網絡船舶我們如何快速的數據。然而，我們可以刪除那些即將在太快的數據包，這將導致TCP / IP放緩只是我們想要的速度。因為我們不想丟棄不必要的流量，我們配置一個'爆'的大小，我們允許以更高的速度。
現在，一旦我們做到了這一點，我們已經完全消除了下行隊列（除了短時間），並獲得與所有的Linux電源管理提供上行隊列的能力。
讓交互通信跳過隊列
剩下的工作就是確保交互式流量跳轉到上游隊列的前面。為了確保上傳不要傷害下載，我們也將ACK數據包隊列的前面。這是通常會導致大宗產生兩種交通方式時，觀察到的巨大的經濟放緩。致謝下游流量必須與上游競爭的流量，並獲得延遲的過程。
我們也將其他的小數據包隊列的前面 - 這有助於它不設置TOS位，就像一切從微軟的操作系統。
允許用戶指定低優先級的流量（在1.1新！）
有時你可能會發現低優先級的輸出流量減慢重要的交通。在這種情況下，下列選項可以幫助你：
NOPRIOHOSTSRC
設置為主機或網絡掩碼網絡中應該有低優先級
NOPRIOHOSTDST
將此設置應具有低優先級的Internet上的主機或網絡掩碼
NOPRIOPORTSRC
將此設置應具有低優先級的源端口。如果你有一個網絡服務器不重要您的流量，設置為80
NOPRIOPORTDST
將此設置應具有低優先級目標端口。
見wshaper和wshaper.htb開始
結果
如果我們做到這一切，我們得到利用XS4ALL在荷蘭一個極好的ADSL連接以下測量：
基線潛伏期：
往返最小/平均/最大= 14.4 / 17.1 / 21.7毫秒
沒有交通調節，在下載：
往返最小/平均/最大= 560.9 / 573.6 / 586.4毫秒
沒有交通調節，同時上傳：
往返最小/平均/最大= 2041.4 / 2332.1 / 2427.6毫秒
與空調，220kbit / s的上傳過程中：
往返最小/平均/最大= 15.7 / 51.8 / 79.9毫秒
與空調，850kbit / s的下載過程：
往返最小/平均/最大= 20.4 / 46.9 / 74.0毫秒
當上傳，下載在著手〜80％的可用速度。載在90％左右。潛伏期，然後跳轉到850毫秒，還是弄清楚為什麼。
你可以從這個腳本期望在很大程度上取決於你的實際的上行速度。當全速上傳，總會有一個數據包的提前擊鍵。這是下限就可以實現延遲 - 將您的MTU通過你的上行速度來計算。典型值將比稍高。降低你的MTU為更好的效果！
一張小桌子：
上行速度|預期的延遲，由於上傳
--------------------------------------------------
32 | 234ms
64 | 117ms
128 | 58ms
256 | 29ms
因此，要計算你的有效延遲，取基線測量（平上卸載鏈接），並查找號碼表，並添加它。這是關於你可以期望的最好的。這個數字來自一個計算是假定你的上游按鍵將有一半最完整大小的數據包在它前面。
這可以歸結為：
   MTU * 0.5 * 10
   -------------- + baseline_latency
       千位
在10倍是不太正確的，但在實踐中效果很好。
你的內核
如果你運行一個最近的分佈，一切都應該是好的。您需要2.4具有QoS選項打開。
如果您編譯自己的內核，它必須啟用一些選項。最值得注意的是，在網絡選項菜單，QoS和/或公平排隊，把至少CBQ，PRIO，SFQ，入口，流量監管，QoS支持，速率估計，QoS的分類，分級U32，fwmark分類。
在實踐中，我（和大多數發行）剛打開的一切。
腳本
該腳本有兩個版本，其中一個工作在標準的內核，並使用CBQ實現。另一種採用了優秀的HTB隊列規定是不是在默認內核。該CBQ版本比HTB多一個測試！
見“wshaper'和'wshaper.htb”。
調音
這些腳本需要知道您的ISP連接的“真實”利率。這是很難確定的前期不同的互聯網服務供應商使用不同種類似乎位。人們使用以下技術報告成功：
估計你都上游和下游的一半速度您的ISP指定。現在驗證如果腳本運行 - 檢查交互，同時上傳和下載時。如上計算這應交付的等待時間。如果沒有，檢查如果腳本沒有錯誤執行。
現在慢慢增加上下游數腳本，直到延遲回來。這樣，您就可以找到您的連接的最佳值。如果你是快樂的，請報告給我，讓我可以使這項工作順利號碼列表。請讓我知道您使用的ISP和你的訂閱，它被譽為規格的名稱，這樣我就可以在這裡列出你和拯救他人的麻煩。
安裝
如果您撥打的，你可以將腳本複製到/etc/ppp/ip-up.d，它會在每次連接運行。
如果你想從一個接口取出成型機，運行'wshaper停止“。要查看狀態信息，運行'狀態wshaper“。
已知問題
如果出現錯誤，一個-x添加到第一線，具體如下：
＃！/斌/ bash的-x
然後重試。這將顯示出哪些行給出了一個錯誤。在聯繫我，請確保您運行的是最新版本的iproute！
最近的版本可以在你的Linux發行商被發現，或者如果你喜歡編譯，在這裡：
 ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz