または同様のツールを使用して出力トラフィックをシェーピングできることはわかっていますtc。ただし、今は入力トラフィックをシェーピングしたいのですが、実際には、低速で損失の多い接続を介して特定の種類のファイルのダウンロードを優先したいと考えています。
理由はtc、出力トラフィックを形作るだけであり、ホスト自体は入力トラフィックの量を直接制御できないためだとわかっています。一方、TCP には、TCP トラフィックが低速接続でオーバーフローするのを防ぐための対策が組み込まれています。では、TCP ヘッダーを改変して、リモート ホストが自分の接続が思っているよりも遅いと認識するようにすることはできるでしょうか?
を使用して、両方のタイプの接続に対応するマークを設定できるとしますiptables。2 番目のタイプの接続が存在する場合にのみ、最初のタイプの接続の入力帯域幅を減らす方法はありますか?
答え1
あなたが言及しているのはTCP明示的輻輳通知（http://en.wikipedia.org/wiki/Explicit_Congestion_Notification) Linux サーバー自体がパケットを受信する頃には、すでにパケットを受信しており、事後に調整しようとしているため、探しているものは技術的に可能ではないと思います。
現実的に、QOS またはトラフィック シェーピングが必要な場合は、受信側ではなく上流のプロバイダーで実行する必要があります。つまり、すべてのトラフィック シェーピングは、送信先側ではなく送信元側で実行されます。
答え2
この問題には非常に優れた解決策がありますが、残念ながら Linux では無料で利用できるものはありません。パケットを遅延またはドロップしても、効果は非常に低くなります。必要な場合は実行できますが、結果はせいぜい適切です。パケットを受信する頃には、保護しようとしている受信帯域幅はすでに消費されています。
正しい方法は、発信 TCP ウィンドウ広告を改変して、相手側に小さなウィンドウを広告することです。これを実行するハードウェアおよびソフトウェア実装はありますが、私の知る限り、Linux で無料で利用できるものはありません。
これ脚本それを実行する方法の 1 つが説明されており、理論と制限を説明する非常に詳細なコメントがいくつかあります。