着信トラフィックのレート制限
incomingトラフィックをレート制限することが可能であるかどうかは、よくわかりません。 directメソッドがないことを理解しています。これにより、リモートサーバーのパケット送信レートを制御できます（両方のエンドポイントを制御している場合を除く）。ただし、この制限を考慮に入れると、ダウンロードマネージャーでダウンロード速度の制限を正しく設定できますか？
TCP slow-start とレート制限の着信トラフィックの間にリンクはありますか？スロースタートで説明されている方法を使用して、送信者のパケット送信レートを人為的に制限することは可能ですか？
追加の考慮事項として、トラフィックシェーピングを実装するサーバーがPPPoE接続自体を確立し、残りのネットワークのルーターとして機能することにも注意してください。
更新：これまでの回答では、私が尋ねた質問のかなりの概要が示されましたが、ダウンロードマネージャーが着信トラフィックを制限する方法などはまだわかりません。具体的には、Linuxゲートウェイボックスに同様の戦略を実装することが可能かどうか。
ダウンロードマネージャーは トリクルペーパー で説明されているように動作します。
BSDソケットを使用するプロセスは、独自のレート制限を実行する場合があります。アップストリーム制限の場合、アプリケーションは、ソケットに書き込まれるデータのレートを制限するだけでこれを実行できます。同様に、ダウンストリーム制限では、アプリケーションがソケットから読み取るデータのレートを制限する場合があります。ただし、これが機能する理由はすぐにはわかりません。アプリケーションがソケットからのデータの読み取りを怠ると、そのソケットの受信バッファーがいっぱいになります。これにより、受信側のTCPがより小さな受信側ウィンドウ（rwnd）をアドバタイズし、基になるTCP接続にバックプレッシャーがかかるため、データフローが制限されます。最終的に、この「トリクルダウン」効果は、エンドツーエンドのレート制限を実現します。ネットワークスタックのすべてのレイヤーのバッファリングによっては、この効果が伝播するまでに時間がかかる場合があります。
UNIXシステムで単一のプログラムを時々レート制限する必要がある場合、簡単な解決策は trickle です。ゲートウェイで実行するような実際のトラフィックシェーピングは、tcを使用して実行できます。これは、Linux Advanced Routing＆Traffic Control HOWTOの Chapter 9.帯域幅管理のキューイング規則 に記載されています。
56kのモデムと4 MbpsのDSl回線の場合、速度の違いは（通常）シェーピングではなく、リンクの速度の違いにすぎません。
着信トラフィックを形成するのが難しい理由は、伝送媒体にバッファがないためです。着信ビットを受け入れるか、失われます。トラフィックがインターフェイスを離れようとしている場合、パケットを必要なだけバッファリングして並べ替えることができます（または、少なくともデバイスで使用可能なバッファメモリまで）。
TCP（これが急流の場合であるかどうかはわかりません）の上にレイヤーがあるプロトコルの場合、それ以上のデータのペーシング要求の単純な問題になります。それ以外の場合、パケットのACKを遅らせるために、アプリケーションはOSと通信する必要があります。ほとんどのUDPベースのプロトコルは、必然的に、アプリケーション固有のプロトコルにACK /再送信ロジックを備えているので、その時点では、それらをペーシングするのは簡単です。
1つの可能なルートは、DSLルーターのLAN側でインターネットからのトラフィックをシェーピングすることです。その時点では、出力ポートでシェーピングしているからです。
着信データの整形を許可するソリューションが見つからなかった理由（そして頭上から何もわからない）には答えられませんが、送信者が受信者がデータを受信できる速さをどのように知るかについては、次のように答えます。
TCP/IPの基本的な設計は、ソースが宛先に送信するすべてのパケットについて、宛先が（ACKパケットを使用して）パケットを受信したと返信するまで待機する必要があるというものです。
したがって、4 Mbpsの送信者と56 Kbpsの受信者がいる場合、送信者は受信者が各パケットに応答するまで送信パケットの間に座って待機する必要があります（このオーバーヘッドを削減するための技術的な詳細がいくつかありますが、前提は抽象的なものです。レベル）。
では、送信者が既に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.