|
|
我们的争论跟这个帖子主题已经严重偏离。另外我也不知道我们在争论什么。现在的话题是不是变成QOS到底能干嘛了。虽然很喜欢跟人争论dd tt的tc htb到底能做到如何如何的好，但是发现很多人根本不知道我在说什么东西。偶都觉得自己有点自言自语的感觉。你没仔细看过tc htb文档实现，没在现实工作中去实现跟我争论这些话题偶觉得完全是纸上谈兵。
p2p在一个不实施任何QOS队列的路由上，它会表现为大并发抢夺网络带宽。接着就是由于tcp udp消亡时间问题，而导致大量的并发无法及时消亡可表现为CPU，内存消耗严重，或者由于带宽有限，而导致tcp响应不及时从而导致类似网页打开慢的问题。
而QOS能干嘛，QOS本身就是为了解决这种数据先进先出，变成有优先权选择的先进先出。
tc htb有个class分类概念，每个分类里有相应的流量和延迟关系，你在实施QOS时永远要记得流量和延迟的反比关系。所以我喜欢玩CS我就将udp 27080单独置于_10分类享受高优先权出列。但是如果我不将它置于_10，那它就归到_40那组。那组将是任何不确定的远程端口，将有大量的不确定的程序在抢夺那点可怜的上行带宽。结果你会发现什么情况在_10组里玩游戏的ping在6-15波动，如果是在_40分类里将是大范围的视这分类里有多少剩余流量而波动它的波动范围就可能是6-600ms。所以好的路由绝对不会什么内网没人在p2p或者少的情况。它本身就可以通过htb基于端口的调度对它进行压抑性控制让它tcp响应不及时，让它网速直掉。
偶用一个dlink600 b2 2M带30台以上本身就觉得没什么说服力因为我已经注意到这个并发总数的问题。想当年有人轻而易举的用迅雷发起3000个并发就把它弄瘫痪了。可是自从实施了QOS，还没见单IP可以超过900并发的。正是由于带宽太小，所以偶本身还有个使用cron对udp数进行侦测的脚本假定udp数超过50就视为p2p行为使用iptalbes limit对它进行发包数限制，并在forward链启用了reject丢弃让一些没目的tcp udp包快速消亡避免对cpu 内存消耗，它的网速自然就掉下来。虽然tc hb有sfq随机公平出列原则，这确实在现场中也能很好的保证网络连接情况，但是如果你实际带宽过小，发现能够浮动带宽小得可怜。所以偶对8 M 20台电脑平时看pps。20M带180台机器的说法保持中立。
偶现在划的这些端口设定已经没碰到什么特别的问题。
root@onlyit:/tmp# cat port.tmp tcp_5060,6060_10 udp_5060,6060,27015:27018,27050,27060,27070,27080_10 tcp_53,22,23,123,3389,8123_20 udp_53_20 tcp_80,443,1080,1863,8080,12000,14000_30 udp_4000:4030,8000:8001_30 tcp_20,21,25,1024:65535_40 udp_1024:65535_40
|
|
简体中文
繁體中文
English
日本語
Deutsch
한국 사람
بالعربية
TÜRKÇE
português
คนไทย
IP卡
狗仔卡
发表于 2012-9-3 15:08
显身卡
