使用 tc 进行流量整形不准确，带宽和延迟较高答案

【问题标题】：Traffic shaping with tc is inaccurate with high bandwidth and delay使用 tc 进行流量整形不准确，带宽和延迟较高
【发布时间】：2012-03-23 18:39:56
【问题描述】：

我正在使用带有内核 2.6.38.8 的 tc 进行流量整形。限制带宽有效，添加延迟有效，但是当使用延迟整形两个带宽时，如果限制>1.5 Mbps 左右，则达到的带宽总是远低于限制。

例子：

tc qdisc del dev usb0 root
tc qdisc add dev usb0 root handle 1: tbf rate 2Mbit burst 100kb latency 300ms
tc qdisc add dev usb0 parent 1:1 handle 10: netem limit 2000 delay 200ms

产生 201 毫秒的延迟（来自 ping），但容量仅为 1.66 Mbps（来自 iperf）。如果我消除延迟，带宽正好是 2 Mbps。如果我指定 1 Mbps 和 200 ms RTT 的带宽，一切正常。我也尝试过 ipfw + dummynet，得到了类似的结果。

我已经尝试在 Kconfig 中使用HZ=1000 重建内核——但这并没有解决问题。其他想法？

【问题讨论】：

标签： linux network-programming trafficshaping ipfw

【解决方案1】：

这实际上不是问题，它的行为与它应该的一样。因为您添加了 200 毫秒的延迟，所以完整的 2Mbps 管道并未发挥其全部潜力。我建议您更详细地研究 TCP/IP 协议，但这里是 iperf 发生情况的简短摘要：您的默认窗口大小可能是 3 个数据包（每个可能 1500 字节）。你用 3 个数据包填充你的管道，但现在必须等到你得到一个确认（这是拥塞控制机制的一部分）。由于您将发送延迟 200 毫秒，这将需要一段时间。现在您的窗口大小将增加一倍，接下来您可以发送 6 个数据包，但再次需要等待 200 毫秒。然后窗口大小再次翻倍，但当您的窗口完全打开时，默认的 10 秒 iperf 测试已接近结束，您的平均带宽显然会更小。

【讨论】：

【解决方案2】：

这样想：

假设您将延迟设置为 1 小时，将速度设置为 2 Mbit/s。

2 Mbit/s 需要（例如）50 Kbit/s 的 TCP ACK。因为 ACK 需要一个多小时才能到达源，所以源不能继续以 2 Mbit/s 的速度发送，因为 TCP 窗口仍然在等待第一次确认。

延迟和带宽比你想象的更相关（至少在 TCP 中。UDP 是另一回事）

【讨论】：