为什么tc不能做入口整形？入口整形是否有意义？

Question

在我的工作中，我发现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不支持它？

Answer 1

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

  

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

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

入口整形的警告是，由于流源和接口之间的路由器中的所有缓冲区，传入流可能需要很长时间才能响应您的整形操作。直到流确实响应减少的限制，它将continue to flood你的下游！与此同时，您将丢弃好的数据包，从而降低吞吐量。

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

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

我对此没有任何数据，自ADSL日以来，延迟有了很大改善。所以我认为值得测试，如果高优先级数据包的低延迟或高吞吐量是你想要的而不是整体吞吐量，你可以忍受上述限制。

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

Search TLDP进一步研究。

Answer 2

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