![使用 SFQ(随机公平排队)时 TCP 流与 UDP 共存](https://linux22.com/image/92799/%E4%BD%BF%E7%94%A8%20SFQ%EF%BC%88%E9%9A%8F%E6%9C%BA%E5%85%AC%E5%B9%B3%E6%8E%92%E9%98%9F%EF%BC%89%E6%97%B6%20TCP%20%E6%B5%81%E4%B8%8E%20UDP%20%E5%85%B1%E5%AD%98.png)
我正在模拟一个网络,使用 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 队列?
答案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 争夺相同的带宽份额)。