大きなファイル (2GB) に対する単純な「コピー」コマンドの速度に、ローカルと SSH 実行で違いがあるでしょうか?

大きなファイル (2GB) に対する単純な「コピー」コマンドの速度に、ローカルと SSH 実行で違いがあるでしょうか?

シナリオ例:
-リナックスマシン(オペレーティング システムは問題ないと思います)。
-OpenSSH サーバー
-ソースの大きなファイルハードディスクに約 2GB あります (SSD やクラシック HD でも問題ないと思います)。
- ファイルの保存先: a (中程度の速さの 2.0)USBペンドライブ(3.0 や 1.0 でも問題ないと思います)。

私はシンプルに注文します:

cp MyBigFile.iso /media/pendrive

ペンドライブが同じマシンに接続されています。
2 つのケース:

  1. ローカルシェル(私はマシンに座って、cp)大きなファイルの実行命令のコピーを行います。
  2. SSH シェル(同じ LAN 上の別のコンピューターに移動し、SSH クライアント経由でログインします) 大きなファイルのコピーをリモートで注文しました。

速度に違いが出ると予想するのは意味があるのでしょうか? なぜでしょうか?

実際、コピーに多数の小さなファイルサーバーとクライアント間の通信 (SSH シェル用) によって、多くの小さな遅延が発生する可能性があります (私が間違っていると思われる場合は、このロジックも自由に修正してください) が、大きな遅延についてはわかりません。

(私の意見については遠慮なく「気にしない」上記のシナリオも同様です。

答え1

マシンに ssh で接続して を実行するとcp fromFile toFile、そのコピーは完全にリモート マシン上で実行されます。コピーを実行するために ssh 経由で通信することはありません。実際、引数を指定しないと、 cp は ssh セッションに進行状況を報告することすらなく、完了するとプロンプトが表示されるだけです。

多数の小さなファイルをコピーしていて、 を使用するとcp -v、 cp はコピー時に各ファイルの名前を出力します。名前を出力すると、ssh 接続を介した通信が発生します。接続速度が遅い場合、 cp コマンドは ssh がネットワーク経由でファイル名を送信するよりも速くファイル名を出力する可能性があり、十分な数のファイル名を出力した後、 cp が stdout への書き込みをブロックする可能性があります。

実際にこのようなことが起こるのを見たことはありませんし、ディスク速度が常に制限要因となってきましたが、理論的には可能だと思います。

関連情報