web-dev-qa-db-ja.com

Linuxでの受信（入力）トラフィックシェーピング-bwが予想より低い

Linuxボックスの着信（ダウンロード）速度を制限したい。

構成されているボックスとトラフィックソース（HTTPサーバー）の両方が同じスイッチに接続されています。シェーピングが構成されていない場合、ダウンロード速度は30MBpsです。

私は http://lartc.org/lartc.html に従ってtcを使用します

########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent 
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:

/sbin/tc qdisc add dev $DEV handle ffff: ingress

# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:

/sbin/tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

ただし、有効なダウンロード速度は、構成よりもはるかに遅くなります。これが私の実験結果です

セットレート、KBps：実際のレート、KBps

  • 32 KBps：30 KBps
  • 64 KBps：50 KBps
  • 128 KBps：106 KBps
  • 256 KBps：160 KBps
  • 512 KBps：210 KBps
  • 1024 KBps：255 KBps

帯域幅が狭い場合、シェーピングは非常にうまく機能しますが、1024 KBitでは、効果的なビットレートは予想よりも75％低くなります。

着信帯域幅を効果的に制限することは可能ですか？

linuxtraffic-shapingiproute2
4
andreikop

bwが予想より低い

それに応じてburstも増やす必要があると思います。

着信帯域幅を効果的に制限することは可能ですか？

パケットを受信する代わりに、パケットをドロップすることで同様の効果が確実に得られると思います。帯域幅のセルフチューニングメカニズムを備えたTCPのようなプロトタイプでは、効果的に機能します。 http://www.linuximq.net/faq.html を見てください

5
poige

着信帯域幅を効果的に制限することは可能ですか？

[〜＃〜]いいえ[〜＃〜]。

着信帯域幅を制限しようとすることは、基本的に、ドリルで穴を開けたボードを持ち上げることによって、消防ホースの流れを制限しようとすることです。あなたに当たる水の量は減りますが、それでも消防ホースに当たっています。

100ガロンの水が必要であるが、（ボードに穴を開けてボードを押し上げることによって）到達する速度を制限する場合、ファイアホースの類推をさらに実行すると、ファイアホースの力の矢面に立つことになります（トラフィックあなたのパイプを下って来る）、しかしほとんどの水を得られない ファイアウォール ボード）。

すべての水をブロックすることの効果は、100ガロンのバケツを満たすのに時間がかかることです。
ブロックする効果TCPファイアウォールを備えたパケットは、リモートホストの congetion control algorithm をトリガーするため、少し悪いですが、これは理想的な世界ではファイアホースへの圧力を下げます。必要な場合よりも大幅に低くなることがあります。

ちなみにこれは、ローカルファイアウォールがDoS攻撃からあなたを救うことができない理由でもあります。たとえそれを無視する決定をするだけであっても、すべてのトラフィックを処理する必要があります。明らかな理由により、DoS攻撃が輻輳制御手順を順守することはほとんどありません。

3
voretaq7

着信帯域幅の制限に関する混合結果を聞いたことがありますが、これはカーネルのifbデバイスで可能になるはずです。 1つの真実は@ voretaq7が言ったことですが、すべての入力パケットを受け入れ、リダイレクトまたはミラーリングを使用して「I_ntermediate F_unctional B_lockデバイスの1つにリダイレクトする場合、着信パケットを「制限」できます。これらに、通常、 「出力」フィルタリング。

すべてのトラフィックをifbに受け入れなければならないので、これは「役に立った」ように聞こえないかもしれませんが、その場合、保留キューからシステムの残りの部分にどのトラフィックが送信されるかを決定できます。

これには、優先度の低いパケットでない限り、パケットをドロップしないという利点があります。確かに、DoSを実行している場合、重要な問題は、受信トラフィックの合計が回線が維持できるよりも高いことです。このため、この方法で影響を与えようとしても無駄です。このメソッドはany必要なプロトコル（TCP、UDP、ICMPなど）を介した正当なストリームでのみ機能します。つまり一括ダウンロードよりもDNSを優先したい場合は、それが可能ですが、どのトラフィックアルゴリズムを使用していても、30Mb /であれば、1000Hzの最速の通常のクロック割り込みで、30Kbのトラフィックを処理する必要があります。 /クロックティック。これは、タイムリーに呼び出されることを前提としています。これが、高いバーストレートが必要な主な理由です。レート制限だけではそれだけを処理することが難しいためです。

ネットワークカードに複数のI/Oキューがある場合はhelpfulになります。多くのカードには6〜12のキュー/方向があり、通常はイーサネットカードの制限されたフィルタリングオプションに基づいて、「自動」で個別のキューに分類できます。

さらに役立つこと-トラフィックをこれらの複数のキューに分割できる場合は、キューのプロセッサアフィニティを設定できます。 CPU処理パケットに制限があることに気付いた場合、multiQを使用すると、着信トラフィックを処理のために別のコアに分散させるのに役立ちます（ハイパースレッディングを使用しないでください。スレッドが動作していないため、パフォーマンスの問題が発生する可能性があります。共有データではあるが、個別のデータストリーム。これらの処理は、個別のL1キャッシュとL2キャッシュを使用するCPUで最適です（通常、L3は引き続き複数のコア間で共有されます）が、少なくともL1キャッシュとL2キャッシュを専用に使用できます。 "流れ"）。

スループットの問題が原因で、単一キューとポリシングを使用していたため、上り制御をあきらめました-現時点では5Mbしか着信していなかったため（現在は7Mb）、multiqとifbは入力シェーピング中です。現状では、私は通常、アプリケーションレベルのシェーピングとコントロールを使用しています。理想的ではありませんが、かなり信頼できます。

時々発生する問題の1つは、回線の問題またはISPの輻輳のどちらかが原因で、最大帯域幅が得られず、固定フィルタープリセットが適応しないことです。これが、私が機能しなかったもう1つの理由です。レート制限を動的にして、そのような問題を感知するためにどれだけの作業が必要かわからないため、この問題についてはあまりにも難しいです。そして、現在、キューに他の優先度の高いプロジェクトが多すぎます...（そして私のI/Oレートがイーサネットポートよりはるかに低い）... ;-)

0
Astara