0

Linux でフローベースのトラフィック シェーピングを実現する方法があるかどうか疑問に思っています。従来のトラフィック シェーピング アプローチは、高いスループットを必要とする特定のプロトコルまたはパケットのタイプ (ssh、http、SYN、ACK など) のクラスを作成することに基づいているようです。

ここでは、すべての TCP 接続を、特定のデータ レートによって特徴付けられるフローとして見たいと考えています。あるだろう

  • インタラクティブな ssh や IRC チャットなどのクイック フローと
  • scp や http ファイル転送などの低速フロー (バルク データ)

現在、着信パケットをこれらのクラスのいずれかに特徴付け/分類する方法を探しているので、tc ベースのトラフィックシェーパーを実行できます。ヒントはありますか?

4

1 に答える 1

2

専用マシンについて言及しているため、ネットワークブリッジから管理しているため、システム内にある存続期間中、パケット全体にアクセスできると想定します。

何よりもまず、リンクの飽和について話している場合、接続の受信側でのスロットリングは無意味です。パケットが表示されるまでには、すでにリソースを消費しています。これは、あなたがブリッジであっても当てはまります。現実的には、エグレス インターフェイスでインテリジェントなことを行うことしかできません。

私は、あなたが望むものを正確に実行する既製の製品を見つけることはできないと思います. 実行中に派生するルールに従って、dummynetのようなものを動的に変更するか、既存のインフラストラクチャを使用して動的ソフトウェア ルーターをプログラムする必要があります。私がよく知っているのはクリックモジュラールーターですが、他にもあります。tc高頻度で構成/再構成されることにどのように反応するか、どのように反応するかは本当にわかりipfwません-不十分だと思います。

ただし、事前に対処しなければならないことがあります。実装に関係なく、このタスクを困難にするもの。例えば、

  1. scp バルクと ssh のインタラクティブな動作をどのように区別する予定ですか? 初期の動作を監視し、それに基づいてルールを適用しますか?
  2. HTTP固有のスロットリングについて言及しています。これは DPI を意味します。このブリッジ/ルーターでそれをサポートできますか? サポートするアプリケーション トラフィックのクラスはいくつですか?
  3. 競合をどのように処理する予定ですか? (それぞれが容量の 30% を取得するように「バルク」フローを割り当てますが、消費しようとする 10 個の「バルク」フローを取得します)
  4. リンク容量をハードコーディングしますか、それとも測定しますか? それは固定されていますか、それとも変化しますか?

一般に、ネットワークの 5 タプルをハッシュするだけで、「フロー」のかなり大まかなアイデアを得ることができます。ただし、アプリケーションのセマンティクスの処理を開始すると、すべての賭けがオフになり、必要なものを取得するためにパケットの内容を掘り下げる必要があります。

より具体的な目的がある場合は、これらのポイントのいくつかが意味のないものになる可能性があります。

于 2011-02-01T15:02:54.743 に答える