我阅读了关于 HFSC 的原始SIGCOMM '97 PostScript 论文，它非常技术性，但我了解基本概念。您可以指定凸或凹服务曲线，而不是给出线性服务曲线（与几乎所有其他调度算法一样），因此可以将带宽和延迟解耦。然而，即使本文提到了正在使用的调度算法（实时和链路共享），它总是只提到每个调度类的一条曲线（解耦是通过指定这条曲线来完成的，只需要一条曲线） ）。
现在已经使用ALTQ 调度框架为 BSD（OpenBSD、FreeBSD 等）实现了 HFSC，并且已经使用TC 调度框架（iproute2 的一部分）在 Linux 上实现了它。两种实现都添加了两条额外的服务曲线，这在原始论文中是没有的！实时服务曲线和上限服务曲线。再次请注意，原始论文提到了两种调度算法（实时和链接共享），但在那篇论文中，它们都使用一个单一的服务曲线。正如您目前在 BSD 和 Linux 中发现的那样，从来没有两条独立的服务曲线。
更糟糕的是，某些版本的 ALTQ 似乎为 HSFC 添加了额外的队列优先级（原始论文中也没有优先级这样的东西）。我发现有几个 BSD HowTo 提到了这个优先级设置（尽管最新的 ALTQ 版本的手册页不知道 HSFC 的这个参数，所以正式它甚至不存在）。
这一切都使得 HFSC 调度比原始论文中描述的算法更加复杂，并且互联网上有大量的教程经常相互矛盾，其中一个声称与另一个相反。这可能是为什么似乎没有人真正了解 HFSC 调度的真正工作原理的主要原因。在我提出问题之前，我们需要某种示例设置。我将使用一个非常简单的方法，如下图所示：
替代文字 http://f.imagehost.org/0177/hfsc-test-setup.png
以下是一些我无法回答的问题，因为教程相互矛盾：
我到底需要什么实时曲线？假设 A1、A2、B1、B2 都是 128 kbit/s 的链路共享（其中任何一个都没有实时曲线），那么如果根有 512 kbit/s 分配（并且A 和 B 当然都是 256 kbit/s），对吧？为什么还要给 A1 和 B1 一个 128 kbit/s 的实时曲线？这有什么好处？给这两个更高的优先级？根据原始论文，我可以通过使用曲线给它们更高的优先级，毕竟这就是 HFSC 的意义所在。通过给两个类一个 [256kbit/s 20ms 128kbit/s] 的曲线，它们的优先级都是 A2 和 B2 的两倍（平均仍然只有 128 kbit/s）
实时带宽是否计入链路共享带宽？例如，如果 A1 和 B1 都只有 64kbit/s 的实时带宽和 64kbit/s 的链路共享带宽，这是否意味着一旦通过实时为它们提供 64kbit/s 的服务，它们的链路共享要求也得到了满足（他们可能获得额外的带宽，但让我们暂时忽略它）或者这是否意味着他们通过链接共享获得了另外的 64 kbit/s？那么每个类是否都有实时加链接共享的带宽“要求”？或者如果链路共享曲线高于实时曲线（当前链路共享要求等于指定的链路共享要求减去已经提供给此的实时带宽），一个类是否只具有比实时曲线更高的要求？班级）？
上限曲线是否也适用于实时，仅适用于链接共享，或者可能适用于两者？有些教程说一种方式，有些人说另一种方式。甚至有人声称上限是实时带宽+链路共享带宽的最大值？真相是什么？
假设 A2 和 B2 都是 128 kbit/s，如果 A1 和 B1 仅是 128 kbit/s 链路共享，或 64 kbit/s 实时和 128 kbit/s 链路共享，是否有任何区别？ ，有什么区别？
如果我使用单独的实时曲线来增加类的优先级，我为什么需要“曲线”呢？为什么实时不是一个固定值，链接共享也是一个固定值？为什么两条曲线？原始论文中明确需要曲线，因为每个类只有一个此类属性。但是现在，有了三个属性（实时、链接共享和上限），我还需要每个属性上的曲线做什么？为什么我希望曲线形状（不是平均带宽，而是它们的斜率）对于实时和链接共享流量是不同的？
根据可用的少量文档，内部类（A 类和 B 类）的实时曲线值完全被忽略，它们仅适用于叶类（A1、A2、B1、B2）。如果这是真的，为什么ALTQ HFSC 示例配置（搜索3.3 示例配置）设置内部类的实时曲线并声称这些设置了这些内部类的保证速率？这不是完全没有意义吗？（注意：pshare 在 ALTQ 中设置链路共享曲线并光栅化实时曲线；您可以在示例配置上方的段落中看到这一点）。
有的教程说所有实时曲线的总和不能高于线速的80%，也有的说不能高于线速的70%。哪一个是对的，或者他们可能都错了？
一个教程说你会忘记所有的理论。不管事情真的如何运作（调度程序和带宽分配），根据下面的“简化思维模型”想象这三条曲线：实时是此类将始终获得的保证带宽。link-share 是这个类想要完全满足的带宽，但是不能保证满足。如果有多余的带宽，该类甚至可能会获得比满足所需更多的带宽，但它可能永远不会使用超过上限所说的。要使所有这些工作，所有实时带宽的总和可能不会超过线路速度的 xx%（请参阅上面的问题，百分比会有所不同）。问题：这或多或少是准确的还是对 HSFC 的完全误解？
如果上述假设确实准确，那么该模型中的优先级在哪里？例如，每个类可能有一个实时带宽（保证）、一个链路共享带宽（不保证）和一个上限，但仍然有一些类比其他类具有更高的优先级需求。在那种情况下，我仍然必须以某种方式优先考虑，即使在这些类的实时流量中也是如此。我会按曲线的斜率优先考虑吗？如果是这样，哪条曲线？实时曲线？链接份额曲线？上限曲线？他们全部？我会给它们所有人相同的斜率还是每个不同的斜率以及如何找出正确的斜率？
我仍然没有失去希望，这个世界上至少存在一群真正了解 HFSC 并能够准确回答所有这些问题的人。这样做而不在答案中相互矛盾会非常好;-)
阅读有关 HFSC 及其表亲的论文并不是理解它的好方法。HFSC 论文的主要目标是为其声明提供严格的数学证明，而不是解释其工作原理。事实上，您无法仅从 HFSC 论文中理解它是如何工作的，您还必须阅读它所引用的论文。如果您对索赔或其证明有疑问，那么联系论文的作者可能是个好主意，否则我怀疑他们会不会有兴趣收到您的来信。
我已经为 HFSC 编写了教程。如果我在下面的解释不清楚，请阅读它。
实时曲线和链路共享曲线以不同的方式评估。实时曲线考虑了一个班级在其整个历史中所做的事情。它必须这样做才能提供准确的带宽和延迟分配。缺点不是大多数人直观地认为是公平的。在实时情况下，如果一个类在其他人不想要它的时候借用带宽，那么当其他人想要它回来时它就会受到惩罚。这意味着在实时保证下，一个类可以在很长一段时间内得不到带宽，因为它在没有人想要的时候使用它。
链接共享是公平的，因为它不会因为使用空闲带宽而惩罚一个类。然而，这意味着它不能提供强大的延迟保证。
将链路共享与提供延迟保证分离是 HFSC 带来的新事物，该论文在开场白中说了很多：在本文中，我们研究了支持链路共享和保证的分层资源管理模型和算法具有解耦延迟（优先级）和带宽分配的实时服务。 那句话中的关键词是解耦的。翻译后，这意味着您应该说明如何与 ls 共享未使用的带宽，并指定 rt 需要哪些实时保证（也称为延迟保证）。两者是正交的。
是的。在 HFSC 论文中，他们根据自类已积压（即有数据包等待发送）以来类已发送的内容来定义带宽。rt 和 ls 之间的唯一区别是 rt 从每次类积压的时间开始向前看，并从该集合中计算最低保证带宽，而链接共享只从类的最后一次积压开始看。所以 rt 比 ls 考虑更多的字节，但是 ls 考虑的每个字节也被 rt 考虑。
上限不停止发送数据包以满足实时条件。在实时条件下发送的包仍然计入上限，因此将来可能会延迟在链路共享条件下发送的包。这是实时和链接共享之间的另一个区别。
是的，它确实有所作为。如上所述，如果您使用实时，则可以保证延迟，但不能公平地共享链接（特别是该类可能会遭受带宽不足），并且不强制执行上限。如果您使用链接共享，则无法保证延迟，但链接共享是公平的，没有饥饿的风险，并且强制执行上限。在链接共享之前总是检查实时，但这并不意味着链接共享将被忽略。那是因为数据包的计数方式不同。由于历史是实时考虑的，因此一个数据包可能不需要满足实时保证（因为从历史中计算了一个），但需要满足链路共享，因为它忽略了历史数据包。
实时控制曲线允许您用一个特定流量类别（例如 VOIP）的紧延迟来换取其他流量类别（例如电子邮件）的低延迟。当决定在实时约束下发送哪个数据包时，HFSC 会选择最先完成发送的数据包。但是，它不使用链路的带宽来计算它，它使用实时曲线分配的带宽。因此，如果我们有相同长度的 VOIP 和电子邮件数据包，并且 VOIP 数据包有一个凸曲线，如果电子邮件的凹曲线有 10 倍的提升，那么将在第一个电子邮件数据包之前发送 10 个 VOIP 数据包。但这仅发生在突发时间，最多应该是发送几个数据包所需的时间 - 即毫秒。此后 VOIP 曲线应该变平，并且 VOIP 将不会在未来得到任何提升，除非它退出一段时间（鉴于 VOIP 是一种低带宽应用程序，它应该）。所有这一切的最终结果是确保前几个 VOIP 数据包的发送速度比其他任何东西都快，从而以电子邮件获得高延迟为代价提供 VOIP 低延迟。
正如我之前所说，由于链接共享不查看历史记录，因此无法提供延迟保证。像 VOIP 这样的实时流量需要坚如磐石的保证。但是，平均而言，链接共享凸曲线仍会为其流量提供延迟提升。只是不能保证。这对大多数事情都很好，例如通过电子邮件的网络流量。
文档是正确的。层次结构（以及内部节点）对实时计算没有任何影响。我不能告诉你为什么 ALTQ 显然认为它确实如此。
两者都是错误的。如果 70% 或 80% 的流量具有必须实时指定的硬延迟要求，那么现实情况是，您几乎可以肯定您使用的链接无法满足它们。您需要更快的链接。
有人认为指定 80% 的流量应该是实时的唯一方法是，如果他们将实时作为优先级提升。是的，为了提供延迟保证，您实际上是在提高某些数据包的优先级。但它应该只有几毫秒。这就是链接可以处理的所有内容，并且仍然提供延迟保证。
很少有流量需要延迟保证。VOIP 是一个，NTP 是另一个。其余的都应该通过链接共享来完成。如果您希望网络快速，您可以通过为其分配大部分链接容量来使其快速。从长远来看，这一份额是有保证的。如果您希望它具有低延迟（平均而言），请在链接共享下给它一个凸曲线。
这是一个很好的描述上限。虽然链接共享描述是严格准确的，但它具有误导性。虽然它真正的链接共享并没有像实时那样提供硬延迟保证，但它在为类分配带宽方面做得比它的竞争对手（如 CBQ 和 HTB）更好。因此，在说链接共享“不提供保证”时，它将其保持在任何其他调度程序可以提供的更高标准。
实时的描述设法既准确，但误导我认为它是错误的。顾名思义，实时的目的不是保证带宽。这是为了提供有保证的延迟 - 即现在发送数据包，而不是稍后发送的随机时间量，具体取决于链接的使用方式。大多数流量不需要保证延迟。
也就是说，实时也不能提供完美的延迟保证。如果链接也不是由链接共享管理的，它可以，但大多数用户希望同时拥有两者的额外灵活性，而且它不是免费的。发送一个 MTU 数据包所需的时间，实时可能会错过它的延迟期限。（如果发生这种情况，那将是因为它是一个 MTU 数据包链路共享偷偷进入，同时实时保持链路空闲，以防它收到的数据包的截止日期很短，必须立即发送。这是链路共享之间的另一个区别和实时。为了提供保证，即使有数据包要发送，实时也可能故意保持线路空闲，从而提供低于 100% 的链路利用率。链路共享总是使用 100% 的链路可用容量。与实时不同,
可以说实时提供硬延迟保证的原因是延迟是有限的。因此，如果您尝试在 1Mbit/sec 链路上提供 20ms 延迟保证，并且链路共享正在发送 MTU 大小（1500 字节）的数据包，那么您知道其中一个数据包需要 12ms 才能发送。因此，如果您告诉实时您想要 8 毫秒的延迟，您仍然可以满足 20 毫秒的最后期限 - 绝对保证。
没有优先级模型。严重地。如果您想给予流量绝对优先级，请使用 pfifo。这就是它的用途。但也要注意，如果您将网络流量绝对优先于电子邮件流量，这意味着让网络流量使链接饱和，因此根本没有电子邮件数据包通过。然后，您所有的电子邮件连接都会消失。
实际上，没有人想要这种优先顺序。他们想要的是 HFSC 提供的。如果你真的有实时流量，HFSC 会提供。但这将是一切。对于其余部分，HFSC 允许您说“在拥塞的链接上，将 90% 分配给网络，让电子邮件以 10% 的速度传输，哦，快速发送奇怪的 DNS 数据包，但不要让别人用它来拒绝我。”
您可以定义具有不同名称的曲线：
当您在 HFSC 中仅使用费率进行定义时，它会自动将“dmax”设置为 0。这基本上意味着它不考虑延迟。一个好的 HFSC 配置应该包括你想为你的类使用的带宽和延迟边界，否则算法无法准确地计算出一个类应该获得多少优先级。
每当您赋予数据包优先级时，其他数据包的优先级必须降低。基于 'dmax' 和 'rate' 值，所有类都将使用虚拟计时器进行多路复用。有关详细信息，请参阅 tc-hfsc(7)。
如果流没有超出类的链接共享定义的边界，则永远不会使用实时曲线。在这种情况下定义实时曲线可以让您例如：保证某个“dmax”。
如果您的链接共享定义完美无缺，那么您就不需要实时曲线。您可以只定义服务曲线 (sc)，但这会使您的配置更加困难。
您的类的上限曲线仅适用于链接共享，当您定义上限曲线时，您必须定义链接共享曲线。然而，父类的上限曲线仍然适用。
如果 A2 = 0 kbits/s 和 B2 = 256 kbits/s，则存在细微差别。然后 A2 的虚拟时间将达到最大值。每当数据包在 A2 中分类时，它们将被立即处理。但是 B2 的实时曲线仍将确保能够传输至少 64 kbit/s
实时曲线不会在相邻叶子之间共享流量，而链路共享曲线则可以。
确实，内部类忽略了实时曲线，它们仅适用于叶类。然而，在这些内部类上定义的实时曲线被考虑到叶类的计算中。
他们的意思是：你不能对所有流量进行优先级排序……每当你给数据包优先级时，其他数据包的优先级就必须降低。如果你过度保证，算法就会变得毫无意义。定义获得优先级的类并定义可能受到影响的类。
这是对的。
例如，HFSC 和 HTB 之间的区别在于，HFSC 将允许您准确定义您希望它具有多少优先级。您可以通过使用“dmax”值定义最小和最大边界来做到这一点。
最后一个指南似乎解释了大多数不一致之处，以及当前的实现与原始论文有何不同：
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
根据本指南，许多其他关于 HFSC 的指南和论坛帖子完全是胡说八道；它只是显示了 HFSC 的复杂性，因为许多看似专家并假装完全了解 HFSC 的人实际上只有部分知识，并基于对概念的误解以及所有这些设置如何协同工作而做出虚假陈述。
我想我最终会放弃 HFSC。如果您可以正确设置 HFSC，它可能是您可以获得的最佳 QoS，但您完全搞砸的机会远高于成功的机会。
如果您无法获得原始作者，那么我接下来会尝试：
还可以尝试查看引用此文章的其他较新的论文。可能有更新的论文是该领域研究的延续，并且可能包含有关您所问问题的更多信息。