linux – 通过HTB共享带宽和优先处理实时流量,哪种方案更好?
我想在我们的互联网线路上添加一些流量管理.在阅读了大量文档之后,我认为HFSC对我来说太复杂了(我不了解所有曲线的东西,我担心我永远不会把它弄好),CBQ不推荐,基本上HTB就是通往适合大多数人.
我们的内部网络有三个“段”,我想在这些段之间或多或少地分享带宽(至少在开始时).此外,我必须根据至少三种流量(实时流量,标准流量和批量流量)确定流量的优先级.带宽共享并不像实际流量应尽可能始终被视为高级流量那样重要,但当然也没有其他流量类别可能会饿死. 问题是,什么更有意义,也保证更好的实时吞吐量: >每个段创建一个类,每个具有相同的速率(根据HTB开发人员,优先级对于没有叶子的类没有关系),并且这些类中的每一个都有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手册说,如果一个类已经达到它的速率,它可以从其父级借用,并且在借用时,具有更高优先级的类总是首先获得带宽.但是,它还说,无论优先级如何,在较低树级别上具有可用带宽的类总是优先于较高树级别的类. 让我们假设以下情况:段C不发送任何流量.段A只能尽可能快地发送实时流量(足以使链路单独饱和),而段B只发送大量流量,速度尽可能快(再次,足以使单独的完整链路饱和).会发生什么? 情况1: 案例2: 这两种情况看起来都是次优的,因为实时流量有时必须等待大量流量,即使有足够的带宽可以借用.但是,在情况2中,实时流量似乎必须等于情况1,因为它只需要等到达到批量流量速率,这很可能小于整个流量的速率(以防万一) 1这是它必须等待的速度).或者我在这里完全错了? 我想到了更简单的设置,使用优先级qdisc.但优先队列有一个很大的问题,即如果它们不受某种限制,就会导致饥饿.饥饿是不可接受的.当然,可以将TBF(令牌桶过滤器)放入每个优先级以限制速率,从而避免饥饿,但是这样做时,单个优先级类不能再自行饱和链接,即使所有其他优先级类别也是如此是空的,TBF将防止这种情况发生.这也是次优的,因为如果没有其他类目前需要其中任何一个类,为什么一个类不能获得100%的线路带宽? 有关此设置的任何意见或想法?使用标准的tc qdiscs似乎很难.作为程序员,如果我可以简单地编写自己的调度程序(我不允许这样做),这是一项非常容易的任务. 解决方法
如果我正确理解htb,那么费率是“保证”的.这意味着您可以了解“实时”流量的比率.只有超过这个比率,它才会借入.如果几个班级想要借用,prio应该开始.保证的费率应该加上物理限制.否则这太麻烦了.
恕我直言,案例A永远不会真正起作用,因为您需要在根级别具有优先级或速率限制.不同部分的优先级/费率对彼此不了解,并且将得到平等处理. 您可能想要的是:将低速和普通prio的“速率”设置为0或接近它,并为其余带宽添加“上限”,对于高prio,您保证100%的物理速率. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |