私たちのインターネット回線に何らかのトラフィック管理を追加したいと考えています。多くのドキュメントを読んだ後、HFSC は私にとって複雑すぎると思います (曲線に関するすべてのことを理解しているわけではないので、正しく理解できないのではないかと思います)。CBQ は推奨されません。基本的に、ほとんどの人にとっては HTB が最適な方法です。
弊社の内部ネットワークには 3 つの「セグメント」があり、私はそれらの間で帯域幅をほぼ均等に共有したいと考えています (少なくとも最初は)。さらに、少なくとも 3 種類のトラフィック (リアルタイム トラフィック、標準トラフィック、バルク トラフィック) に応じてトラフィックを優先順位付けする必要があります。帯域幅の共有は、リアルタイム トラフィックは可能な限り常にプレミアム トラフィックとして扱われるべきであるという事実ほど重要ではありませんが、もちろん他のトラフィック クラスも不足してはなりません。
問題は、何がより理にかなっていて、より優れたリアルタイム スループットを保証するかということです。
セグメントごとに 1 つのクラスを作成します。各クラスは同じレートを持ちます (HTB 開発者によると、リーフのないクラスでは優先度は関係ありません)。また、これらの各クラスには、3 つの優先度レベル (優先度とレートが異なります) に対して 3 つのサブクラス (リーフ) があります。
最上位の優先レベルごとに 1 つのクラスがあり、それぞれが異なるレートを持ち (この場合も優先度は関係ありません)、それぞれに 3 つのサブクラス (セグメントごとに 1 つ) がありますが、リアルタイム クラスの 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:
セグメント A->High Prio とセグメント B->Low Prio の両方に送信するパケットがあり、A->High Prio の方が優先度が高いため、レートに達するまで常に最初にスケジュールされます。次に、セグメント A から借りようとしますが、セグメント A の方がレベルが高く、セグメント B->Low Prio はまだレートに達していないため、このクラスが最初に処理され、これもレートに達してセグメント B から借りようとするまで処理されます。両方がレートに達すると、両方とも再び同じレベルになり、今度はセグメント A->High Prio が再び勝利し、セグメント A のレートに達するまで続きます。次に、ルート (セグメント C は保証されたトラフィックをまったく使用していないため、トラフィックに十分な余裕があります) から借りようとしますが、この場合も、セグメント B->Low Prio がルート レベルに到達するまで待機する必要があります。それが起こると、優先順位が再び考慮され、今度はセグメント A -> High Prio がセグメント C から残ったすべての帯域幅を取得します。
ケース 2:
High Prio->Segment A と Low Prio->Segment B の両方に送信するパケットがあり、ここでも High Prio->Segment A が優先されます。これは、優先度が高いためです。High Prio->Segment A がレートに達すると、帯域幅に余裕がある High Prio から借りようとしますが、High Prio の方がレベルが高いため、Low Prio->Segment B がレートに達するまで待たなければなりません。両方のレートがレートに達し、借りる必要が生じると、High Prio->Segment A が High Prio クラスのレートに達するまで再び優先されます。レートに達すると、再び十分な帯域幅が残っているルートから借りようとしますが (この時点では Normal Prio のすべての帯域幅は使用されていません)、Low Prio->Segment B が Low Prio クラスのレート制限に達するまで再び待たなければならず、ルートからも借りようとします。最終的に、両方のクラスがルートから借りようとします。優先度が考慮され、High Prio->Segment A はルートに残っているすべての帯域幅を取得します。
どちらのケースも最適とは言えません。どちらの場合も、借りられる帯域幅が十分残っているにもかかわらず、リアルタイム トラフィックはバルク トラフィックを待たなければならないことがあるからです。ただし、ケース 2 では、バルク トラフィック レートに達するまで待つだけでよく、そのレートはおそらくセグメント全体のレートよりも低いため (ケース 1 では、そのレートを待たなければなりません)、リアルタイム トラフィックの待機時間はケース 1 よりも短くなるようです。それとも、私は完全に間違っているのでしょうか。
優先度 qdisc を使用する、さらに簡単な設定も考えました。しかし、優先度キューには、何らかの制限を設けないと、リソース不足を引き起こすという大きな問題があります。リソース不足は許容されません。もちろん、各優先度クラスに TBF (トークン バケット フィルター) を配置してレートを制限し、リソース不足を回避することはできますが、そうすると、他のすべての優先度クラスが空であっても、1 つの優先度クラスだけでリンクを飽和させることはできなくなります。TBF によって、そのような事態は発生しなくなります。また、これは最適とは言えません。なぜなら、現時点で他のクラスがまったく帯域幅を必要としない場合、あるクラスが回線の帯域幅の 100% を取得できないのはなぜでしょうか。
この設定に関してコメントやアイデアはありますか? 標準の tc qdisc を使用するのは非常に難しいようです。プログラマーとしては、独自のスケジューラを作成できれば非常に簡単な作業です (これは許可されていません)。
答え1
私がHTBを正しく理解しているなら、レートは「保証」されているということです。つまり、持っている「リアルタイム」トラフィックのレートに関するアイデア。このレートを超えた場合のみ、借用します。複数のクラスが借用を希望する場合は、prio が作動する必要があります。保証されたレートは、物理的な制限を加算する必要があります。そうしないと、面倒すぎます。
私の意見では、ルート レベルで優先度またはレート制限を設定する必要があるため、ケース A は実際には機能しません。異なるセグメントの優先度/レートは互いについて何も知らず、平等に処理されます。
おそらく必要なのは、低優先度と通常優先度の「レート」を 0 またはそれに近い値に設定し、残りの帯域幅に「上限」を追加することです。高優先度の場合は、物理的なレートの 100% を保証します。