タグ付けされた質問 「htb」

1
HTBの最小レートおよびデフォルトクラスの問題
私が使用しているHTB構造については疑問があります。 私の目的は、ローカルネットワークのユーザーのダウンロードとアップロードの速度を制限することです。ネットワークの各ユーザーには、ドメインの個人用リストがあり、ドメインの速度は上下できません。 つまり、user1はslashdot.orgでのアクセスをダウンロードで8KB、アップロードで3KBに制限でき、user2はslashdot.orgでのアクセスを4KBから1KBに制限できます。 現時点では、うまく機能するiptables / tcカップルをセットアップしますが、非常に小さな規模で、同時に2つまたは3つの仮想ホストを使用します(残念ながら、実際のサイズテストは実行できません)。 現在の構造は次のとおりです(LANの出口にあるもののみを表示します。アップロード用のものは、単にこの「コピー」です) インターフェイスにアタッチされたHTB qdisc(ハンドル2 :)、デフォルトのトラフィッククラスはクラスFFFFです。 HTB qdiscの直下にあるルートクラス2:1は、DOWNLINKキャパシティのレートと上限を持っています。 2:1の子としてのデフォルトクラス2:FFFF。レートは1kbspで、上限はDOWNLINK容量です。 次に、特定のドメインのユーザーに新しい制限がある場合、他のクラスが動的に追加され、そのドメインからのダウンロード速度を制御するために新しいtcクラスが追加されます。 今のところ、私がやったことは次のとおりです。 一意のIDを持つ新しいtcクラスを作成します(ここではポイントではなく、データベースから取得します)。クラス2:1の親として、レート値は1bps、ceil値は制限されたダウンロード速度に設定されます。 tcコマンドは次のとおりです。 -------------- BEGIN SCRIPT -------------- DOWNLINK=800 ## Setting up the static tc qdisc and class $tc qdisc add dev $LAN_IFACE root handle 2: htb default 0xFFFF # Main class so the default class can …

1
HTBを介した帯域幅の共有とリアルタイムトラフィックの優先順位付け。どちらのシナリオが適切に機能しますか?
インターネット回線に何らかのトラフィック管理を追加したいと思います。たくさんのドキュメントを読んだ後、HFSCは私には複雑すぎると思います(すべての曲線を理解しているわけではありません。正しく理解できないと思います)。CBQはお勧めしません。基本的にHTBはほとんどの人のために行きます。 私たちの内部ネットワークには3つの「セグメント」があり、それらの間で帯域幅を多かれ少なかれ均等に共有したいと思っています(少なくとも最初は)。さらに、少なくとも3種類のトラフィック(リアルタイムトラフィック、標準トラフィック、バルクトラフィック)に従ってトラフィックを優先する必要があります。帯域幅の共有は、リアルタイムトラフィックを可能な限り常にプレミアムトラフィックとして扱う必要があるという事実ほど重要ではありませんが、他のトラフィッククラスが不足することはありません。 問題は、何がより意味があり、リアルタイムのスループットが向上するかを保証することです。 セグメントごとに1つのクラスを作成し、それぞれが同じレートを持ち(HTB開発者によると、葉ではないクラスでは優先度は関係ありません)、これらの各クラスには、3つの優先度レベル(異なる優先度)の3つのサブクラス(葉)がありますと異なるレート)。 優先度レベルごとに1つのクラスがあり、それぞれに異なるレートがあり(やはり優先度は関係ありません)、セグメントごとに1つずつ、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 …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.