300人同时在线的无线网络，需要多大带宽

QOS这个东西从现实操作中对于上行小的用户是个很难优化的问题。偶在公司22mbps下行67mbps上行，用一个RTN16刷的tomato可以带的了150人，tc的prio优先级，sfq特性,ack,syn ,fin,rst,小包优先出列都能在网络极端拥塞的情况下每用户仍然有一定的带宽，至少网页浏览还是顺畅的。后来不管了退回原先的设备tplink的ER5120，HOHO真的没办法带，这种基于ip的限速有很多问题，首先这个数量级的平均每用户保障带宽就降到20kb/s，在这个年代20kb的带宽能干嘛。所以我给每用户的下行是10kb-300kb。这个值是远远的超过现有网络。平时80用户在线还勉勉强强，150用户的时候网络根本没法用。你会发现那网页打开时半天还在转圈。就是因为IP级QOS采用FIFO队列导致的。30M的光纤，上行2M。这根线路的缺点在上行，虽然偶搞了一套60/80 的htb树形队列理论，这个队列也在现实环境测试过。但是也仅能保障网页浏览的顺畅，无法再保证p2p程序像快播之类的下行发起。tcp协议的应答特性使得上行拥塞同样造成下行无法发起连接。结果是流量远远用不到30M100M的话，每用户基本带宽30KB，保障网页浏览，保障游戏用户（无线不大可能）没问题，如果另外的299人都不在用网络的话，1个人可以拿到100M带宽，可以再保障需要流量的视频之类的应用。300人采取收费吧。每个人收个10块钱，网络费用都回来了。而且能够这个规模的网络又想保障延迟情况的话。接触过的也只有ros了。dd tt之类的cpu带不起这么多用户，特别采取下行限速。ros除了小包没有tc的处理规则，但ack包还是能放行出去，而且像上行持续连接到一定流量自动降级的这样设定都有，除了小包，其它linux系统有的，它也能处理。ros的pcq是用来解决simple queue队列出现的亢长匹配。也可以根据一定的判断来实现自动对有问题用户进行限速，其它所有的用户不限速操作，这样带宽可以有效的利用。至于爱快之类的，我就不清楚它是否有ros这样的基于命令行方式的配置灵活性。 查看原帖>>

记得采纳啊