高速な広域ネットワークを使用している場合、sftpとscpはほぼ同じ速度であり、低速です。どちらも、基礎となるopensshのパフォーマンスの問題に悩まされています。最新のハードウェアでは、これは暗号化のオーバーヘッドによるものではなく、openssh実装の問題によるものです。高速接続で機能しない独自の内部ウィンドウメカニズムを実装しています。
これらの問題は、長距離（レイテンシが長い）接続でより明白になりますが、LANでも低速が発生しました。
これらは十分に文書化されており、問題を修正するためのパッチが利用可能です。接続のいずれかの端にパッチを適用すると役立ちます。理想的には、両端にパッチを適用します。詳細とパッチについては、ピッツバーグスーパーコンピューターセンターの High Performance SSH を参照してください。
ところで、ウィンドウ処理の問題が解決されると、暗号化のオーバーヘッドも問題になる可能性があります。パッチにもその修正があります。
その間、あなたはftpがひどく安全でないことに気付くでしょう。パスワードをプレーンテキストで送信します。
ftps FTPプロトコルをSSLでラップすると思います。パッチを適用していないSFTP/SCPよりもおそらく高速です。
最後の注意点：私の経験では、WinSCPクライアントは（少なくともときどき）痛々しく遅いです。理由はわかりませんが、FAQに基づいて、この問題が発生したのは私だけではありません。Windowsからscpを実行していて、遅いと思われる場合は、別のクライアントです。パッチを当てていないopensshサーバーを使用しても、別のクライアントで多くのことを実行できます。残念ながら、どのクライアントが優れているかわかりません。
一般に、すべてのプロトコルはほぼ同じように動作します。プロトコルよりもネットワークまたはディスクの速度によって制限される可能性が高くなります。
古いバージョンのOpenSSH（SFTP/SCP）は、高レイテンシネットワーク（大西洋横断など）で速度を制限する固定ウィンドウサイズを使用していました。 HPN（ハイパフォーマンスネットワーキング）と呼ばれるこの問題を修正するためのパッチセットがあり、OpenSSHの最新のインストールに含まれています。
ギガビット以上のLANリンクや遅いCPUなどの状況で実行している場合、SFTP/SCPがボトルネックになる可能性があります。 ssh/scp/sftpプロセスが送信または受信ホスティングでCPUの100％を使用しているため、これを知ることができます。 OpenSSHの新しいバージョン（6.4以降）を使用している場合、AES暗号のスレッドバージョンを有効にできます。これにより、複数のコアを使用して暗号化を処理でき、ディスクではなくCPUによって制限される可能性が低くなります。またはネットワーク帯域幅。
送信側と受信側の両方を制御する場合、OpenSSH 6+にはオプションの「NONECIPHER」モードもあります。これは通常の暗号化/キーなどを使用してリモートマシンにログインしますが、実際のファイルコピーでは暗号化されていない接続にドロップします。これにより、CPUのオーバーヘッドが解消されます。暗号化されていないシェルを取得できないようにするために、NONECIPHERに組み込まれている保護手段があります。
最終的に、プロトコルは速度の制限となるべきではありませんが、古いバージョンのsshは、待ち時間の長いリンクでは問題を抱えています。
暗号化のオーバーヘッドに基づくと、プレーンFTPのパフォーマンスは他のプロトコルよりもわずかに優れていると思いますが、それはごくわずかです。最初に必要なセキュリティを提供するプロトコルを使用し、次にスループットについて心配します。
そうは言っても、実数を見つけるためのテストを設定する必要があります。上記はすべて私の意見です。ローカルでパフォーマンスをテストする場合は、ネットワーク上にサーバーをセットアップします。最終用途がインターネット経由の場合は、外部ホストからテストします。
いつものように、グーグルは答えを保持しています、
FTP v/s SFTP v/s FTPS
FTP> FTPS> SFTP
他の誰かのテストでは、FTPはSCPよりも高速であるように見えます（ http://www.lysesoft.com/support/forums/viewtopic.php?f=5&t=542 ）が、自分で試してみることをお勧めします。
ネットワーク上の任意のボックスにSCPとFTPをセットアップし、通常のファイル転送を実行して、両方にかかる時間を確認します