使用 SFQ（随机公平排队）时 TCP 流与 UDP 共存

Question

我正在模拟一个网络，使用 TC（流量控制）限制和修改所有接口。我的接口形式为 HTB --- SFQ（这有点复杂，但我会简化它）。

接口速度限制为 10mbps。假设我以 7mbps 的速度从 A 向 B 发送 UDP 流。之后，我从同一主机 (A) 向 B 发送一个 TCP 流。由于我在输出接口处有一个 SFQ 并且有两个流，因此调度程序每个流发送 5mbps。因此，刚开始时，UDP 流将损失 2mbps 的带宽。

当然，这是您对公平队列的期望，您希望它从它发送的每个流中发送相当数量的数据包。然而，我预计在一些 ACK 超时后，UDP 流需要 7mpbs，TCP 需要 3mpbs。但是，我从未见过超时。如果我删除 SFQ 队列，一切都会如我所料，TCP 流量达到 3mpbs，UDP 流量达到 7mbps。

这正常吗？这是我应该期待的吗？如果这是我应该预期的正常行为，则意味着对于任何给定路径，如果存在较大的 TCP 流量，如果您不想造成损失，则只能将 50% 用于 UDP 流量。

有没有办法保持 SFQ 队列？

Answer 1

这是预料之中的。 SFQ 强制执行 TCP/TCP 友好协议仅在争夺有限带宽时近似的公平性。如果某些流量应该超过其公平份额，您需要对其进行分类并绕过竞争的 SFQ 实例。这就是 HTB 的用途（而不是无类别的 TBF）。

这是一个常见的策略。那里有一些可行的例子，只是当我需要它们时我从来没有拿到它们。通常，较高优先级类别的带宽将受到限制，以避免完全地让其他交通挨饿。

https://wiki.archlinux.org/index.php/Advanced_traffic_control#Hierarchical_Token_Bucket_.28HTB.29

http://lartc.org/howto/lartc.qdisc.filters.html

请记住，某些 UDP 流量被设计为 TCP 友好的，例如奎克。如果您确实过滤 UDP 流量，那么从 Chrome nightlies 进行的下载可能会导致高优先级带宽饱和。从公平的角度来看，这是没有意义的。

此外，您几乎肯定想用 FQ_CODEL 替换 SFQ。测试负载引起的延迟，例如http://dslreports.com/speedtest，或者只是ping在您的一项饱和测试期间。 （有一个有趣的警告。使用 uTP 的“后台”流量的工作原理是将引起的延迟保持在 100 毫秒以下。使用 CODEL 或类似的钳位延迟低于此值，uTP 流实际上成为前台流量，并与 TCP 争夺相同的带宽份额）。