☰

不。

tag-icon • tag-icon linux traffic-shaping iproute2
不。

我想限制 Linux 的传入（下载）速度。

配置好的盒子和流量源（HTTP服务器）都连接到同一个交换机，如果不配置shaping，下载速度为30MBps

我按照http://lartc.org/lartc.html

########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent 
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:

/sbin/tc qdisc add dev $DEV handle ffff: ingress

# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:

/sbin/tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

但是实际下载速度比配置的要慢很多。以下是我的实验结果

设定速率，KBps：实际速率，KBps

  • 32 KBps：30 KBps
  • 64 KBps：50 KBps
  • 128 KBps：106 KBps
  • 256 KBps：160 KBps
  • 512 KBps：210 KBps
  • 1024 KBps：255 KBps

对于小带宽，整形工作相当好，但在 1024 KBit 上，有效比特率比预期低 75％。

是否可以有效限制传入带宽？

答案1

体重低于预期

burst我认为你也必须相应地增加。

是否可以有效限制传入带宽？

我认为你肯定可以通过丢弃数据包而不是接收数据包来实现类似的效果。对于具有带宽自调节机制的 TCP 等协议，这种方法可以有效发挥作用。请查看http://www.linuximq.net/faq.html

答案2

是否可以有效限制传入带宽？

不。

尝试限制传入带宽基本上就是尝试通过举起一块钻孔的木板来限制消防水带的流量：虽然您会减少打到您的水量，但您仍然会被消防水带击中。

进一步使用消防水带的类比，如果您需要 100 加仑的水，但限制了水流到您手中的速度（通过举起有洞的木板），您仍然会承受消防水带的大部分力量（顺着管道流下来的水流），但不会得到大部分的水（因为只有穿过洞的水才能到达您手中 —— 其余的水都会被防火墙板滴到地上）。

阻断所有水的结果是，需要更长的时间才能装满 100 加仑的水桶。
使用防火墙阻断 TCP 数据包的效果更差一些，因为您会触发远程主机的拥塞控制算法在理想情况下，这会降低消防水带上的压力，有时会比你希望的要低得多。

顺便说一句，这也是为什么本地防火墙无法保护您免受 DoS 攻击的原因——您仍然必须处理所有流量，即使只是决定忽略它。出于显而易见的原因，DoS 攻击不太可能遵守拥塞控制程序。

答案3

我听说过限制传入带宽的混合结果，但使用内核中的 ifb 设备应该可以实现这一点。而一个事实是 @voretaq7 所说的，如果您接受所有输入数据包并使用重定向或镜像将它们重定向到其中一个“中间功能块锁”设备，则可以“限制”传入数据包。对于这些，您可以附加任何通常仅限于“出口”过滤的过滤器。

这听起来可能不是“有帮助”，因为您必须接受所有流量进入 ifb - 但随后您必须决定哪些流量从该保持队列“进入”到系统的其余部分。

这样做的好处是不会丢弃数据包，除非它们是优先级较低的数据包。当然，如果您遭到 DoS 攻击，关键问题可能是入站流量总量高于您的线路所能承受的流量，因此尝试使用此方法影响它是徒劳的。此方法仅适用于合法的流任何所需协议（TCP、UDP、ICMP 等）。例如，如果我想优先处理 DNS 而不是批量下载，我可以这样做，但是，无论您使用哪种流量算法，如果您有 30Mb/，那么使用 1000Hz 的最快正常时钟中断，您仍然必须处理 30Kb 的流量/时钟滴答，并且假设您及时被调用。这就是您必须具有高突发速率的主要原因，因为仅使用速率限制很难处理这么多。

这将是有帮助的如果您的网卡有多个 I/O 队列。许多网卡有 6-12 个队列/方向，可以根据以太网卡上通常更有限的过滤选项提供一些“自动”分类到单独队列的功能。

更有帮助的是——如果您可以将流量分配到这些多个队列中，那么您可以为队列设置处理器亲和性。如果您发现自己在 CPU 处理数据包方面受到限制，那么使用多队列可以帮助将传入流量分散到不同的核心进行处理（不要使用超线程——这可能会导致性能问题，因为线程不是在共享数据上运行，而是在单独的数据流上运行。使用单独的 L1 和 L2 缓存处理这些问题将是最好的（L3 仍然会在多个核心之间共享），但您至少可以将 L1 和 L2 缓存专用于它们自己的“流”）。

由于单队列和策略带来的吞吐量问题，我放弃了入口控制——当时我只有 5Mb 的传入流量（现在是 7Mb），所以我还没有尝试看看使用 multiq 和 ifb 在入口整形方面有多有效。事实上，我通常使用应用程序级整形和控制——虽然不理想，但相当可靠。

时不时出现的一个问题是，由于线路问题或 ISP 拥塞，我无法获得最大带宽，然后我的固定过滤器预设也无法适应……这是我没有花太多功夫解决这个问题的另一个原因，因为我不确定需要做多少工作才能使速率限制动态并感知到此类问题，而且现在我的队列中有太多其他更高优先级的项目……（并且我的 I/O 速率远低于我的以太网端口）…… ;-)

相关内容