タグ付けされた質問 「traffic-management」

HFSCに関するオリジナルのSIGCOMM '97 PostScript論文を読みましたが、これは非常に技術的なものですが、基本的な概念は理解しています。ほぼすべての他のスケジューリングアルゴリズムと同様に、線形のサービスカーブを与える代わりに、凸または凹のサービスカーブを指定することができます。したがって、帯域幅と遅延を分離することができます。ただし、このペーパーでは使用されているスケジューリングアルゴリズムの種類（リアルタイムおよびリンク共有）に言及していますが、スケジューリングクラスごとに1つの曲線のみに言及しています（この曲線を指定することで分離が行われ、そのために必要な曲線は1つだけです） ）。 現在、HFSCはALTQスケジューリングフレームワークを使用してBSD（OpenBSD、FreeBSDなど）に実装され、TCスケジューリングフレームワーク（iproute2の一部）を使用してLinuxに実装されています。どちらの実装であった二つの追加サービスカーブ、コメントを追加しないで、元の論文では！リアルタイムのサービス曲線と上限のサービス曲線。繰り返しになりますが、元の論文では2つのスケジューリングアルゴリズム（リアルタイムとリンク共有）に言及していますが、その論文ではどちらも1つのサービスカーブで機能します。現在BSDとLinuxで見られるように、いずれか1つに対して2つの独立したサービス曲線はありませんでした。 さらに悪いことに、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がある場合、それぞれが128 kbit / sを取得します（そしてAとBは両方とももちろん256 kbit / sです）。A1とB1に128 kbit / sのリアルタイムカーブを追加するのはなぜですか？これは何に役立つでしょうか？これら2つに高い優先度を与えるには？元の論文によると、カーブを使用することで優先順位を高くすることができます。両方のクラスに[256kbit / s 20ms 128kbit / s]の曲線を与えると、両方とも自動的にA2とB2の2倍の優先度を持ちます（平均で128 kbit / sしか得られません） リアルタイム帯域幅はリンク共有帯域幅にカウントされますか？たとえば、A1とB1の両方に64kbit / sのリアルタイムと64kbit / sのリンク共有帯域幅しかない場合、リアルタイムで64kbit / sが提供されると、リンク共有要件も満たされることを意味します（余分な帯域幅を取得しますが、それをしばらく無視します）、またはリンク共有を介して別の64 kbit / sを取得することを意味しますか？それで、各クラスには、リアルタイムとリンクシェアの帯域幅の「要件」がありますか？または、リンク共有曲線がリアルタイム曲線よりも高い場合、クラスの要件はリアルタイム曲線よりも高いだけですか（現在のリンク共有要件は、指定されたリンク共有要件からこれに既に提供されているリアルタイム帯域幅を引いたものに等しい）クラス）？ 上限曲線はリアルタイムにも、リンク共有のみに適用されますか、それとも両方に適用されますか？一部のチュートリアルでは、一方の言い方があり、一部は、他の方法で言います。上限がリアルタイム帯域幅+リンク共有帯域幅の最大値であると主張する人もいますか？真実は何？ A2とB2が両方とも128 kbit / sであると仮定すると、A1とB1が128 …

35 linux  qos  traffic-shaping  bsd  traffic-management 

1台のマシンが持つことのできるポートの数に制限があり、ソケットが未使用のポート番号にしかバインドできない場合、サーバーはこれをどのように処理しますか？システムを分散させる、つまり、多くのマシンに多くのサーバーを配置するだけで実現できますか？

29 web-server  http  port  tcp  traffic-management 

インターネット回線に何らかのトラフィック管理を追加したいと思います。たくさんのドキュメントを読んだ後、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 …

10 linux  qos  traffic-shaping  traffic-management  htb