发现限速了之后，客户端的确慢下来了，MRTG 看到的还很高，为什么？
你们好，我是一个 Linux 网管，我们原先用的是 l7-filter 做的 P2P 阻断和限速，发现识别能力太差，经过朋友推荐现在在使用 Panabit，在使用过程中，我们发现一个奇怪的问题比如，用迅雷下载的时候（可能同时用到了 HTTP、BT、和迅雷自己的协议），对这个 IP 限制了速度，之后发现他下载的确慢了，数值与设置的相当，但是从网管软件上看，以及从 Linux 网关上的 MRTG 图上看，进来的流量还是很大，这是为什么？ 原帖由 netmaster 于 2007-8-28 21:46 发表 http://www.panabit.com/forum/images/common/back.gif
你们好，我是一个 Linux 网管，我们原先用的是 l7-filter 做的 P2P 阻断和限速，发现识别能力太差，经过朋友推荐现在在使用 Panabit，在使用过程中，我们发现一个奇怪的问题
比如，用迅雷下载的时候（可能同 ...
MRTG如果我没有记错的话，是5分钟更新一次结果。
你能否将你的拓扑结构详细描述一下，另外MRTG看到的是谁的流量？
我的网络是这样的
ISP
|(PPPoE)
Linux
/ \(eth2)
(eth1)| panabit
DMZ |
LAN
测试的时候，我的网络里面目前只有 LAN 下面有一台电脑，只使用迅雷下载
我对他限制 1Mbps，也就是里面设置的 1024kbit/s，换成 byte 就应该是 128kB/s
我的迅雷确实慢下来了，速度确实只有 116kB/s 左右（我想，不到 128 的原因是由于迅雷协议显示的速率是纯 payload 的，而 panabit 是对整个 L3 限制的吧）
但实际上我在 Linux 网关上看到的外网数据进来到 ppp0（ADSL 设备）的流量远大于 128kB/s
root@NAT ~ # sar -n DEV -u 4 9999
Linux 2.4.34.1 (NAT) 08/28/2007
11:14:12 PM CPU %user %nice %system %iowait %idle
11:14:16 PM all 4.25 0.00 8.25 0.00 87.50
11:14:12 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/srxmcst/s
11:14:16 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:14:16 PM eth0 237.50 224.00 167990.0023480.00 0.00 0.00 0.00
11:14:16 PM eth1 0.00 0.50 0.00 30.00 0.00 0.00 0.00
11:14:16 PM eth2 222.50 235.7521609.00 165768.00 0.00 0.00 0.00
11:14:16 PM ppp0 237.75 224.00 162522.0018552.00 0.00 0.00 0.00
11:14:16 PM CPU %user %nice %system %iowait %idle
11:14:20 PM all 3.75 0.00 9.00 0.00 87.25
11:14:16 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/srxmcst/s
11:14:20 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:14:20 PM eth0 227.00 193.25 164908.0022101.75 0.00 0.00 0.00
11:14:20 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:14:20 PM eth2 191.50 224.5020465.00 162601.50 0.00 0.00 0.00
11:14:20 PM ppp0 227.00 193.50 159364.0017864.00 0.00 0.00 0.00
11:14:20 PM CPU %user %nice %system %iowait %idle
11:14:24 PM all 4.25 0.00 9.25 0.00 86.50
11:14:20 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/srxmcst/s
11:14:24 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:14:24 PM eth0 223.25 209.75 152416.2523347.00 0.00 0.00 0.00
11:14:24 PM eth1 0.00 0.75 0.00 45.00 0.00 0.00 0.00
11:14:24 PM eth2 209.00 221.7521627.25 150169.75 0.00 0.00 0.00
11:14:24 PM ppp0 222.00 209.25 146859.2518709.25 0.00 0.00 0.00
11:14:24 PM CPU %user %nice %system %iowait %idle
11:14:28 PM all 1.00 0.00 11.25 0.00 87.75
11:14:24 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/srxmcst/s
11:14:28 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:14:28 PM eth0 236.00 202.75 161811.5021699.75 0.00 0.00 0.00
11:14:28 PM eth1 0.00 0.25 0.00 15.00 0.00 0.00 0.00
11:14:28 PM eth2 202.00 234.2520050.75 159343.50 0.00 0.00 0.00
11:14:28 PM ppp0 236.50 203.50 155961.5017280.75 0.00 0.00 0.00
root@NAT ~ #
而我在开着迅雷的 client 上用 wireshark 抓包发现，TCP 协议有大量重传信息
那么我想，虽然 panabit 限制住了流经他到 client 的流量，但外网因为数据被限速带来的大量 TCP 重传对外网网口冲击造成的大量无用数据怎么处理呢？这样也一样造成了大量的带宽浪费啊？ 另外，发现如果从 client 从外网收 MAIL 就没有问题，进入到 ppp0 设备的流量是 129kB/s 左右，最大到过 131kB/s
我想，是不是和迅雷多线程有关？因为毕竟 FoxMail 用 POP3 协议收信时只是单线程作业，而 P2P 软件则不是
由于限速后，很多 TCP 数据无法到达 client，线程越多，TCP 连接数越多，TCP 重传量就越大，浪费带宽就越多？
[ 本帖最后由 netmaster 于 2007-8-28 23:35 编辑 ] 原帖由 netmaster 于 2007-8-28 23:25 发表 http://www.panabit.com/forum/images/common/back.gif
我的网络是这样的
测试的时候，我的网络里面目前只有 LAN 下面有一台电脑，只使用迅雷下载
我对他限制 1Mbps，也就是里面设置的 1024kbit/s，换成 byte 就应该是 128kB/s
我的迅雷确实慢下来了，速度确实 ...
你的分析很有道理。这个由于重传带来的开销很难避免。
有一种方法是使用red，但是这要求有一个queue，会导致延迟。
很多时候都必须有所取舍。
TCP重传同很多因素有关系，同样的设置，在你的环境是这样的情况，在其他环境里可能是另外一种情况。 queue 也是队列，队列总有个 buffer，当 buffer 不满的情况下可以做流量整形，但 buffer 满了必然会丢弃，丢弃就会重传
所以我认为你说的 red 也不能解决这个问题 原帖由 netmaster 于 2007-8-28 23:41 发表 http://www.panabit.com/forum/images/common/back.gif
queue 也是队列，队列总有个 buffer，当 buffer 不满的情况下可以做流量整形，但 buffer 满了必然会丢弃，丢弃就会重传
所以我认为你说的 red 也不能解决这个问题
我们一般的丢弃都是tail drop，但是RED的丢弃不是这样的，它有可能是丢弃已经在Queue中的某个数据包，这样对TCP而言是
有道理的。
开坛至今，你是第一个分析如此深的网友，希望你多对panabit提提意见，让panabit日益完善。 小巫见大巫了，你们的技术实力相当强大，已经做到了 2Gbps 线速，不知道这个是否是在 x86 构架上实现的？ 原帖由 netmaster 于 2007-8-28 23:46 发表 http://www.panabit.com/forum/images/common/back.gif
小巫见大巫了，你们的技术实力相当强大，已经做到了 2Gbps 线速，不知道这个是否是在 x86 构架上实现的？
是的。
以前大家都认为x86不行，那是由于其IO不行，并非是其处理能力不行。
PCIE的出现让x86看到了曙光，再加上AMD和Intel越来越关注功耗和多核的发展，因此，在不远的将来，X86会在嵌入式领域走
得越来越远。 我觉得你们应该做硬件产品，包装起来卖，而不是做纯软件的，这样会有更高的利润空间，比如你们的专业版
页:
[1]
2