すべてのインターフェイスを制限および変更するために、トラフィック制御（TC）を使用してネットワークをシミュレートしています。私のインターフェースはHTB --- SFQ形式です（少し複雑ですが単純化します）。
インターフェイス速度は10mbpsに制限されます。 7mbpsの速度でAからBにUDPストリームを送るとしましょう。その後、同じホスト（A）からBにTCPストリームを送信します。出力インターフェイスにSFQがあり、2つのストリームがあるため、スケジューラはストリームあたり5 mbpsを送信します。したがって、最初にUDPストリームは2mbpsの帯域幅を失います。
もちろん、これは公平なキューで期待できるものです。送信する各ストリームで適切な数のパケットを送信したいと思います。しかし、いくつかのACKタイムアウトの後、UDPストリームは7mpbsを使用し、TCPは3mpbsを使用することが予想されます。しかし、私はタイムアウトを見たことがありません。 SFQキューを削除すると、すべてが期待どおりに機能し、TCPトラフィックは3mpbsに達し、UDPトラフィックは7mbpsに達します。
これは普通ですか？これが私が期待すべきものですか？これが通常の動作である場合、これは、特定のルートに相当なTCPトラフィックがある場合に損失を望まない場合は、UDPトラフィックに50％しか使用できないことを意味します。
SFQキューを維持する方法はありますか？
ベストアンサー1
これは予想されます。 SFQは、限られた帯域幅を超えて競合するとき、公平性に近いTCP / TCPに優しいプロトコルを実施します。一部のトラフィックが公平な配布よりも多くなければならない場合は、それらを分類して競合するSFQインスタンスをバイパスする必要があります。これがHTBの目的です（クラスのないTBFとは反対）。
これは一般的な戦略です。そこにはいくつかの実際の例がありますが、必要に応じて得られませんでした。一般に、優先順位の高いカテゴリの帯域幅は、次のことを防ぐために制限されます。完全他のトラフィックを飢えさせてください。
https://wiki.archlinux.org/index.php/Advanced_traffic_control#Hierarchical_Token_Bucket_.28HTB.29
http://lartc.org/howto/lartc.qdisc.filters.html
一部のUDPトラフィックはTCPに優しく設計されています。クイック。 UDPトラフィックをフィルタリングしている場合、Chrome nightliesからダウンロードすると、優先順位の高い帯域幅が飽和する可能性があります。公平性の観点からは、これは言葉ではありません。
また、SFQをFQ_CODELに変更したい場合もほぼ確実です。テスト負荷による遅延。http://dslreports.com/speedtest、またはping飽和テストのいずれかでのみ可能です。 （興味深い注意があります。uTPを使用する「バックグラウンド」トラフィックは、誘導されたレイテンシを100ms未満に保つことによって機能します。これと同じことをTCPと競合します。