285P果然是带机王

andyx***

有个virtual**的服务端就好了。

Eki***

TT限制端口可以用 IPTABLES 简单点可以 用 nocat splash
好像访问限制也能做到（没测试

haosh***

速龙电脑 发表于 2012-8-31 15:08
我真是对牛弹琴，还跟我钻流量，你觉得作为网络管理员的我，会白天下东西吗？晚上2点到早上8点下 ...

我真是对牛弹琴晚上，我要说的是你不能单看你的内网一天有30G的流量就说明有10几个台机在看电影，大流量很有可能是挂PT的流量，你都知道你的3个1T 1个1.5T  1个2T的硬盘都装爆了，难道就你才有3个1T 1个1.5T  1个2T的硬盘？就单以内网一天有30G的流量就说10几台机同时看电影未免太武断了，要是错开时段的你说的不就是废话，就个别上网看电影，其他的不看电影你的网络带30台机都没有问题
  还有我告诉你网络游戏对网络带宽不感冒对网络延时才感冒。

da***

tc htb算法 iptables标签 都是很神奇的东西如果你习惯写QOS脚本，你就会发现dd tt类的QOS效果很NB。当然QOS是个很有环境针对性的东西，别指望有一个通用的脚本可以解决不同人的网络环境。

有些数据可能夸张了点，但是linux下可能还真有这样的夸张的情况可以发生。sfq算法,prio权限都可以实现很多具体的抢夺方式。看过很多什么企业级先进级NB级的路由的那可怜的QOS设置界面基本都停留在ip限速级的，要知道脚本的灵活性选不是WEB那单调的设置界面能实现的。tt的原版QOS是对tc工具的最佳表现。但是依然还是要注意流量60,80和延迟的关系，这也是为什么很多人觉得tt QOS效果不怎么样的情况发生。

游戏延迟在linux tc调度的路由里延迟是很好控制的，你只要给出它个class分类，这个分类里的流量不要塞满。然后总体流量又保证在60-80比例里。ping一定很好看。

所以偶在一根20mbps下行的光纤 1mbps上行。上行接口只做ppp0针对端口的QOS控制，下行原则上可以不控制。不过如果为了让游戏的ping更好看更稳定点，可以再单独限制下行br0接口每个ip 135kb-500kb 那么ping基本就在10以内跳动了。

都说磊科的QOS很NB，但是我从来没见有人公布过它的脚本，倒反而有人说它延迟很高。但是我相信神奇的脚本再根据具体的网络环境进行逻辑判断实现是能达到很夸张的QOS效果的。

soil***

  纯交换机 带机不成问题了 牛叉的不是285 只是ROS 其实真没必要....浪费资源..一个ROS 你想分网控制加多一张网卡就好了了 浪费啊!!!!!!  再牛叉也是一垃圾!!!!! 反而235W 236W 还可以用一下

dcl***

soilfish 发表于 2012-9-2 08:15
纯交换机 带机不成问题了 牛叉的不是285 只是ROS 其实真没必要....浪费资源..一个ROS 你想分网控制加多一 ...

麻烦仔细看帖子再喷·····

285P要的是行为管理限制连接数，ROS限制连接数很差劲，我也知道只用ROS简单

再说了，谁说285P工作在交换机模式，235W带机超不过30，我试过，一天以后连配置界面都进不去

soil***

ROS限制连接数很差劲  一点都不差....ROS 限连接是最好的

sse***

285p的机子是国产入门级最实用的也是最好用的，带机量看设置的人跟网络，4m电信带黑吧17台无压力，qos会用跟不会用差很远，磊科的各个型号qos有出入，各种路由过手的也不算少，大企业大网吧手头上做着几个，本人认为285p这个价对得起性价比这个单词了，学习的东西谦虚一点的好，你做不到的东西不代表人家不行，人家做到了你就得学一下为什么可以，为什么自己不可以，在这里骂得翻天最后什么也没有，证明不了什么，你认为不行观点说一下再来张图，路由各有各的优点，坦白的说linux内核的不喜欢，但不少高档货在用，喜欢freebsd的可是硬路由中很少，ecos的感觉很好可惜多核多wan都是linux的内核天下。客观的说一句，什么好用就用什么。

dcl***

soilfish 发表于 2012-9-2 10:50
ROS限制连接数很差劲  一点都不差....ROS 限连接是最好的

你要是不信可以在ROS前面加个防火墙试试看

TCP连接数还好，UDP连接数很不准，调延时也不行，容易误伤，打游戏的时候很容易卡掉

打游戏最好的还是wayos或者ROS不开连接数限制，延迟很低，磊科的路由器不开行为管理和智能QOS延迟也很小

话不能说的太满，每个系统都有优缺点，能连接起来用取长补短才是王道

速龙***

sse9880 发表于 2012-9-2 12:20
285p的机子是国产入门级最实用的也是最好用的，带机量看设置的人跟网络，4m电信带黑吧17台无压力，qos会用跟 ...

正解，说得很不错，有些小白连用都没用过几个路由，就在这啊之啊嘬（洛里啰嗦），我的8M光纤带20台都被小白说成神马。。。无语啊

不过说285P是入门就错了，人家定位可是中高端的，只是现在改版的多了，被沦落了

soil***

  确实是这样 ros 2M 电信ADSL  设置好了 带 20没问题 4M 30左右 8M 50台 如果光纤 我之前做大的网吧时是 20M 电信光纤拉 180台 后来扩到 250台

da***

你们的数据怎么一个比一个夸张。。。。都用的什么设备。20mbps*1024kbps/8=2560kb/s/180=14.222kb

看我的dlink600 b2 ddwrt build 14311 2M ADSL 240kb/65kb tc做的基于端口的QOS，虽然看起来有38台。实际网络连接很小。昨天最高也就见到1200多个并发数。偶现在发现在_40这组如果有大量的p2p连接依然会导致在20M的线路上网络缓冲不及时。当然也许可以考虑用限制连接数的方式，但是这种方法方法基本不考虑。linux下的tc只能限制tcp协议吧。UDP是个没方向的协议tc可没说它可以限制。dd下匹配模块有限，当有机器连接数超标偶就用个limit模块进行发包数量限制然后在forward链启用REJECT丢弃让udp协议快速消亡以避免占用CPU和内存资源，在低带宽下可以保证端口应用服务正常，但是最终实际可以浮动的带宽也少得可怜。

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

root@onlyit:/tmp# ip n
192.168.8.44 dev vlan3 lladdr 00:1a:4d:83:aa:a9 STALE
192.168.12.243 dev br0 lladdr f4:ec:38:09:62:96 DELAY
192.168.8.42 dev vlan3 lladdr 00:1a:4d:83:cb:b0 REACHABLE
192.168.8.11 dev vlan3 lladdr 00:1a:4d:65:69:0a DELAY
192.168.9.13 dev vlan5 lladdr 00:1a:4d:83:ca:fb STALE
192.168.12.71 dev br0 lladdr d0:df:9a:cb:6d:46 REACHABLE
192.168.12.36 dev br0 lladdr 00:19:e0:8e:81:78 STALE
192.168.8.53 dev vlan3 lladdr 00:1a:4d:83:ae:25 STALE
192.168.8.45 dev vlan3 lladdr 00:1a:4d:83:aa:36 REACHABLE
192.168.8.46 dev vlan3 lladdr 00:1a:4d:83:aa:60 REACHABLE
192.168.8.55 dev vlan3 lladdr 00:16:e6:9d:3b:2d STALE
192.168.8.43 dev vlan3 lladdr 00:1a:4d:83:ca:13 REACHABLE
192.168.12.40 dev br0 lladdr 00:19:e0:8e:7a:89 STALE
192.168.8.12 dev vlan3 lladdr 00:16:e6:9d:1f:fd STALE
192.168.12.205 dev br0 lladdr 88:c6:63:76:b2:99 STALE
192.168.8.23 dev vlan3 lladdr 00:1a:4d:65:69:14 DELAY
192.168.9.11 dev vlan5 lladdr 00:1a:4d:65:e2:24 STALE
192.168.12.207 dev br0  FAILED
192.168.8.36 dev vlan3 lladdr 00:16:e6:9d:3b:67 DELAY
192.168.8.56 dev vlan3 lladdr 00:1a:4d:65:68:f6 DELAY
192.168.8.34 dev vlan3 lladdr 00:1a:4d:65:dc:13 STALE
192.168.8.32 dev vlan3 lladdr 00:16:e6:9d:3a:5c REACHABLE
192.168.8.41 dev vlan3 lladdr 00:1a:4d:83:cc:01 REACHABLE
192.168.8.16 dev vlan3 lladdr 00:1a:4d:6b:c9:50 REACHABLE
192.168.8.21 dev vlan3 lladdr 00:16:e6:9d:3b:50 DELAY
192.168.8.52 dev vlan3 lladdr 00:1a:4d:6b:d9:ae STALE
192.168.8.26 dev vlan3 lladdr 00:16:e6:9d:23:9f DELAY
192.168.8.13 dev vlan3 lladdr 00:1a:4d:65:dc:61 REACHABLE
192.168.8.51 dev vlan3 lladdr 00:1a:4d:65:dc:51 REACHABLE
192.168.8.31 dev vlan3 lladdr 00:1a:4d:65:e1:7c DELAY
192.168.9.12 dev vlan5 lladdr 00:1a:4d:65:dc:6b STALE
192.168.8.22 dev vlan3 lladdr 00:1a:4d:65:69:00 REACHABLE
192.168.12.206 dev br0 lladdr 00:1f:3c:69:2e:32 REACHABLE
192.168.8.25 dev vlan3 lladdr 00:1a:4d:83:df:df REACHABLE
192.168.8.100 dev vlan3 lladdr 00:16:e6:9d:37:43 STALE
192.168.8.15 dev vlan3 lladdr 00:1a:4d:65:e1:f1 REACHABLE
192.168.12.75 dev br0 lladdr c8:3a:35:cd:b8:c3 REACHABLE
192.168.12.66 dev br0 lladdr dc:2b:61:74:05:a1 STALE
192.168.12.70 dev br0 lladdr d8:b3:77:90:12:0e REACHABLE
root@onlyit:/tmp# ip n|wc -l
39
root@onlyit:/tmp# ./conn_dato.sh
192.168.8.44    connection count:TCP 5   UDP 0   _?
192.168.12.243  connection count:TCP 0   UDP 0   _?
192.168.8.42    connection count:TCP 19  UDP 2   _?
192.168.8.11    connection count:TCP 8   UDP 1   _?
192.168.9.13    connection count:TCP 0   UDP 0   _?
192.168.12.71   connection count:TCP 3   UDP 2   _rx78gp03s-PC
192.168.9.23    connection count:TCP 0   UDP 0   _?
192.168.12.36   connection count:TCP 3   UDP 1   _O_zhanglaoshi
192.168.8.53    connection count:TCP 5   UDP 0   _?
192.168.8.45    connection count:TCP 86  UDP 5   _?
192.168.8.46    connection count:TCP 18  UDP 5   _?
192.168.8.55    connection count:TCP 5   UDP 3   _?
192.168.8.43    connection count:TCP 91  UDP 3   _?
192.168.12.40   connection count:TCP 0   UDP 0   _
192.168.8.12    connection count:TCP 6   UDP 2   _?
192.168.12.205  connection count:TCP 1   UDP 0   _D_T
192.168.8.23    connection count:TCP 26  UDP 4   _?
192.168.9.11    connection count:TCP 0   UDP 0   _
192.168.12.207  connection count:TCP 0   UDP 0   _D_note
192.168.8.36    connection count:TCP 25  UDP 11  _?
192.168.8.56    connection count:TCP 12  UDP 3   _?
192.168.8.32    connection count:TCP 6   UDP 3   _?
192.168.8.41    connection count:TCP 92  UDP 10  _?
192.168.8.16    connection count:TCP 14  UDP 6   _?
192.168.8.21    connection count:TCP 8   UDP 2   _?
192.168.8.52    connection count:TCP 5   UDP 0   _?
192.168.8.26    connection count:TCP 10  UDP 2   _?
192.168.8.13    connection count:TCP 5   UDP 2   _?
192.168.8.51    connection count:TCP 7   UDP 0   _?
192.168.8.31    connection count:TCP 114 UDP 4   _?
192.168.9.12    connection count:TCP 0   UDP 0   _?
192.168.8.22    connection count:TCP 10  UDP 5   _?
192.168.12.206  connection count:TCP 7   UDP 4   _only
192.168.8.25    connection count:TCP 0   UDP 22  _?
192.168.8.100   connection count:TCP 5   UDP 3   _?
192.168.8.15    connection count:TCP 3   UDP 3   _?
192.168.12.75   connection count:TCP 1   UDP 11  _only-e7727fbd44
192.168.12.66   connection count:TCP 0   UDP 0   _Fox
192.168.12.70   connection count:TCP 1   UDP 0   _Android_866153000415588
ALL_Active_Clients_Count: 39

root@onlyit:/tmp#

haosh***

速龙电脑 发表于 2012-9-2 14:02
正解，说得很不错，有些小白连用都没用过几个路由，就在这啊之啊嘬（洛里啰嗦），我的8M光纤带20台都被 ...

说别人小白看来你是小白中的小白，人家黑网吧上网的人主要做些什么你知道么，你不懂今天我告诉你去黑网吧的清一色玩网络游戏，去正规网吧的9成以上玩网游的，网络游戏对网络延时才比较敏感，对带宽不是很敏感，在黑网吧只要一个使用迅雷或QQ视频或其他比较占带宽的软件整个网吧玩网游的都卡。
   还有我告诉你只要你的电脑够好网络质量够好2M10台机垃圾路由不限速没有智能带宽控制在都只玩网游的情况下毫无压力，你500多的NR285P弱爆了

da***

本来争论的问题是8m的路由能不能带20台pc同时流畅播放。这个我估计数据有点悬，但是正因为有突发的过程有缓冲的过程所以可能还能勉强实现。

至于你说的网络游戏和网游难道指的是lan游戏和网游。流量和延迟来保证游戏流畅的问题早就证明是个非常简单的问题。

至于你说的2m带10台电脑的问题，你有个很大的假设网络很好。很显然网络流畅跟电脑性能没多大关系。qos本身就是来解决把平时排队买饭时变成工行的vip用户可以优先办理业务。

haosh***

dato 发表于 2012-9-3 07:32
本来争论的问题是8m的路由能不能带20台pc同时流畅播放。这个我估计数据有点悬，但是正因为有突发的过程有缓 ...

网络流畅跟电脑性能没多大关系绝对没错，但能不能流畅运行网游就有绝对的关系，要不然几千快钱的CPU和显卡不就成摆设；或者说拿台PII或PIII的电脑和I3 I5的电脑上网效果一样？这绝对不可能的呀。对网络带宽而言却要求不高但网络延时一定要低，要不然管你1000M对等的光纤也好延时一高游戏就会卡就算一台机独享也罢。至于流量网络游戏的数据流量都很小不信你自己去监测一下至于网页游戏我就不知因为我不玩的，至于你说的本来争论的问题是8m的路由能不能带20台pc同时流畅播放。这个我估计数据有点悬，但是正因为有突发的过程有缓冲的过程所以可能还能勉强实现。
难道世人所说的能够流畅看电影是看几分钟停一会缓冲后看几分钟又停一会这样循环下去这叫做流畅观看？

弹性带宽控制本质就是小包优先嘛只不过是比较智能。