这是一个创建于 2714 天前的主题，其中的信息可能已经有所发展或是发生改变。
题主的宽带出口流量最高 24Mbps ，使用的 RB750 路由器。在路由器上面已经做了 Mangle 和 Queue ，当然他们现在都工作的很好。但是有一件事题主不太明白：
为什么 WAN 流量会大于 LAN 流量总和呢？这是正常的吗？
关于路由器的配置情况，目前关于 Queue 这一块大概是这样的：
- 在 Queue Type 中有定义 pcq-down 和 pcq-up 通过 dst 和 src address 来区分
- Mangle 中有通过数据类型和数据包大小两种方式标记，类型在前大小在后
- 然后在 Queue Tree 里面定义了 Download 和 Upload 采用的都是相对应的 PCQ 类型
- 确定所有数据包都被标记，也都被纳入了 Queue Tree 中
测试环境是迅雷和在线视频，在同一台 PC 上测试。 PC 满载测试时发现了一些问题：
- 开启 Queue ： PC 检测到 20Mbps 流量， LAN 20Mbps ， PPPoE 24Mbps ， Queue 20Mbps
- 关闭 Queue ： PC 检测到 24Mbps 流量， LAN 24Mbps ， PPPoE 24Mbps ， Queue --Mbps
- 在开启 Queue 用 Torch 功能统计时情况和上面一样
- 修改 Queue 速度限制到 10M ，发现 PPPoE 多出 LAN 总和 4Mbps
- 修改 Queue 速度限制到 1M ，发现 PPPoE 多出 LAN 总和 2Mbps
疑问 既然在开启 Queue 功能后 PC 都只检测到 20Mbps 的话， LAN 总和也只有 20Mbps ，为什么 WAN 会多出 LAN 的统计总和呢？是正常的现象吗？ =w=
 |
1
vibbow 2016-12-27 02:09:14 +08:00  1
首先 LZ 要搞清楚一个事实
真正完美限速是不存在的，因为对端双方都不知道对方期望的速率是什么。 如果一个数据包已经达到你路由器了，但是已经达到限速线了怎么办？ 这也就是 LZ 现在遇到的问题，虽然你路由器限制了到 LAN 的速率是 20Mb 但是对端并不知道你的限速是 20Mb ，还在以超过 20Mb 的速度给你传输数据。 |
|
2
vibbow 2016-12-27 02:14:26 +08:00
BTW ， RB 系列的 CPU 其实挺弱鸡的， Queue 和 Mangle 规则做太多的话对性能影响很大...
还是上 CCR 或者 x86 才是正道啊... |
 |
4
lan894734188 2016-12-27 04:54:45 +08:00 via Android
正常的 还有报文和 ack 通讯
|
 |
5
dfc643 OP @vibbow 感谢回答，原来如此。不过我在测试不限速的时候 ping 会出现丢包，限速虽然对端网络还是以 24Mb 传送，但是 ping 不会丢包，应该是 Queue 的功劳。
其实 RB 在小型家用或者办公网络里面还可以的啦，我这个情况基本上 CPU 68% 左右满载。 |
|
6
dfc643 OP @lan894734188 嗯，超出部分应该涵括了这一些。
|
|
8
lan894734188 2016-12-27 17:48:06 +08:00 via Android
@dfc643 还有限速应该做在数据流入方向
|
|
9
dfc643 OP @lan894734188 Mangle 的标记打在 Forward 的大概算流入方向吧 ^^;
|
|
10
dfc643 OP @vibbow 万年前的 RB750 r1 = = （ 300MHz 的那一款）
不过新版的 r2 r3 真不敢买，电路板太干净了。 |
|
12
dfc643 OP @vibbow 之前双十一差点就下单了，看了一下评测又取消订单了，貌似现在内网交换量有问题，还有系统貌似也有些 BUG 。主要这是 MKTK 第一款 MTK 芯片的不知道会不会弃坑。 orz ..
|
|
13
vibbow 2016-12-27 21:41:40 +08:00
@dfc643 买了一个 750 R3 的
内网交换速度没感觉有啥问题， switch 菜单的问题升级到 6.38 也解决了。不过感觉上 switch 功能相对于 atheros 芯片有一些精简，有一个 vlan 的功能至今没调出来... 主要是由硬件加密加速功能，连 vpn 速度嗖嗖的。不像 962 ，跑不到 20Mb 的速度 CPU 就满了... |
|
14
dfc643 OP @vibbow 之前看评测内网交换只能到 500Mb ，然后就取消了，想入一个千兆。再观望一段时间，看看 MKTK 会不会把 MTK 芯片弃坑。说实话我现在这 r1 真耐用用了好多年了。
|
|
15
lan894734188 2016-12-28 04:46:23 +08:00 via Android
@dfc643 我们做 target 的网段就行了不用标记
|
|
16
dfc643 OP @lan894734188 好的吧，不过这样的话区分流量类型会不会有点麻烦(´･ω･`)
|
|
17
lan894734188 2016-12-28 17:04:13 +08:00 via Android
@dfc643 用了 pcq 还需要区分流量类型么 ros 的流量类型区分不太好 没有人维护特征库 单靠端口是不够的 虽然有 L7 特征识别但是没有特征库 ros 单纯的作为路由 AC 是挺好的 流量特征识别还是交给 panabit
|
|
18
dfc643 OP @lan894734188 PCQ 只是平摊流量，做优先级还是需要区分的吧。
我这边只是简单地区分了 80 端口小包流量，视频音乐流量，然后其他的按数据包大小区分的。 这个 L7 数据库可以参考一下 http://l7-filter.sourceforge.net/protocols |
|
19
lan894734188 2016-12-28 23:26:57 +08:00 via Android
优先级可以做在 queue tree 下 标记全局的 dst src 就好啦 ros 的 L7 说实话还没在生产环境用过
|
|
20
dfc643 OP @lan894734188 原来如此。 L7 的话其实用还是挺好用的就是费 CPU 资源。比如标记特殊流量如在线视频很管用。
|
|
21
lan894734188 2016-12-29 15:29:40 +08:00 via Android
@dfc643 嗯流量分类还是 panabit 好用 透明桥串在链路上就好 还可做缓存牵引 log 审计
|
|
22
dfc643 OP @lan894734188 马克了谢谢，有空弄下来玩玩看。
|
Select Language