なぜscpはとても遅いのですか？
scpを使用してファイルのバッチをコピーしようとしていますが、非常に低速です。これは、10個のファイルの例です。
$ time scp cap_* user@Host:~/dir
cap_20151023T113018_704979707.png 100% 413KB 413.2KB/s 00:00
cap_20151023T113019_999990226.png 100% 413KB 412.6KB/s 00:00
cap_20151023T113020_649251955.png 100% 417KB 416.8KB/s 00:00
cap_20151023T113021_284028464.png 100% 417KB 416.8KB/s 00:00
cap_20151023T113021_927950468.png 100% 413KB 413.0KB/s 00:00
cap_20151023T113022_567641507.png 100% 413KB 413.1KB/s 00:00
cap_20151023T113023_203534753.png 100% 414KB 413.5KB/s 00:00
cap_20151023T113023_855350640.png 100% 412KB 411.7KB/s 00:00
cap_20151023T113024_496387641.png 100% 412KB 412.3KB/s 00:00
cap_20151023T113025_138012848.png 100% 414KB 413.8KB/s 00:00
cap_20151023T113025_778042791.png 100% 413KB 413.4KB/s 00:00
real 0m43.932s
user 0m0.074s
sys 0m0.030s
奇妙なことに、転送速度は約413KB/sで、ファイルサイズは約413KBなので、実際には毎秒1ファイルを転送する必要がありますが、ファイルごとに約4.3秒かかります。
このオーバーヘッドがどこから来るのか、それを速くする方法はありますか？
@wurtelのコメントはおそらく正しいでしょう。各接続を確立するために多くのオーバーヘッドがあります。 修正できる場合 転送が速くなります（解決できない場合は、@ roaimaのrsync回避策を使用してください）。私は同じようなサイズのファイルを転送する実験をしました（head -c 417K /dev/urandom > foo.1とそのファイルのコピーをいくつか作成しました）、接続に時間がかかるホスト（Host4）と非常に速く応答するホスト（Host1）に送信します。
$ time ssh $Host1 echo
real 0m0.146s
user 0m0.016s
sys 0m0.008s
$ time scp * $Host1:
foo.1 100% 417KB 417.0KB/s 00:00
foo.2 100% 417KB 417.0KB/s 00:00
foo.3 100% 417KB 417.0KB/s 00:00
foo.4 100% 417KB 417.0KB/s 00:00
foo.5 100% 417KB 417.0KB/s 00:00
real 0m0.337s
user 0m0.032s
sys 0m0.016s
$ time ssh $Host4 echo
real 0m1.369s
user 0m0.020s
sys 0m0.016s
$ time scp * $Host4:
foo.1 100% 417KB 417.0KB/s 00:00
foo.2 100% 417KB 417.0KB/s 00:00
foo.3 100% 417KB 417.0KB/s 00:00
foo.4 100% 417KB 417.0KB/s 00:00
foo.5 100% 417KB 417.0KB/s 00:00
real 0m6.489s
user 0m0.052s
sys 0m0.020s
$
rsyncを（sshよりも）使用できます。これは、単一の接続を使用してすべてのソースファイルを転送します。
rsync -avP cap_* user@Host:dir
rsyncがない場合（そしてその理由は！？）、次のようにtarをsshとともに使用すると、一時ファイルの作成を回避できます。
tar czf - cap_* | ssh user@Host tar xvzfC - dir
rsyncは、割り込みが発生した場合に再起動できるため、他のすべての条件が同じであることが推奨されます。
時間がかかるのは乗り換えの交渉です。一般に、nbバイトのファイルの操作には、それぞれn *-の単一ファイルの単一操作よりもはるかに長い時間がかかりますbバイト。これは、例えばディスクI/O用。
注意深く見ると、この場合の転送速度はsize_of_the_file/secsであることがわかります。
ファイルをより効率的に転送するには、tarを使用してファイルをバンドルし、次にtarballを転送します。
tar cvf myarchive.tar cap_20151023T*.png
または、アーカイブも圧縮する場合は、
tar cvzf myarchive.tar.gz myfile*
圧縮するかどうかは、ファイルの内容によって異なります。 JPEGまたはPNGの場合、圧縮による影響はありません。
Scpが、特に高帯域幅ネットワークで本来あるべき速度よりも遅いもう1つの理由は、静的に定義された内部フロー制御バッファーがあり、ネットワークパフォーマンスのボトルネックになることです。
HPN-SSH は、これらのバッファーのサイズを増加させるOpenSSHのパッチバージョンです。 scp転送速度に大規模な違いが生じます（サイトのグラフを参照してください。ただし、私も個人的な経験から話します）。もちろん、メリットを得るには、すべてのホストにHPN-SSHをインストールする必要がありますが、大きなファイルを定期的に転送する必要がある場合は、それだけの価値があります。
私は説明した手法を使用しました here 並列gzipとnetcatを使用して、データをすばやく圧縮してコピーします。
要約すると：
# SOURCE:
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888
# TARGET:
> nc <source Host> 8888 | pigz -d | tar xf - -C /
これはtarを使用してファイルを収集します。次に、pigzを使用して多くのCPUスレッドを取得し、ファイルを圧縮して送信します。ネットワーク伝送はnetcatを使用しています。受信側では、netcatがリッスンしてから（並行して）圧縮解除し、tarを展開します。
この問題は、scpを介して大きなmp4ファイルのサイト間転送を行うときに発生しました。約250KB/sを取得していました。宛先ファイアウォールでUDPフラッド保護（FP）を無効にした後、転送速度が6.5MB/sに増加しました。 FPをオンに戻すと、速度は250KB /秒まで低下しました。
送信者：cygwin、受信者：Fedora 20、ファイアウォールSophos UTM。
SSHは何のためにUDPを使用しますか？@ superuser.com -それは私が読んだものから直接ではありません。
ファイアウォールログを確認したところ、プライベートサイト間内部VPNアドレスではなく、パブリックIPアドレスを介して、送信元ポートと宛先ポート4500の両方でフラッド検出が発生していました。したがって、私の問題はおそらくNAT scp TCPデータが最終的に暗号化され、ESP ＆UDPパケット、およびその結果としてFPの影響を受けます。方程式からscpを削除するために、VPNを介してWindowsファイルコピー操作を実行したところ、FPを有効または無効にした場合のscpと同様のパフォーマンスが得られました。また、実行されました。 TCPに対するiperfテスト。FPありの場合は2Mビット/秒、FPなしの場合は55Mビット/秒であることがわかりました。
この質問はそれほど古いものではなく、誰もがこのソリューションを参照していないので、250kb/s前後のscpとは異なり、帯域幅が最大制限（私の場合は10MiB/s）にプッシュされるため、適切であると思います。質問。
実際にはrsyncと同じ250kb/s-少なくともポート指定子rclone -Avvp cap_* -e "ssh -p 1087 -i id_rsa" user@Host:~/dir
Openssh-unix-devメーリングリストへの 投稿の引用 ：
Scpプロトコルは古く、柔軟性がなく、簡単に修正できません。その作成者は、代わりにファイル転送にsftpやrsyncなどのより近代的なプロトコルの使用を推奨しています
同じ構文がsftpにも適用されるので、scp text.txt user@Hostの代わりにsftp text.txt user@Host（ の使用例scpがsftp と交換可能）になりました。
また、最近のバージョンのOpenSSHはデーモンをアクティブにするはずです。少なくとも私の場合、Arch Linuxサーバーでは、他のディストリビューションにsftpパッケージをインストールする必要があるかもしれません。
Ssh暗号化ファイルフラグ（id_rsa）と、非標準のsshポート1087を22の代わりに使用して、構文をいじる時間を安全にするもう1つの実用的な例：
sftp -P 1087 -i id_rsa user@server:/home/user/Downloads/Video/*/*.mp4 /home/user/Videos/
また、sftpは800kb/sまたは最大1 Mbit/sに制限される場合があります。これは次の方法で確認できます。
# sysctl -a | grep net.*rmem
制限を変更できます。彼らが遅すぎる場合はこのように：
# sysctl -w net.ipv4.tcp_rmem='40960 873800 62914560'
# sysctl -w net.core.rmem_max=8388608