高速で待ち時間の長いWANリンクを介して単一の大きなファイルを転送する最良の方法は何ですか？
ロックされています。この質問に対するコメントは無効になっていますが、新しい回答やその他の相互作用はまだ受け付けています。詳細をご覧ください。 これはこれに関連しているように見えますが、多少異なります。 2つの企業サイト間にこのWANリンクがあり、1つの非常に大きなファイル（Oracleダンプ、最大160 GB）を転送する必要があります。 完全な100 Mbpsの帯域幅（テスト済み）がありますが、TCPの仕組み（ACKなど）により、単一のTCP接続では最大にならないようです。リンクをiperfでテストし、TCPウィンドウサイズを大きくすると結果が劇的に変化します。基本設定では最大5 Mbpsのスループットが得られ、より大きなWSでは最大で最大45 Mbpsが得られますが、それ以上は得られません。ネットワーク遅延は約10ミリ秒です。 好奇心から、1つ以上の接続を使用してiperfを実行しましたが、4つの接続を実行すると、実際にはそれぞれ〜25 Mbpsの速度に達し、利用可能なすべての帯域幅がいっぱいになることがわかりました。そのため、複数の同時転送を実行することが重要になります。 FTPでは、事態はさらに悪化します。最適化されたTCP設定（高いウィンドウサイズ、最大MTUなど）でも、1回の転送で20 Mbpsを超えることはできません。いくつかの大きなファイルを同時にFTPで送信しようとしましたが、実際には1つのファイルを転送する場合よりもはるかに良くなりました。しかし、その後、犯人はディスクI / Oになりました。これは、同じディスクの4つの大きなファイルの読み込みと書き込みがすぐにボトルネックになるためです。また、少なくとも1つの大きなファイルを小さなファイルに分割してから、少なくとも許容時間内にマージして戻すことはできないようです（明らかに、ファイルのスプライシング/マージバックに相当する時間を費やすことはできません）転送）。 ここでの理想的なソリューションは、ファイルのさまざまなチャンクを同時に転送できるマルチスレッドツールです。eMuleやBitTorrentのようなピアツーピアプログラムのようなものは既にありますが、単一のソースから単一の宛先までです。理想的には、このツールを使用すると、使用する並列接続の数を選択でき、もちろん、ファイルのさまざまなセクション間で狂ったように（あまりにも）ジャンプしないようにディスクI / Oを最適化できます。 誰でもそのようなツールを知っていますか？ または、誰もがより良い解決策や私たちがまだ試みていない何かを提案できますか？ PSすでにテープ/ディスクにバックアップし、宛先に物理的に送信することを考えました。WANがそれを削減しない場合、それは私たちの極端な測定値になりますが、AS Tanenbaumが言ったように、「高速道路を疾走するテープでいっぱいのステーションワゴンの帯域幅を過小評価しないでください」。