通过 HTB 共享带宽并优先考虑实时流量，哪种场景效果更好？

Question

我想为我们的互联网线路添加某种流量管理。看了很多文档后，我觉得HFSC对我来说太复杂了（我不了解所有曲线的东西，恐怕我永远不会弄对），不推荐CBQ，基本上HTB是方法去大多数人。

我们的内部网络有三个“网段”，我想在这些网段之间或多或少平均地共享带宽（至少在开始时）。此外，我必须根据至少三种流量（实时流量、标准流量和批量流量）对流量进行优先级排序。带宽共享并不像实时流量应始终被视为优质流量这一事实重要，但当然也没有其他流量类别可能会饿死。

问题是，什么更有意义并且还能保证更好的实时吞吐量：

1. 每个段创建一个类，每个类都具有相同的速率（根据 HTB 开发人员的说法，对于没有叶子的类，优先级无关紧要）并且这些类中的每一个都有三个子类（叶子），用于 3 个优先级（具有不同的优先级）和不同的费率）。

2. 每个优先级有一个类，每个类都有不同的速率（同样优先级无关紧要），每个有 3 个子类，每个段一个，而实时类中的所有 3 个都具有最高的优先级，批量中的最低优先级类，等等。

我将尝试使用以下 ASCII 艺术图像更清楚地说明这一点：

Case 1:

root --+--> Segment A
       |       +--> High Prio
       |       +--> Normal Prio
       |       +--> Low Prio
       |
       +--> Segment B
       |       +--> High Prio
       |       +--> Normal Prio
       |       +--> Low Prio
       |
       +--> Segment C
               +--> High Prio
               +--> Normal Prio
               +--> Low Prio

Case 2:

root --+--> High Prio
       |        +--> Segment A
       |        +--> Segment B
       |        +--> Segment C
       |
       +--> Normal Prio
       |        +--> Segment A
       |        +--> Segment B
       |        +--> Segment C
       |
       +--> Low Prio
                +--> Segment A
                +--> Segment B
                +--> Segment C

案例 1 似乎是大多数人会这样做的方式，但除非我没有正确阅读 HTB 实现细节，案例 2 可能会提供更好的优先级。

HTB 手册说，如果一个类达到了它的速率，它可能会从它的父类借用，并且在借用时，具有更高优先级的类总是首先获得带宽。但是，它还表示，无论优先级如何，在较低树级别上具有可用带宽的类始终优先于较高树级别上的类。

让我们假设以下情况：Segment C 没有发送任何流量。段 A 仅以最快的速度发送实时流量（足以使单独的链接饱和），而段 B 仅以最快的速度发送批量流量（同样，足以单独使完整的链接饱和）。会发生什么？

情况1：
Segment A->High Prio 和 Segment B->Low Prio 都有数据包要发送，因为 A->High Prio 具有更高的优先级，它总是首先被调度，直到达到它的速率。现在它试图从 Segment A 借用，但由于 Segment A 处于更高级别并且 Segment B->Low Prio 尚未达到其速率，因此现在首先提供该类，直到它也达到速率并想要从B 段。一旦两者都达到了它们的速率，两者再次处于同一水平，现在 A-> 高优先级将再次获胜，直到它达到 A 段的速率。现在它尝试从根（已经大量的流量空闲，因为段 C 没有使用任何保证的流量），但同样，它必须等待段 B->低优先级也达到根级别。一旦发生这种情况，

案例2：
High Prio->Segment A 和 Low Prio->Segment B 都有数据包要发送，同样 High Prio->Segment A 将获胜，因为它具有更高的优先级。一旦达到其速率，它会尝试从具有空闲带宽的 High Prio 借用，但处于更高级别，它必须等待 Low Prio-> Segment B 再次达到其速率。一旦两者都达到了他们的利率并且都不得不借钱，High Prio->Segment A 将再次获胜，直到达到 High Prio 级别的利率。一旦发生这种情况，它会尝试从 root 借用，这再次有足够的带宽剩余（此时 Normal Prio 的所有带宽都未使用），但它必须再次等待，直到 Low Prio->Segment B 达到低优先级，也试图从根借用。最后两个类都尝试从 root 借用，优先考虑优先级，并且 High Prio->

这两种情况似乎都不理想，因为无论哪种方式实时流量有时都必须等待批量流量，即使有足够的带宽可以借用。但是，在情况 2 中，实时流量似乎必须比情况 1 中等待的时间少，因为它只需要等到达到批量流量速率，这很可能小于整个段的速率（并且以防万一1 这是它必须等待的速率）。还是我在这里完全错了？

我想过更简单的设置，使用优先级 qdisc。但是优先队列有一个大问题，如果它们不受某种限制，它们会导致饥饿。饥饿是不可接受的。当然，可以将 TBF（令牌桶过滤器）放入每个优先级以限制速率，从而避免饥饿，但是当这样做时，单个优先级不能再单独使链路饱和，即使所有其他优先级也是如此是空的，TBF 将阻止这种情况发生。这也是次优的，因为如果目前没有其他类需要任何一个类，为什么不能获得 100% 的线路带宽？

有关此设置的任何评论或想法？使用标准的 tc qdiscs 似乎很难做到。作为一名程序员，如果我可以简单地编写自己的调度程序（这是不允许的），那将是一项非常简单的任务。

Answer 1

如果我正确理解htb，那么利率是“有保证的”。这意味着您对“实时”流量的速率有所了解。只有超过这个利率，它才会借钱。如果有几个班级想要借钱，pri​​o应该启动。保证利率应该加上物理限额。不然就太麻烦了。

恕我直言，情况 A 永远不会真正起作用，因为您需要在根级别进行优先级或速率限制。不同段中的优先级/费率彼此不了解，并且将被同等处理。

您可能想要的是：将低优先级和正常优先级的“速率”设置为 0 或接近它，并为其余带宽添加“上限”，对于高优先级，您保证 100% 的物理速率。