着信トラフィックのレート制限

着信トラフィックのレート制限が可能かどうか、私はまったく理解していません。リモートサーバーのパケット送信レートを制御する直接的な方法はありません（両方のエンドポイントを制御している場合を除きます）が、この制限を考慮すると、ダウンロードマネージャーを使用してダウンロード速度の制限を正しく設定する方法？

TCPスロースタートとレート制限着信トラフィックの間にリンクはありますか？slow-startで説明されている方法を使用して、送信者のパケット送信レートを人為的に制限することは可能ですか？

追加の考慮事項として、トラフィックシェーピングを実装するサーバーがPPPoE接続自体を確立し、残りのネットワークのルーターとして機能することに注意してください。

更新：これまでの回答は、私が尋ねた質問の公正な概要を示しましたが、ダウンロードマネージャーが着信トラフィックを制限する方法、さらに具体的には、同様の戦略を実装できるかどうかはまだわかりませんLinuxゲートウェイボックス。

ダウンロードマネージャーは、トリクルペーパーで説明されているように動作する可能性が高いです。

BSDソケットを利用するプロセスは、独自のレート制限を実行する場合があります。アップストリーム制限の場合、アプリケーションは、ソケットに書き込まれるデータのレートを制限するだけでこれを実行できます。同様に、ダウンストリーム制限の場合、アプリケーションはソケットから読み取るデータのレートを制限できます。ただし、これが機能する理由はすぐにはわかりません。アプリケーションがソケットからデータを読み取ることを怠ると、そのソケット受信バッファーがいっぱいになります。これにより、受信側のTCPが小さなレシーバーウィンドウ（rwnd）をアドバタイズし、基礎となるTCP接続にバックプレッシャーが生じ、データフローが制限されます。最終的に、この「トリクルダウン」効果により、エンドツーエンドのレート制限が実現します。ネットワークスタックのすべてのレイヤーでのバッファリングによっては、この効果の伝播に時間がかかる場合があります。

あなたは時折レート制限UNIXシステム上の単一のプログラムに必要がある場合は、簡単な解決策があるトリクル。ゲートウェイで実行するような実際のトラフィックシェーピングは、で実行できますtc。これについては、第9章「Linux Advanced Routing＆Traffic Control HOWTOの帯域幅管理のためのキューイング規則」で説明されています。

56kモデムと4 Mbps DSl回線の場合、（通常）速度の違いを生じさせるシェーピングはなく、リンクの速度の違いにすぎません。

着信トラフィックをシェーピングするのが難しい理由は、伝送媒体にバッファがないためです。着信ビットを受け入れるか、失われます。トラフィックがインターフェイスから出ようとしている場合、パケットを必要なだけバッファリングおよび並べ替えることができます（または、少なくともデバイスで使用可能なバッファメモリまで）。

TCPの上に層があるプロトコルの場合（それがトレントの場合かどうかはわかりません）、それはさらにデータの要求をペーシングする単純な問題です。そうでない場合、アプリケーションはOSと通信してパケットのACKを遅らせる必要があります。ほとんどのUDPベースのプロトコルは、必然的にアプリ固有のプロトコルにACK /再送信ロジックを備えているため、その時点でペースを調整するのは簡単です。

可能なルートの1つは、DSLルーターのLAN側でインターネットからのトラフィックをシェーピングすることです。その時点で、出力ポートでシェーピングすることになります。

着信データのシェーピングを許可するソリューションを見つけられなかった理由に答えることはできません（頭の外ではわかりません）が、受信者がデータを受信できる速度を送信者がどのように知るかについては答えられません。

TCP / IPの基本設計では、送信元が宛先に送信するすべてのパケットについて、宛先がACKパケットを受信したことを返信する（パケットで）のを待つ必要があります。

したがって、4Mbpsの送信者と56Kbpsの受信者がいる場合、送信者は座って、受信者が各パケットに応答するためにパケットを送信する間待機する必要があります（このオーバーヘッドを減らすための技術的な詳細がありますが、前提は依然として抽象的レベル）。

では、送信者が既に56Kbpsのデータを送信していて、もう少し送信しようとするとどうなりますか？

パケットは失われます。（まあ、潜在的にスイッチのバッファにキューされていますが、それがいっぱいになると、パケットは失われます）。パケットが失われたため、受信者はパケットを受信せず、ACKパケットを送信しません。送信者はこのACKパケットを受信しないため（送信されなかっただけでなく、失われたり、ネットワークが中断したりする可能性があるため）、送信者は余分なパケットを再送信する必要があります。座ってパケットが送信され、ACK応答が返されるまでパケットの再送信を試みます。

要約すると、送信者が受信者の帯域幅を使い切ったら、通過するのに十分な帯域幅が利用可能になるまで、次のパケットを停止して何度も再送する必要があります。これにより、クライアントが受信できる最大速度まで送信速度が効果的に低下します。（そして、この場合、パケットを再送しなければならない回数を減らす最適化方法があります。基本的に、送信者はパケットを再送しなければならないたびにスローダウンしますが、それはこの簡単な説明の範囲外です。

ifbインターフェースでそれを行うことができます。

ifbインターフェイスを使用すると、eth0（またはその他）の入力フローをifb0（たとえば）の出力にルーティングし、そこに制限ルールを適用できます。

Linux Foundationの次のURLを確認してください：http : //www.linuxfoundation.org/collaborate/workgroups/networking/ifb

そして、着信および発信帯域幅を制限する次のスクリプト：https : //github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

wondershaperをチェックしてください：http ://lartc.org/wondershaper/

着信トラフィックについて：

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.

UFW（Uncomplicated Fire Wall）を使用する http://ubuntuforums.org/showthread.php?t=1260812

このスレッドは、30秒以内に6ヒットのIPがデフォルトで拒否される単純な例を示しています。

sudo ufw limit ssh/tcp

また、時間とヒットカウントに指定された値を持つ、より「高度な」コマンド

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP