我讀過原著SIGCOMM '97 PostScript 論文關於HFSC，技術性很強，但我了解基本概念。您可以指定凸或凹服務曲線，而不是給出線性服務曲線（與幾乎所有其他調度演算法一樣），從而可以解耦頻寬和延遲。然而，即使本文提到了正在使用的調度演算法類型（實時和鏈路共享），它總是只提到每個調度類別的一條曲線（解耦是透過指定這條曲線來完成的，只需要一條曲線） ）。
現在 HFSC 已針對 BSD（OpenBSD、FreeBSD 等）實現，使用ALTQ調度框架它已經在 Linux 上實作了TC調度框架（iproute2 的一部分）。兩種實作都增加了兩條額外的服務曲線，即不是在原始論文中！即時服務曲線和上限服務曲線。再次請注意，原始論文提到了兩種調度演算法（即時和連結共享），但在那篇論文中，兩者都適用於一條服務曲線。正如您目前在 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一條128kbit/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%（請參閱上面的問題，百分比有所不同）。 Q：這或多或少是準確的，還是對 HSFC 的完全誤解？
如果上述假設確實準確，那麼該模型中的優先順序在哪裡？例如，每個類別可能具有即時頻寬（保證）、鏈路共享頻寬（不保證）以及可能的上限，但仍有一些類別比其他類別具有更高的優先需求。在這種情況下，即使在這些類別的即時流量中，我仍然必須以某種方式確定優先順序。我會根據曲線的斜率來決定優先順序嗎？如果是的話，哪條曲線？即時曲線？連結共享曲線？上限曲線？他們全部？我會給所有它們相同的斜率還是每個都不同的斜率以及如何找出正確的斜率？
我仍然沒有失去希望，世界上至少有一群人真正理解 HFSC，並且能夠準確地回答所有這些問題。這樣做在答案中不會互相矛盾，那就太好了;-)
答案1
閱讀有關 HFSC 及其同類論文的論文並不是理解它的好方法。 HFSC 論文的主要目標是為其主張提供嚴格的數學證明，而不是解釋其工作原理。事實上，僅憑 HFSC 論文你無法理解它是如何運作的，你還必須閱讀它引用的論文。如果您對主張或證據有疑問，那麼聯繫論文作者可能是個好主意，否則我懷疑他們是否有興趣收到您的來信。
我寫了一個HFSC 教程。如果我下面的解釋不清楚，請閱讀它。
為什麼我需要即時曲線？假設 A1、A2、B1、B2 都是 128 kbit/s 連結共享（其中任何一個都沒有即時曲線），那麼如果根有 512 kbit/s 可供分配（當然，A 和B 都是256 kbit/ s），對嗎？為什麼我要另外給A1和B1一條128kbit/s的即時曲線？這有什麼好處呢？給這兩個更高的優先權？根據原始論文，我可以透過使用曲線給他們更高的優先級，這畢竟是 HFSC 的全部內容。透過為兩個類別提供 [256kbit/s 20ms 128kbit/s] 的曲線，兩者的優先權都會自動達到 A2 和 B2 的兩倍（平均仍僅獲得 128 kbit/s）
即時曲線和連結共享曲線的評估方式不同。實時曲線考慮了一個類別在其整個歷史中所做的事情。它必須這樣做才能提供準確的頻寬和延遲分配。缺點並不是大多數人直觀地認為的那樣公平的。在即時情況下，如果一個類別在沒有其他人需要時借用頻寬，那麼當其他人稍後想要收回它時，它就會受到懲罰。這意味著在即時保證下，一個類別可以在很長一段時間內無法獲得頻寬，因為它在沒有人需要的時候更早地使用了它。
連結共享是公平的，因為它不會懲罰使用空閒頻寬的類別。然而，這意味著它無法提供強有力的延遲保證。
將連結共享與提供延遲保證分開是 HFSC 帶來的新事物，這篇論文在開頭就說了這麼多：在本文中，我們研究了分層資源管理模型和演算法，它們支援鏈路共享和保證即時服務，並具有解耦的延遲（優先權）和頻寬分配。 這句話中的關鍵字是解耦。翻譯過來，這意味著您需要說明如何與 ls 共享未使用的頻寬，並指定 rt 需要哪些即時保證（又稱延遲保證）。兩者是正交的。
即時頻寬是否計入鏈路共享頻寬？
是的。在 HFSC 論文中，他們根據類已積壓（即有資料包等待發送）後已發送的內容來定義頻寬。 rt 和 ls 之間的唯一區別是 rt 從每次類積壓的時間開始向前查找併計算該組中的最低保證帶寬，而鏈接共享僅從類上次積壓的時間開始查找。因此 rt 比 ls 考慮更多的字節，但 ls 考慮的每個位元組也被 rt 考慮。
上限曲線是否也適用於即時、僅適用於連結共享，或兩者都適用？
上限不會阻止資料包的發送以滿足即時條件。即時情況下發送的封包仍計入上限，因此很可能會延遲將來在連結共享情況下發送的封包。這是實時和連結共享之間的另一個區別。
假設 A2 和 B2 都是 128 kbit/s，那麼 A1 和 B1 僅 128 kbit/s 連結共享，或 64 kbit/s 即時和 128 kbit/s 連結共享有什麼區別嗎？
是的，它確實有所作為。如上所述，如果您使用即時，延遲是有保證的，但連結沒有公平共享（特別是該類別可能會遭受頻寬匱乏），並且不強制執行上限。如果您使用連結共享，則無法保證延遲，但連結共享是公平的，不存在飢餓風險，並且強制執行上限。在連結共享之前始終檢查即時，但這並不一定意味著連結共享將被忽略。這是因為資料包的計數方式不同。由於歷史是即時考慮的，因此資料包可能不需要滿足即時保證（因為歷史資料中包含了一個資料包），但需要滿足連結共享，因為它忽略了歷史資料包。
如果我使用單獨的即時曲線來增加類別的優先級，為什麼我需要「曲線」？為什麼即時不是固定值，連結共享也是固定值？為什麼兩條曲線都是？原始論文中對曲線的需求很明確，因為每個類別只有一個此類屬性。但現在，有了三個屬性（即時、連結共享和上限），我還需要每個屬性上的曲線嗎？為什麼我希望即時流量和連結共享流量的曲線形狀（不是平均頻寬，而是它們的斜率）不同？
即時控製曲線可讓您以特定流量類別（例如 VOIP）的低延遲來換取其他流量類別（例如電子郵件）的低延遲。當在即時約束下決定要發送哪個資料包時，HFSC 選擇第一個完成發送的資料包。但是，它不使用鏈路的頻寬來計算此值，而是使用即時曲線分配的頻寬。因此，如果我們有相同長度的VOIP 和電子郵件資料包，並且VOIP 資料包具有凸曲線，該曲線比電子郵件的凹曲線高出10 倍，那麼將在第一個電子郵件資料包之前發送10個VOIP 資料包。但這只發生在突發時間，這最多應該是發送幾個資料包所需的時間 - 即毫秒。此後，VOIP 曲線應趨於平緩，並且 VOIP 將不會獲得未來的成長，除非它回落一段時間（考慮到 VOIP 是一種低頻寬應用，它應該如此）。所有這一切的最終結果是確保前幾個 VOIP 資料包的發送速度比其他資料包更快，從而以電子郵件獲得高延遲為代價提供 VOIP 低延遲。
正如我之前所說，由於連結共享不查看歷史記錄，因此無法提供延遲保證。諸如 VOIP 之類的即時流量需要堅如磐石的保證。然而，平均而言，鏈路共享凸曲線仍會為其流量提供延遲提升。只是無法保證。這對於大多數事情來說都很好，例如電子郵件上的網路流量。
根據可用的少量文檔，內部類別（A 類和 B 類）完全忽略即時曲線值，它們僅應用於葉類（A1、A2、B1、B2）。如果這是真的，為什麼 ALTQ HFSC 範例配置（搜尋 3.3 範例配置）會在內部類別上設定即時曲線，並聲稱這些曲線設定了這些內部類別的保證速率？這不是完全沒有意義嗎？ （注意：pshare 在 ALTQ 中設定連結共享曲線並劃分即時曲線；您可以在範例配置上方的段落中看到這一點）。
文檔是正確的。層次結構（以及內部節點）對即時計算沒有任何影響。我無法告訴你為什麼 ALTQ 顯然認為是這樣。
有的教學說所有即時曲線的總和不能高於線速度的80%，也有的說不能高於線速度的70%。哪一個是對的，或者兩者都錯了？
兩者都是錯的。如果您的 70% 或 80% 的流量具有必須即時指定的硬延遲要求，那麼事實是您幾乎可以肯定您所使用的連結無法滿足他們的要求。您需要更快的連結。
人們認為指定 80% 的流量應該是即時的唯一方法是，他們是否將即時作為優先級提升。是的，為了提供延遲保證，您實際上提高了某些資料包的優先順序。但它應該只會持續幾毫秒。這就是鏈路可以應對的全部情況，並且仍然提供延遲保證。
需要延遲保證的流量非常少。 VOIP 是其中之一，NTP 是另一個。其餘的都應該透過連結共享來完成。如果您希望網路速度更快，則可以透過為其分配大部分連結容量來使其更快。那份分享是長期保證。如果您希望它具有低延遲（平均），請在連結共享下給它一條凸曲線。
一篇教學說你會忘記所有的理論。無論實際情況如何（調度程序和頻寬分配），請根據以下「簡化思維模型」想像這三個曲線：實時是此類始終獲得的保證頻寬。 link-share是該類別想要完全滿足的頻寬，但不能保證滿足。如果有多餘的頻寬，類別甚至可能會獲得比滿足所需更多的頻寬，但它可能永遠不會使用超過上限的頻寬。為了使所有這些工作正常，所有即時頻寬的總和不得高於線路速度的 xx%（請參閱上面的問題，百分比有所不同）。 Q：這或多或少是準確的，還是對 HSFC 的完全誤解？
這是一個很好的描述上限。雖然連結共享描述是嚴格準確的，但它具有誤導性。雖然真正的連結共享無法像即時那樣提供硬延遲保證，但與 CBQ 和 HTB 等競爭對手相比，它在為類別分配頻寬方面做得更好。因此，當說連結共享「不提供保證」時，它的標準高於任何其他調度程序可以提供的標準。
即時的描述確實是準確的，但具有誤導性，我認為它是錯誤的。顧名思義，即時的目的不是提供保證的頻寬。它是為了提供保證的延遲 - 即資料包立即發送，而不是根據連結的使用方式稍後發送一些隨機時間。大多數流量不需要保證延遲。
也就是說，即時也不能提供完美的延遲保證。如果連結也不是由連結共享管理的，則可以，但大多數用戶希望同時擁有這兩者的額外靈活性，而且它不是免費的。即時可能會因發送 MTU 封包而錯過其延遲期限。 （如果發生這種情況，那是因為它是一個MTU 資料包鏈路共享，同時即時保持鏈路空閒，以防收到必須立即發送的截止期限很短的資料包。這是鏈路共享之間的另一個區別為了保證實時性，即使有數據包要發送，也可能會故意保持線路空閒，因此與實時不同，鏈路共享始終使用 100% 的可用鏈路容量。 。
即時之所以可以提供硬延遲保證，是因為延遲是有限的。因此，如果您嘗試在 1Mbit/sec 連結上提供 20ms 延遲保證，且連結共用正在傳送 MTU 大小（1500 位元組）的封包，那麼您知道其中一個封包將需要 12ms 來傳送。因此，如果您告訴即時您想要 8 毫秒的延遲，您仍然可以滿足 20 毫秒的最後期限 - 有絕對的保證。
如果上述假設確實準確，那麼該模型中的優先順序在哪裡？例如，每個類別可能具有即時頻寬（保證）、鏈路共享頻寬（不保證）以及可能的上限，但仍有一些類別比其他類別具有更高的優先需求。在這種情況下，即使在這些類別的即時流量中，我仍然必須以某種方式確定優先順序。我會根據曲線的斜率來決定優先順序嗎？如果是的話，哪條曲線？即時曲線？連結共享曲線？上限曲線？他們全部？我會給所有它們相同的斜率還是每個都不同的斜率以及如何找出正確的斜率？
沒有優先級模型。嚴重地。如果您想給予流量絕對優先級，請使用 pfifo。這就是它的用途。但也要注意，如果您給予網路流量相對於電子郵件流量的絕對優先級，這意味著讓網路流量使連結飽和，從而沒有電子郵件資料包通過，根本不。然後你所有的電子郵件連線都會消失。
事實上，沒有人想要這種優先順序。他們想要的正是 HFSC 提供的。如果您確實有即時流量，HFSC 可以提供。但這將是全部。對於其餘部分，HFSC 允許您說「在擁塞的連結上，將90% 分配給網絡，讓電子郵件以10% 的速度傳輸，哦，快速發送奇怪的DNS 資料包，但不要讓別人用它來DOS我。
答案2
您可以使用不同的名稱定義曲線：
- rt，即時曲線，頻寬/延遲保證。
- ls，連結共享曲線，頻寬/延遲共享（基於鄰居葉子的配置）
- ul，上限曲線，可能達到的最大頻寬/延遲。
為什麼我需要即時曲線？假設 A1、A2、B1、B2 都是 128 kbit/s 連結共享（其中任何一個都沒有即時曲線），那麼如果根有 512 kbit/s 可供分配（當然，A 和B 都是256 kbit/ s），對嗎？為什麼我要另外給A1和B1一條128kbit/s的即時曲線？這有什麼好處呢？給這兩個更高的優先權？根據原始論文，我可以透過使用曲線給他們更高的優先級，這畢竟是 HFSC 的全部內容。透過為兩個類別提供 [256kbit/s 20ms 128kbit/s] 的曲線，兩者的優先權都會自動達到 A2 和 B2 的兩倍（平均仍僅獲得 128 kbit/s）
當您在 HFSC 中僅使用費率進行定義時，它會自動將“dmax”設為 0。良好的 HFSC 配置應包括您想要用於類別的頻寬和延遲邊界，否則演算法無法準確計算出類別應獲得多少優先順序。
每當您賦予資料包優先順序時，其他資料包的優先順序都必須降低。基於“dmax”和“rate”值，所有類別都將使用虛擬計時器進行多路復用。請參閱 tc-hfsc(7) 以了解更多資訊。
即時頻寬是否計入鏈路共享頻寬？例如，如果 A1 和 B1 都只有 64kbit/s 即時頻寬和 64kbit/s 連結共享頻寬，這是否意味著一旦透過即時為它們提供 64kbit/s 服務，它們的連結共享要求也得到滿足（它們可能獲得額外的頻寬，但讓我們忽略這一點）或者這是否意味著他們透過連結共享獲得另一個64 kbit/s？那麼每個類別是否都有即時和鏈路共享的頻寬「要求」？或者，如果連結共享曲線高於即時曲線，則類別是否僅具有比即時曲線更高的要求（當前鏈路共享要求等於指定的鏈路共享要求減去已提供給該類別的即時頻寬）班級） ？
如果流量沒有超出類別的鏈路共享定義的邊界，則永遠不會使用即時曲線。在這種情況下定義即時曲線可以讓您例如：保證一定的「dmax」。
如果您的連結共享定義完美無缺，那麼您就不需要即時曲線。您可以只定義服務曲線 (sc)，但這會使您的配置更加困難。
上限曲線是否也適用於即時、僅適用於連結共享，還是兩者都適用？有些教程說一種方式，有些教程說另一種方式。甚至有人說上限是即時頻寬+連結共享頻寬的最大值？真相是什麼？
您的類別的上限曲線僅套用於連結共享，當您定義上限曲線時，您必須定義連結共享曲線。但仍適用父類的上限曲線。
假設 A2 和 B2 都是 128 kbit/s，那麼 A1 和 B1 僅 128 kbit/s 連結共享，或 64 kbit/s 即時和 128 kbit/s 連結共享有什麼區別嗎？
例如，如果 A2 = 0 kbits/s 且 B2 = 256 kbits/s，則存在細微差別。那麼A2的虛擬時間將達到最大。每當資料包被分類為 A2 時，它們將立即被處理。但B2的即時曲線仍會保證至少能夠傳輸64 kbit/s
如果我使用單獨的即時曲線來增加類別的優先級，為什麼我需要「曲線」？為什麼即時不是固定值，連結共享也是固定值？為什麼兩條曲線都是？原始論文中對曲線的需求很明確，因為每個類別只有一個此類屬性。但現在，有了三個屬性（即時、連結共享和上限），我還需要每個屬性上的曲線嗎？為什麼我希望即時流量和連結共享流量的曲線形狀（不是平均頻寬，而是它們的斜率）不同？
即時曲線不會在相鄰葉子之間共享流量，但連結共享曲線會共享流量。
根據可用的少量文檔，內部類別（A 類和 B 類）完全忽略即時曲線值，它們僅應用於葉類（A1、A2、B1、B2）。如果這是真的，為什麼 ALTQ HFSC 範例配置（搜尋 3.3 範例配置）會在內部類別上設定即時曲線，並聲稱這些曲線設定了這些內部類別的保證速率？這不是完全沒有意義嗎？ （注意：pshare 在 ALTQ 中設定連結共享曲線並劃分即時曲線；您可以在範例配置上方的段落中看到這一點）。
確實，內部類別會忽略即時曲線，它們僅適用於葉類。然而，在葉類的計算中會考慮在這些內部類別上定義的即時曲線。
有的教學說所有即時曲線的總和不能高於線速度的80%，也有的說不能高於線速度的70%。哪一個是對的，或者兩者都錯了？
他們的意思是：你不能確定所有流量的優先順序...每當你給予資料包優先順序時，其他資料包的優先順序都必須降低。如果你過度保證，演算法就變得毫無意義。定義獲得優先順序的類別並定義可能受到影響的類別。
一篇教學說你會忘記所有的理論。無論實際情況如何（調度程序和頻寬分配），請根據以下「簡化思維模型」想像這三個曲線：實時是此類始終獲得的保證頻寬。 link-share是該類別想要完全滿足的頻寬，但不能保證滿足。如果有多餘的頻寬，類別甚至可能會獲得比滿足所需更多的頻寬，但它可能永遠不會使用超過上限的頻寬。為了使所有這些工作正常，所有即時頻寬的總和不得高於線路速度的 xx%（請參閱上面的問題，百分比有所不同）。 Q：這或多或少是準確的，還是對 HSFC 的完全誤解？
這是對的。
如果上述假設確實準確，那麼該模型中的優先順序在哪裡？例如，每個類別可能具有即時頻寬（保證）、鏈路共享頻寬（不保證）以及可能的上限，但仍有一些類別比其他類別具有更高的優先需求。在這種情況下，即使在這些類別的即時流量中，我仍然必須以某種方式確定優先順序。我會根據曲線的斜率來決定優先順序嗎？如果是的話，哪條曲線？即時曲線？連結共享曲線？上限曲線？他們全部？我會給所有它們相同的斜率還是每個都不同的斜率以及如何找出正確的斜率？
例如，HFSC 和 HTB 之間的差異在於，HFSC 將允許您準確定義您希望它具有多少優先順序。您可以透過使用“dmax”值定義最小和最大邊界來實現此目的。
答案3
最後一個指南似乎解釋了大多數不一致之處以及當前的實現與原始論文有何不同：
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
根據本指南，許多其他有關 HFSC 的指南和論壇貼文完全是無稽之談；這只是表明 HFSC 是多麼複雜，因為許多看似專家並假裝完全了解 HFSC 的人實際上只了解部分知識，並基於對概念的誤解以及所有這些設定如何共同發揮作用而做出錯誤的陳述。
我想我最終會放棄HFSC。如果您能夠正確設定 HFSC，這可能是您可以獲得的最佳 QoS，但您完全搞砸的機會遠高於成功的機會。
答案4
如果您無法聯繫到原作者，那麼我接下來會嘗試以下方法：
- 進入linux核心原始碼樹，找到實作「TC調度框架」的C文件
- 查看標題並找到程式碼的作者。
- 「TC 調度框架」的電子郵件程式設計師要求他們提供有關其實現的文獻。
也可以嘗試檢查引用這篇文章的其他較新的論文。可能有更新的論文是該領域研究的延續，並可能包含有關您所問問題的更多資訊。