发现限速了之后，客户端的确慢下来了，MRTG 看到的还很高，为什么？

netmaster

你们好，我是一个 Linux 网管，我们原先用的是 l7-filter 做的 P2P 阻断和限速，发现识别能力太差，经过朋友推荐现在在使用 Panabit，在使用过程中，我们发现一个奇怪的问题

比如，用迅雷下载的时候（可能同时用到了 HTTP、BT、和迅雷自己的协议），对这个 IP 限制了速度，之后发现他下载的确慢了，数值与设置的相当，但是从网管软件上看，以及从 Linux 网关上的 MRTG 图上看，进来的流量还是很大，这是为什么？

panabit

原帖由 netmaster 于 2007-8-28 21:46 发表
你们好，我是一个 Linux 网管，我们原先用的是 l7-filter 做的 P2P 阻断和限速，发现识别能力太差，经过朋友推荐现在在使用 Panabit，在使用过程中，我们发现一个奇怪的问题

比如，用迅雷下载的时候（可能同 ...

MRTG如果我没有记错的话，是5分钟更新一次结果。
你能否将你的拓扑结构详细描述一下，另外MRTG看到的是谁的流量？

netmaster

我的网络是这样的

          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/s  rxmcst/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.00  23480.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.75  21609.00 165768.00      0.00      0.00      0.00
11:14:16 PM      ppp0    237.75    224.00 162522.00  18552.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/s  rxmcst/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.00  22101.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.50  20465.00 162601.50      0.00      0.00      0.00
11:14:20 PM      ppp0    227.00    193.50 159364.00  17864.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/s  rxmcst/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.25  23347.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.75  21627.25 150169.75      0.00      0.00      0.00
11:14:24 PM      ppp0    222.00    209.25 146859.25  18709.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/s  rxmcst/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.50  21699.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.25  20050.75 159343.50      0.00      0.00      0.00
11:14:28 PM      ppp0    236.50    203.50 155961.50  17280.75      0.00      0.00      0.00

root@NAT ~ #

而我在开着迅雷的 client 上用 wireshark 抓包发现，TCP 协议有大量重传信息
那么我想，虽然 panabit 限制住了流经他到 client 的流量，但外网因为数据被限速带来的大量 TCP 重传对外网网口冲击造成的大量无用数据怎么处理呢？这样也一样造成了大量的带宽浪费啊？

netmaster

另外，发现如果从 client 从外网收 MAIL 就没有问题，进入到 ppp0 设备的流量是 129kB/s 左右，最大到过 131kB/s
我想，是不是和迅雷多线程有关？因为毕竟 FoxMail 用 POP3 协议收信时只是单线程作业，而 P2P 软件则不是
由于限速后，很多 TCP 数据无法到达 client，线程越多，TCP 连接数越多，TCP 重传量就越大，浪费带宽就越多？

[ 本帖最后由 netmaster 于 2007-8-28 23:35 编辑 ]

panabit

原帖由 netmaster 于 2007-8-28 23:25 发表

我的网络是这样的

测试的时候，我的网络里面目前只有 LAN 下面有一台电脑，只使用迅雷下载
我对他限制 1Mbps，也就是里面设置的 1024kbit/s，换成 byte 就应该是 128kB/s
我的迅雷确实慢下来了，速度确实 ...

你的分析很有道理。这个由于重传带来的开销很难避免。
有一种方法是使用red，但是这要求有一个queue，会导致延迟。
很多时候都必须有所取舍。

TCP重传同很多因素有关系，同样的设置，在你的环境是这样的情况，在其他环境里可能是另外一种情况。

netmaster

queue 也是队列，队列总有个 buffer，当 buffer 不满的情况下可以做流量整形，但 buffer 满了必然会丢弃，丢弃就会重传
所以我认为你说的 red 也不能解决这个问题

panabit

原帖由 netmaster 于 2007-8-28 23:41 发表
queue 也是队列，队列总有个 buffer，当 buffer 不满的情况下可以做流量整形，但 buffer 满了必然会丢弃，丢弃就会重传
所以我认为你说的 red 也不能解决这个问题

我们一般的丢弃都是tail drop，但是RED的丢弃不是这样的，它有可能是丢弃已经在Queue中的某个数据包，这样对TCP而言是
有道理的。

开坛至今，你是第一个分析如此深的网友，希望你多对panabit提提意见，让panabit日益完善。

netmaster

小巫见大巫了，你们的技术实力相当强大，已经做到了 2Gbps 线速，不知道这个是否是在 x86 构架上实现的？

panabit

原帖由 netmaster 于 2007-8-28 23:46 发表
小巫见大巫了，你们的技术实力相当强大，已经做到了 2Gbps 线速，不知道这个是否是在 x86 构架上实现的？

是的。
以前大家都认为x86不行，那是由于其IO不行，并非是其处理能力不行。
PCIE的出现让x86看到了曙光，再加上AMD和Intel越来越关注功耗和多核的发展，因此，在不远的将来，X86会在嵌入式领域走
得越来越远。

netmaster

我觉得你们应该做硬件产品，包装起来卖，而不是做纯软件的，这样会有更高的利润空间，比如你们的专业版