13

在我的工作中，我发现 tc 可以做出口整形，并且只能做入口监管。我想知道为什么 tc 不实现入口整形？

代码示例：

#ingress
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 \
   u32 match ip src 0.0.0.0/0 police rate 256kbit \
   burst 10k drop flowid :1
#egress
tc qdisc add dev eth0 root tbf \
   rate 256kbit latency 25ms burst 10k

但我不能这样做：

#ingress shaping, using tbf
tc qdisc add dev eth0 ingress tbf \
   rate 256kbit latency 25ms burst 10k

我发现一个名为 IFB（更新的 IMQ）的解决方案可以将流量重定向到出口。但这似乎不是一个好的解决方案，因为它正在浪费 CPU。所以我不想用这个。

入口整形有意义吗？为什么 tc 不支持它？

4

2 回答 2

13

虽然入口的 tc 整形规则非常有限，但您可以创建一个虚拟接口并对其应用出口规则，如下所述：

https://serverfault.com/questions/350023/tc-ingress-policing-and-ifb-mirroring

（如果您的虚拟机已经使用虚拟接口，您可能不需要虚拟接口，您可以将 tc 应用于它们。）

入口整形的警告是，由于流源和接口之间的路由器中的所有缓冲区，传入流可能需要很长时间才能响应您的整形操作。并且在流确实响应降低的限制之前，它将继续淹没您的下游！同时，您将丢弃好的数据包，从而降低吞吐量。

同样，当高优先级流结束或下降时，低优先级流需要一段时间才能恢复到其全速。如果它经常发生，这可能会非常具有破坏性！

这样做的结果是，动态整形可能对稳定速率的长寿命流组按需要工作，但当下游被淹没时，对短寿命或变化速率的高优先级流几乎没有优势：低优先级流将只是需要太长时间才能退缩。但是，将低优先级和中优先级数据包分类并限制在低于最大降速率的某个静态速率可能会有所帮助，以保证至少有一些空间用于高优先级数据。

我没有这方面的任何数据，并且自 ADSL 时代以来延迟已经改善了很多。所以我认为它可能值得测试，如果您希望高优先级数据包的低延迟或高吞吐量比整体吞吐量更重要，并且您可以忍受上述限制。

正如 Janoszen 和 ADSL HOWTO 所提到的，如果我们可以调整 TCP 窗口大小作为整形的一部分，流可以更快地响应。

搜索 TLDP以进行进一步研究。

于 2013-06-06T01:12:13.353 回答
4

整形作用于发送缓冲区。入口整形需要控制远程发送缓冲区。

于 2013-05-10T22:55:29.813 回答