谈一下如何利用iptables限制速度（不用tc）

platinum

不精确能理解
不划算呢？

wwy

原帖由 "platinum" 发表：

为什么这么说呢？难道limit比tc耗费资源吗？

tc 的性能会不如limit ？

windowsnt

不错，有些情况下需要限制包的数量

goodcat1

还是用交换机限制端口流量来的方便可靠

q1208c

呵呵, 这样的做法可能会有问题的.

tc 用的是 kernel 的东东, 也就是说, 如果发进来的包多了, 它会告诉发送方, 它收不了这么多, 那发送方就会慢下来, 或是包小些的.

而 iptables 不一样, 它可能是只是简单的丢了多的包, 当然, 因为 应用层会处理包收不到的情况, 这些包会重传, 但这性能的代价可是不小.  udp 要 20s 断掉,  tcp 可能更长, 也许有 上千 s 的. 这样的等待, 我想没几个人愿意吧?

iptables 的 limit 可能更主要的作用是用来防止 DoS 吧.
而 tc 用来限制流量可能更合适.

fushuyong

其实 你这个方法是可行的， 可以先在自己的网络环境中计算一下平均的包大小，然后再limit。 我觉得这个比TC强。

platinum

原帖由 "q1208c" 发表：
呵呵, 这样的做法可能会有问题的.

tc 用的是 kernel 的东东, 也就是说, 如果发进来的包多了, 它会告诉发送方, 它收不了这么多, 那发送方就会慢下来, 或是包小些的.

netfilter难道不是kernel的东东吗？

而 iptables 不一样, 它可能是只是简单的丢了多的包, 当然, 因为 应用层会处理包收不到的情况, 这些包会重传, 但这性能的代价可是不小.  udp 要 20s 断掉,  tcp 可能更长, 也许有 上千 s 的. 这样的等待, 我想没几个人愿意吧?

限速后tc的实现结果和limit是一样的，都是丢一些包，有什么区别吗？

iptables 的 limit 可能更主要的作用是用来防止 DoS 吧.
而 tc 用来限制流量可能更合适.

DoS是拒绝服务攻击，不是limit能防御的，不是iptables能实现的，需要编写C代码滴～～
你想，假如--limit 100/s，DoS的量把100/s都占满了，你怎么防御？顶多是保证服务器不会CPU负载过高而死掉罢了

q1208c

原帖由 "platinum" 发表：

DoS是拒绝服务攻击，不是limit能防御的，不是iptables能实现的，需要编写C代码滴～～
你想，假如--limit 100/s，DoS的量把100/s都占满了，你怎么防御？顶多是保证服务器不会CPU负载过高而死掉罢了

呵呵, tc 在丢包的同时, 会告诉发送方, 让它慢一点发, netfilter 就不会了. 因为它本来就只管 reject /drop 的.

虽然 netfiler / tc 都是 kernel 的东东, 但如果他们的功能重复了, 那开发者不是猪头? 干嘛放两个同样功能的东东在里面呢?

关于 DoS , 没有任何一种办法是一定没问题的. 都只能在一定程度上解决.

limit 100/s 只是用在特定有 service 上的. 因为不太可能有全部端口的 DoS, 所以, 可能有一个Service 满了, 比如 http 的到了 100/s 了(被攻击), 但 ftp 的 100/s 可能还可用. 而最重要的是 server 不会有问题.

colddawn

这样限制真得非常不准确！
1，楼主有提到“不是所有的包都是mtu所规定的大小”，事实是非常多的包的大小与这个差别很大！简单点的举个例子，tcp连接发起需要三次握手，这三次的包都是只有包头没有内容，也就是48字节大。假设你限制了10个每秒，那我发起5个http请求，每个要3次握手，也就是说要发2个包收一个包，架设你是限制发出，那这刚好就能达到你得limit上限，而这个时候多余的包就drop了，而我们的数据流根本还没开始那。算一下流量为48*10=480字节，与你预期的1500*10差了不是1个数量级别。再加上病毒肆虐的icmp,udp包，用这个limit限制就根本谈不上精确，连准确都达不到了。
2，limit模块限制也不是简单得满了限额就drop，而是有一个round robin算法，对某些突发包有附加惩罚，而对某些刚好界定在limit界限的包数量有包容，这也造成了流量限制基本不准，具体google一下iptabales+limit有不少文章都提及了，虽然都没说得很详细。

所以楼主的思路只能说是有讨论余地，而无实用价值了，老老实实用tc吧，hoho

platinum

原帖由 "q1208c" 发表：

tc 用的是 kernel 的东东, 也就是说, 如果发进来的包多了, 它会告诉发送方, 它收不了这么多, 那发送方就会慢下来, 或是包小些的.

这要看tc是否有发送ICMP type 4的机制，但是不知道tc到底有没有这样的机制
如果有，这样可省掉许多re-transmition
若没ICMP，TCP 会在 ack time-out 后在重送，实际和limit的功能是一样的，而不是你所说的“如果发进来的包多了, 它会告诉发送方, 它收不了这么多, 那发送方就会慢下来”