linux – 通过HTB共享带宽和优先处理实时流量,哪种方案更好？

概述我想在我们的互联网线路上添加一些流量管理.在阅读了大量文档之后,我认为HFSC对我来说太复杂了(我不了解所有曲线的东西,我担心我永远不会把它弄好),CBQ不推荐,基本上HTB就是通往适合大多数人. 我们的内部网络有三个“段”,我想在这些段之间或多或少地分享带宽(至少在开始时).此外,我必须根据至少三种流量(实时流量,标准流量和批量流量)确定流量的优先级.带宽共享并不像实际流量应尽可能始终被视为高级 我想在我们的互联网线路上添加一些流量管理.在阅读了大量文档之后,我认为HFSC对我来说太复杂了(我不了解所有曲线的东西,我担心我永远不会把它弄好),CBQ不推荐,基本上HTB就是通往适合大多数人.

我们的内部网络有三个“段”,我想在这些段之间或多或少地分享带宽(至少在开始时).此外,我必须根据至少三种流量(实时流量,标准流量和批量流量)确定流量的优先级.带宽共享并不像实际流量应尽可能始终被视为高级流量那样重要,但当然也没有其他流量类别可能会饿死.

问题是,什么更有意义,也保证更好的实时吞吐量：

>每个段创建一个类,每个具有相同的速率(根据HTB开发人员,优先级对于没有叶子的类没有关系),并且这些类中的每一个都有3个子类(叶子)用于3个优先级(具有不同的优先事项和不同的费率).
>每个优先级有一个类,每个具有不同的速率(再次优先级无关紧要),每个具有3个子类,每个段一个,而实时类中的所有3个具有最高的prio,最低的prio批量类,等等.

我将尝试使用以下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 PrioCase 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手册说,如果一个类已经达到它的速率,它可以从其父级借用,并且在借用时,具有更高优先级的类总是首先获得带宽.但是,它还说,无论优先级如何,在较低树级别上具有可用带宽的类总是优先于较高树级别的类.

让我们假设以下情况：段C不发送任何流量.段A只能尽可能快地发送实时流量(足以使链路单独饱和),而段B只发送大量流量,速度尽可能快(再次,足以使单独的完整链路饱和).会发生什么？

情况1：
段A->高Prio和段B-> Low Prio都有要发送的数据包,因为A-> High Prio具有更高的优先级,它将始终首先被调度,直到它达到其速率.现在它试图从A段借款,但由于A段处于较高水平而且B段> Low Prio尚未达到其速率,因此该类现在首先服务,直到它也达到该速率并且想要借入从B段开始.一旦两者都达到了他们的费率,两者都再次处于同一水平,现在A – >&High Prio将再次获胜,直到它达到A段的速度.现在它试图从根借(由于段C没有使用任何保证的流量,因此它有足够的流量备用,但同样,它必须等待段B->低Prio也达到根级别.一旦发生这种情况,将再次考虑优先级,此时段A-> High Prio将获得段C留下的所有带宽.

案例2：
高Prio->段A和低Prio->段B都有要发送的数据包,再次高Prio->段A将获胜,因为它具有更高的优先级.一旦它达到它的速率,它试图借用具有带宽备用的High Prio,但是在更高的水平上,它必须再次等待低Prio-> B段B也达到它的速率.一旦两者都达到了他们的速度并且都必须借用,高Prio-> A段将再次获胜,直到它达到High Prio级别的速度.一旦发生这种情况,它会尝试从root中借用,这又剩下足够的带宽(此时normal PRo的所有带宽都没有使用),但它必须再次等待,直到低Prio-> B段达到速率限制为止Low Prio类,也试图从root借用.最后,两个类都试图从root中借用,优先级被考虑在内,而High Prio-> Segment A获得所有带宽已经剩下的.

这两种情况看起来都是次优的,因为实时流量有时必须等待大量流量,即使有足够的带宽可以借用.但是,在情况2中,实时流量似乎必须等于情况1,因为它只需要等到达到批量流量速率,这很可能小于整个流量的速率(以防万一) 1这是它必须等待的速度).或者我在这里完全错了？

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

有关此设置的任何意见或想法？使用标准的tc qdiscs似乎很难.作为程序员,如果我可以简单地编写自己的调度程序(我不允许这样做),这是一项非常容易的任务.

解决方法 如果我正确理解htb,那么费率是“保证”的.这意味着您可以了解“实时”流量的比率.只有超过这个比率,它才会借入.如果几个班级想要借用,prio应该开始.保证的费率应该加上物理限制.否则这太麻烦了.

恕我直言,案例A永远不会真正起作用,因为您需要在根级别具有优先级或速率限制.不同部分的优先级/费率对彼此不了解,并且将得到平等处理.

您可能想要的是：将低速和普通prio的“速率”设置为0或接近它,并为其余带宽添加“上限”,对于高prio,您保证100％的物理速率.

总结

以上是内存溢出为你收集整理的linux – 通过HTB共享带宽和优先处理实时流量,哪种方案更好？全部内容，希望文章能够帮你解决linux – 通过HTB共享带宽和优先处理实时流量,哪种方案更好？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。