1 分以上 (または N バイト以上、あるいは M パケット以上) 開いている TCP 接続を検出し、それらをバルク トラフィック (「ダウンロード」) として分類して優先順位を下げたいと思います。
iptables/netfilter/conntrack を使用して長時間実行されているストリームを検出し、tc によるシェーピング対象としてマークすることはできますか?
TCP の「シーケンス番号」をストリームの長さの尺度として使用できるかもしれないと思いましたが、残念ながらゼロから始まるわけではありません。おそらく、netfilter/conntrack による接続追跡によって、正しいシーケンス番号、または合計バイト数と接続期間を決定し、パケットをマークするかどうかを選択できるでしょう。
（私はこれを進入ifb0仮想インターフェースを使用しています。私は現在、低優先度データを制限するためにtbfキュー（sfq付き）を使用しています。いずれにしても、どんな解決策も適用できます。出口たとえば、接続が制限されている Web サーバーで、小さなリクエストを高速化するためにダウンロードの優先順位を下げたい場合などです。
更新: conntrackd を使用すると、接続のリストと、各接続が開始されてからどのくらい経ったかを確認できます。このリストを使用して、制限したい IP/ポート ペアを検出し始めました (60 秒後)。ただし、いくつかの問題があります。
- conntrack(d) は、接続が閉じられたときに、リストから接続をすぐにクリアしないようです。そのため、終了した接続も含めて、すべての接続を制限対象としてマークすることになります。
- conntrack でマークを設定しても、パケットにマークが設定されないようです (tc が確認する限り)。 (これは、conntrack が ifb0 の後のパケットを確認するからだけではありません。出力パケットにもマークが表示されません。) そのため、制限のために tc に新しいフィルターを追加していますが、これは長期的には理想からは程遠いものです。
- conntrack(d) では、各接続が使用した帯域幅の量はわかりません。そのため、断続的なセッション (isocket など) と大量のダウンロードを区別できません。(いずれにしても、これは難しい問題です。すでに 5 つのダウンロードがあり、新しいダウンロードが開始された場合、フラッディングしようとしていることをどのように判断すればよいのでしょうか。最大速度に近づくことはありません。)
上記に関するご提案があれば、ぜひお聞かせください。
(良い面としては、ダウンロードを正しく分類できない場合でも、tfb を使用して受信データを最大ダウンレートの 80% に制限するだけで、接続のオーバーフラッディングが防止され、以前よりもはるかに簡単に新しい接続を確立できるようになりました。)
答え1
接続の寿命と実際の寿命は、接続を特別に形成する必要があるかどうかとはまったく関係がありません。
いくつかの例：
SSH は、数分、数時間、数日、数週間、さらには数か月と長期間存続する可能性があります。ユーザー操作に応答するには、依然として高い優先度が必要です。
Bittorrent (または同様のプロトコル) はランダムに存続し、数秒間存続して切断されるものもあれば、数分または数時間存続して切断されるものもあります。一度に 1 日以上存続するものはほとんどありません。
要約: 接続の長さは、接続が「バルク」であるかどうか、および接続をバルクとして扱う必要があるかどうかとはまったく関係ありません。
必ずしも直接関連しているわけではありませんが、役に立ちます:
トラフィック シェーピングを使用する場合、ダウンロード トラフィックを制限することは有益でしょうか、それとも有害でしょうか?