web-dev-qa-db-ja.com

ネットワーク（FTP、HTTP、RSyncなど）を介してファイルを転送する最速の方法は何ですか

2つのシステム間でネットワークを介して大量のデータを転送する最良の方法を見つけようとしています。現在、FTP、HTTP、またはRSyncのいずれかを検討していますが、どちらが最も速いのか疑問に思っています。いくつかの回答をオンラインで探したところ、次のサイトが見つかりました。

問題は、これらが古く、プロトコルの通信方法の理論的な違いについて詳しく説明していることです。実際のベンチマークにもっと興味があります。つまり、特定のセットアップでは、さまざまなサイズのファイルを転送するとき、1つのプロトコルが他のプロトコルよりもx％高速です。

誰かがこれらをテストし、結果をどこかに投稿しましたか？

httpnetworkingfile-uploadftprsync
21
oneself

それでは、次のテストをセットアップします。

  • ハードウェア：2デスクトップ、Intel Core Duo CPU @ 2.33GHz、4GのRAM。
  • OS：両方のマシン上のUbuntu 11.10
  • ネットワーク：100Mb専用スイッチ、両方のマシンが接続されています。
  • ソフトウェア：

次のファイルグループを各サーバーにアップロードしました。

  1. 1 100Mファイル。
  2. 10個の10Mファイル。
  3. 100個の1Mファイル。
  4. 1,000個の100Kファイル。
  5. 10,000個の10Kファイル。

複数の実行で次の平均結果を得ました（秒単位の数値）：

|-----------+---------+----------|
| File Size | FTP (s) | HTTP (s) |
|-----------+---------+----------|
|      100M |       8 |        9 |
|       10M |       8 |        9 |
|        1M |       8 |        9 |
|      100K |      14 |       12 |
|       10K |      46 |       41 |
|-----------+---------+----------|

したがって、大きなファイルではFTPがわずかに速く、多くの小さなファイルではHTTPが少し速いようです。全体として、それらは同等であり、サーバーの実装はプロトコルよりもはるかに重要だと思います。

35
oneself

両端のマシンがかなり強力な場合（つまり、ネットブック、NASボックス、トースターなどではない場合）、TCPで動作するすべてのプロトコルがほぼ同じ速度になると思います。バルクデータの転送時。アプリケーションプロトコルの仕事は、TCPが転送するためにバッファを一杯にすることです。したがって、TCPがいっぱいになるようにペースを設定します。

圧縮または暗号化を行うプロトコルは、性能の低いマシンのCPUでボトルネックになる場合があります。私のネットブックはSCPよりもはるかに高速にFTPを実行します。

rsyncはインクリメンタルな変更を迅速に送信するために巧妙なことを行いますが、バルク転送の場合は、dumbプロトコルよりも利点はありません。

7
Tom Anderson

考慮すべきもう1つのユーティリティはbbcpです。 http://www.slac.stanford.edu/~abh/bbcp/ 。

これを使用するための優れた、しかし古くなったチュートリアルは、ここにあります： http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm bbcpは大きなファイル（複数のGB）の転送に非常に優れていることがわかりました。私の経験では、平均してrsyncよりも高速です。

4
kadal

rsyncはオプションでデータを圧縮します。通常、これにより転送がはるかに高速になります。 rsync -z を参照してください。

Scpについては言及しませんでしたが、 scp -C も圧縮します。

CPUおよびネットワークリンクの速度に応じて、圧縮により転送が高速または遅くなる場合があることに注意してください。 （リンクが低速でCPUが高速の場合、圧縮が優れたアイデアになります。リンクが高速でCPUが低速の場合、圧縮が無効になります。）最適化と同様に、ご使用の環境で結果を測定します。

3
Robᵩ

ニーズと設定に対する答えを知りたい場合は、より具体的にするか、独自のパフォーマンス（および信頼性）テストを行う必要があります。問題のプロトコルとその通信について少なくとも初歩的な理解を得るのに役立ちますので、引用されている記事は有用なリソースであると考えます。また、これらのプロトコルの初期の発明者が直面した制限を知るのに役立ちます-ネットワークへの影響を低く抑えることを目的としたのか、メモリ不足に陥るのか、CPUサイクルをカウントする必要があるのか​​？状況に応じた回答を取得したい場合、考慮または回答すべき事項をいくつか示します。

  • OS /ファイルシステム関連：
    • 同じOS/FSの組み合わせ間でコピーを行っていますか、または受信側で同等のものが一致しないファイルタイプなどの非互換性について心配する必要がありますか？
    • つまり輸送する特別なものはありますか？メタデータ、リソースフォーク、拡張属性、ファイル許可は、選択したプロトコル/ツールによって転送されないか、受信側で無意味になる可能性があります。
    • 同じことがスパースファイルにも当てはまります。これは、コピーのもう一方の端でフルサイズに肥大化する可能性があり、サイジングについて持っていたすべての計画を台無しにします。
  • 関連する物理的制約：
    • ネットワークへの影響
    • cpu負荷：最近の圧縮は、ほとんどの転送プロトコルが設計された当時のものよりも現代のCPUの方が圧縮の影響を受けにくいため、圧縮ははるかに「安く」なります。
    • 耐障害性-中断した転送が残った場所をピックアップできるようにする必要がありますか、それとも新たに始めたいですか？
    • 増分転送、または完全転送？インクリメンタル転送はあなたにとって大きな節約になりますか、それともタスクの設計による完全な転送がありますか？後者の場合、転送を開始する前に転送リストを作成するために追加されたレイテンシとメモリの影響は、あまり望ましくないトレードオフになります。
    • 基礎となるネットワークプロトコルで利用可能なMTUの利用プロトコルはどれくらい優れていますか？
    • たとえば、受信側でテープドライブのストリーミングを維持するために、データの安定したストリームを維持する必要がありますか？

考慮すべきことがたくさんありますが、リストは完全ではありません。

2
Tatjana Heuser