SFTPを介してファイルを転送すると、FTPより時間がかかるのはなぜですか？
ファイルを手動でサーバーにコピーし、同じファイルをSFTPサーバーに手動でコピーします。ファイルは140MBです。
FTP：約11MB/sのレートがあります
SFTP：約4.5MB/sのレートがあります
ファイルを送信する前に暗号化する必要があることを理解しています。ファイル転送への唯一の影響ですか？ （実際には、これは正確に転送時間ではなく、暗号化時間です）。
私はそのような結果に驚いています。
私はHPN-SSHの著者であり、ここにコメントする人から計量を依頼されました。まず、いくつかの背景項目から始めたいと思います。まず、SSHv2は多重化されたプロトコルであることに留意することが重要です-単一のTCP接続上の複数のチャネル。そのため、SSHチャネルは、TCPで使用される基本的なフロー制御アルゴリズムを本質的に認識していません。これは、SSHv2が独自のフロー制御アルゴリズムを実装する必要があることを意味します。最も一般的な実装は、基本的にスライディングウィンドウを再実装します。これは、TCPスライディングウィンドウの上にSSHスライディングウィンドウが乗っていることを意味します。最終的な結果として、受信バッファーの有効サイズは、2つのスライディングウィンドウの受信バッファーの最小値になります。 Stock OpenSSHの最大受信バッファサイズは2MBですが、これは実際には〜1.2MBに近くなります。最新のOSのほとんどは、4MBの有効サイズまで（自動チューニング受信バッファーを使用して）成長できるバッファーを備えています。なぜこれが重要なのですか？受信バッファーサイズが帯域幅遅延積（BDP）より小さい場合、システムの速度に関係なく、パイプを完全に満たすことはできません。
これは、SFTPがTCPおよびSSHフロー制御の上に別のフロー制御層を追加するという事実によって複雑になります。 SFTPは未処理のメッセージの概念を使用します。各メッセージは、コマンド、コマンドの結果、またはバルクデータフローです。未処理のメッセージは、特定のデータグラムサイズまで可能です。そのため、さらに別の受信バッファとして考えられるものになります。この受信バッファのサイズは、データグラムサイズ*最大未処理メッセージ（両方ともコマンドラインで設定可能）です。デフォルトは32k * 64（2MB）です。したがって、SFTPを使用するときは、TCP受信バッファー、SSH受信バッファー、およびSFTP受信バッファーがすべて十分なサイズであることを確認する必要があります（大きすぎたり、インタラクティブで過剰なバッファリングの問題が発生したりすることはありません）セッション）。
HPN-SSHは、最大16MB程度の最大バッファーサイズを持つことで、SSHバッファーの問題に直接対処します。さらに重要なことは、TCP接続のバッファーサイズ（基本的にレイヤー3と4の間に穴を開ける）のprocエントリーをポーリングすることにより、バッファーが適切なサイズに動的に拡大することです。これにより、ほとんどすべての状況でオーバーバッファリングが回避されます。 SFTPでは、未処理の要求の最大数を256に増やします。少なくともそれを行う必要があります-6.3パッチセットに期待どおりに変更が反映されなかったようです（6.2ですが、すぐに修正します） ）。 6.3が6.4（6.3からの1行のセキュリティ修正）に対してきれいにパッチを適用するため、6.4バージョンはありません。 sourceforgeからパッチセットを入手できます。
これは奇妙に聞こえるかもしれませんが、パフォーマンスの面で最も重要な変更はバッファの正しいサイズ変更でした。多くの人が暗号化はnotであると考えているにもかかわらず、ほとんどの場合、パフォーマンスの低下の本当の原因です。 （RTTの観点から）ますます遠くにあるソースにデータを転送することで、これを自分で証明できます。 RTTが長くなるほど、スループットが低下することがわかります。これは、これがRTTに依存するパフォーマンスの問題であることを明確に示しています。
とにかく、この変更により、最大2桁の改善が見られるようになりました。 TCPを理解すれば、なぜこれがそのような違いをもたらしたのか理解できます。データグラムのサイズやパケット数などではありません。ネットワークパスを効率的に使用するために、mustは2つのホスト間で転送できるデータ量に等しい受信バッファーを持っているためです。これは、パスが十分に高速でなく、十分な長さでない場合、改善が見られないことも意味します。 BDPが1.2MB未満の場合、HPN-SSHは価値がない可能性があります。
並列化されたAES-CTR暗号は、完全な暗号化をエンドツーエンドで行う必要がある場合に、複数のコアを持つシステムのパフォーマンスを向上させます。ほとんどのデータはそれほど機密ではないため、通常は、人々（またはサーバーとクライアントの両方を制御できる）にNONE暗号スイッチ（暗号化認証、クリアで渡されるバルクデータ）を使用することをお勧めします。ただし、これはSCPのような非対話型セッションでのみ機能します。 SFTPでは機能しません。
他にもいくつかのパフォーマンスの改善がありますが、バッファの適切なサイジングと暗号化の作業ほど重要なものはありません。空き時間ができたら、おそらくHMACプロセスをパイプライン処理し（現在、パフォーマンスに最も大きな影響を与えています）、さらにいくつかのマイナーな最適化作業を行います。
では、HPN-SSHが非常に優れているのに、なぜOpenSSHがHPN-SSHを採用していないのでしょうか？それは長い話であり、OpenBSDチームを知っている人はおそらくすでに答えを知っています。私は彼らの理由の多くを理解しています-それは彼らの終わりに追加の作業を必要とする大きなパッチであり（そして彼らは小さなチームです）、彼らはセキュリティほどパフォーマンスを気にしません（HPN-SSHにセキュリティの影響はありませんが） ）、などなど。ただし、OpenSSHはHPN-SSHを使用しませんが、Facebookは使用します。 Google、Yahoo、Apple、最も大規模な研究データセンター、NASA、NOAA、政府、軍、およびほとんどの金融機関も同様です。この時点では十分に吟味されています。
誰か質問がある場合はお気軽に質問してください。ただし、このフォーラムの最新情報を入手できない場合があります。 HPN-SSHメールアドレス（google it）経由でいつでもメールを送信できます。
UPDATE：コメント者が指摘したように、以下に概説する問題はこの投稿の前に修正されました。しかし、私はHP-SSHプロジェクトを知っていたので、著者に計量を依頼しました。彼らが（正当に）最も賛成の答えで説明しているように、暗号化はnot問題の原因。電子メールと私よりも賢い人々に賛成です！
うわー、間違った答えしかなかった1年前の質問。ただし、同じ質問を自分で行ったときに、速度低下は暗号化によるものだと考えていたことを認めなければなりません。しかし、次の論理的な質問を自問してみてください。コンピューターはどれくらい速くデータを暗号化および解読できますか？そのレートがOPによって報告される4.5Mb /秒（0.5625MBsまたはおよそhalf5.5 "フロッピーディスクの容量に近いと思われる場合！ ）数回自分自身を叩いて、コーヒーを飲み、同じ質問をもう一度します。
それは明らかに、パケットサイズの選択における見落としになる量と関係があるか、少なくともそれがそうである LIBSSH2の著者は言う 、
SFTPの性質と、送信するすべての小さなデータチャンクに対するACKにより、遅延の大きいネットワークを介してデータを送信する場合、初期の単純なSFTP実装はひどく苦しみます。 32KBのデータごとに数百ミリ秒待機する必要がある場合、高速SFTP転送は決してありません。この種の単純な実装は、libssh2 1.2.7まで、libssh2が提供してきたものです。
したがって、速度の低下は、小さなパケットサイズx各パケットの必須のack応答によるものであり、明らかに異常です。
高性能SSH/SCP（HP-SSH） プロジェクトは、暗号化の並列化と同様に内部バッファを明らかに改善するOpenSSHパッチセットを提供します。ただし、並列化されていないバージョンでも、一部のコメンターが取得した40Mb/sの暗号化されていない速度を超えて実行されていました。この修正では、暗号ではなくOpenSSHが暗号化ライブラリを呼び出す方法を変更する必要があり、AES128とAES256の速度に差はありません。暗号化にはいくらかの時間がかかりますが、わずかです。それは90年代に問題になったかもしれませんが、（Java対Cの速度のように）もはや重要ではありません。
SFTP転送の速度にはいくつかの要因が影響します。
- 暗号化。対称暗号化は高速ですが、気付かれることはそれほど高速ではありません。高速ネットワーク（100メガビット以上）で速度を比較すると、暗号化はプロセスの中断になります。
- ハッシュ計算とチェック。
- バッファコピー。 SSHの上で実行されるSFTPは、データをコピーせずにネットワークインターフェースに渡すことができるプレーンFTPと比較して、各データブロックを少なくとも6回（各側に3回）コピーします。また、ブロックコピーにも少し時間がかかります。
結果は理にかなっています。 FTPは暗号化されていないチャネル上で動作するため、SFTP（SSHバージョン2プロトコルのサブシステム）よりも高速です。また、SFTPはコマンドベースのFTPとは異なり、パケットベースのプロトコルであることを忘れないでください。
SFTPの各パケットは、クライアントから発信ソケットに書き込まれる前に暗号化され、その後サーバーで受信されると解読されます。これにより、転送速度は遅くなりますが、転送は非常に安全です。 SFTPでzlibなどの圧縮を使用すると、転送時間は改善されますが、プレーンテキストFTPの近くにはありません。おそらくより良い比較は、両方とも暗号化を使用するSFTPとFTPSを比較することですか？
SFTPの速度は、暗号化/復号化に使用される暗号、使用される圧縮に依存します。ソケット接続に使用されるzlib、パケットサイズ、およびバッファサイズ。
暗号化にはCPUだけでなく、ネットワークオーバーヘッドもあります。
比較のため、Raring Ringtail Ubuntu alpha 2 live cdを実行しているi5ラップトップから299GB ntfsディスクイメージをUbuntu 12.04.1を実行しているi7デスクトップに転送してみました。報告された速度：
wiFi +電力線経由：scp：5MB /秒（40 Mbit /秒）
ギガビットイーサネット+ネットギアG5608 v3経由：
scp：44MB /秒
sftp：47MB /秒
sftp -C：13MB /秒
したがって、優れたギガビットリンクでは、sftpはscpよりもわずかに高速であり、2010年時代の高速CPUは暗号化するのに十分に高速であるように見えますが、すべての場合に圧縮が勝つわけではありません。
ただし、不良なギガビットイーサネットリンクでは、sftpがscpよりはるかに優れています。 scpが非常におしゃべりであることについては、2008年のcomp.security.sshで「scp UNBELIEVABLY slow」を参照してください。 https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/ldPV3msFFQwhttp://fixunix.com/ssh/368694-scp-unbelievably-slow.html
これを行うことができるすべての種類があります。 1つの可能性は「トラフィックシェーピング」です。これは一般に、ビジネスクリティカルなアクティビティのために帯域幅を確保するためにオフィス環境で行われます。同様の理由で、Webホスティング会社またはISPによって実行される場合もあります。
自宅で簡単にセットアップすることもできます。
たとえば、FTPの最小帯域幅を予約するルールがありますが、SFTPは「その他すべて」のルールに該当する場合があります。または、SFTPの帯域幅を制限するルールがあるかもしれませんが、他の誰かがあなたと同時にSFTPを使用しています。
だから：どこからファイルを転送していますか？
SFTPはSSHを介したFTPではなく、異なるプロトコルであり、SCPに類似しており、より多くの 機能 を提供します。