サーバーからダウンロードしているのですが、FileZilla ではダウンロード速度が最大 1.3MiB/秒になりますが、同時ダウンロードを開始すると、ダウンロード速度も 1.3MiB/秒になります。では、1 つのファイルを 1.3MB/秒より速くダウンロードして、利用可能な帯域幅の飽和 (~6+MB/秒) に近づけることができないのはなぜでしょうか?
lftp などのセグメント化されたダウンロードをサポートする他の SFTP クライアントを使用できることはわかっていますが、オープン ソースの他の優れたクライアントを知っていますか?
しかし、1 つのファイルのダウンロード速度が 1.3 MB/秒に制限される理由がまだ知りたいです。TCP やバッファなどの技術的な制限なのか、それとも構成の問題なのか? 確認したところ、FileZilla ではトラフィック スロットリングがまったく有効になっていないことは確かです。
また、rsync も試してみましたが、FileZilla/SFTP よりも悪かったです。WinSCP も試してみましたが、SCP/SFTP のいずれの方法でも最も遅かったです。つまり、1.3MB/秒の一定転送速度の FileZilla は、他の転送方法と比べてかなり優れています。
転送速度が 1.3MB/秒でピークに達する理由について、またセグメント化されたダウンロードを使用せずに転送速度を上げることが可能かどうかについて、詳しい説明がある方がいらっしゃいましたら、ぜひ知りたいです。サーバーは OpenSSH 6.7p1 (Debian) を実行しており、クライアントは Windows 上の FileZilla です。
更新: Martin の情報 (以下の回答を参照) に応えて、ダウンロード中のサーバーとクライアント間の ping は 180 ミリ秒から 190 ミリ秒でほぼ一定であることを付け加えておきます。また、CPU 使用率は非常に低く、最大 2% から 8% です。最新バージョンの winscp 5.73 で試したところ、sftp モードで 555kb/s、scp モードで最大約 805kb/s でした。一方、Filezilla でセカンダリ同時転送を開始すると、これも 1.3MiB/s で一定になります。
では、Martin と Michael が少し触れたように、サーバーへの 180 ミリ秒の遅延は数学的な制限要因なのでしょうか? それとも、スループットを改善できるような他の原因があるのでしょうか? そうでない場合、安全でセグメント化されたダウンロードをサポートする他のオープン ソース ダウンローダー (lftp のようなものですが、Windows でも問題なく動作します) をご存知の方がいらっしゃいましたら、教えていただけると幸いです。
答え1
転送速度に影響を与える一般的な要因は 3 つあります。
帯域幅– 明らかにあなたの問題ではない明らかな要因。
ネットワーク遅延/レイテンシ– SFTP はパケット指向のプロトコルです。ダウンロード時に、SFTP クライアントは SFTP サーバーに「読み取り」要求を送信し、応答を待機し、返されたデータをローカル ファイルに追加し、ファイルの最後までこれを繰り返します。
接続が高速であっても、サーバーが遠い（または遅い）場合は、データが戻ってくるまでに時間がかかります。クライアントがこの時間を無駄に待機していると、転送速度が低下します。
ほとんどの SFTP クライアント (FileZilla および WinSCP を含む) は、各単一の「読み取り」要求でファイルの大きなチャンクを要求し、前の要求への応答を待たずに複数の「読み取り」要求を送信 (キューイング) することで、この問題を克服しています。たとえば、WinSCP は一度に最大 32 KB のチャンクを 32 個要求でき、合計 1 MB になります (これらはデフォルトです)。ただし、帯域幅とネットワーク遅延の間に大きな差異がある場合、その 1 MB でも帯域幅を飽和させるには小さすぎる可能性があります。
基盤となる TCP プロトコルも同様の問題に悩まされる可能性があります。したがって、実際の SFTP クライアントが効率的であるかどうかだけでなく、基盤となる TCP 層が効率的であるかどうかも重要です。
参照帯域幅遅延積Wikipediaで。
少なくとも、テストにWinSCPの最新バージョンを使用したのであれば、これは問題ではないと思います。いくつかの改善最近のリリースでは、WinSCP は FileZilla と同様に高遅延接続を効率的に利用できるようになりました。
CPU– SFTP は暗号化されているため、CPU を大量に消費します。帯域幅が大きいのに CPU が比較的遅い場合、CPU がネットワークの転送速度に合わせてデータを暗号化 (またはダウンロードの場合は復号化) できず、転送速度が制限される可能性があります。
一般的な SFTP クライアントは、CPU コア間で暗号化/復号化を分散できないため、実際には単一の CPU コアの容量が転送速度を制限します。
Windows タスク マネージャーを使用して、転送中にコアの 1 つが最大限に使用されているかどうかを確認します。
この回答の一部はWinSCPの記事から引用したものですファイル転送速度が非常に遅いです。WinSCP は利用可能な帯域幅をすべて利用していません。転送速度を向上させるにはどうすればよいですか?
答え2
私もこの問題を抱えていました。
タスクマネージャーを使用して優先度を高く設定しました。
今では5MiB/sまで到達しています
答え3
最近、まったく同じネットワークで Windows 10 とおそらく新しいバージョンの FileZilla を使用して試したところ、同じサーバーから最大 7MB/秒の転送速度が得られました。その後、仮想マシン内で RSYNC を使用してテストしたところ、やはり 7MB/秒が得られました。この Windows 7 システムにインストールした COMODO ファイアウォールに問題があることは、今では「ほぼ確実」です。
どうやら、これを「無効」にしても、ルールを強制するのではなく、ネットワーク スタックを遅くするだけのようです。この Windows 7 システムを仮想マシン内にインストール/複製したので、Comodo cis premium (ウイルス対策 + ファイアウォール) を完全に「削除」して、ここで確認してみます。また、このマシンでは、ネットワーク上の一部のシステムへの ping が不規則で断続的に遅延していることにも気付きました。その間にある他のすべてのシステムは 1 ミリ秒未満で安定していました。帯域幅遅延の製品情報は非常に良好ですが、私の場合は、別のインストール (同じネットワークのローカルとリモート) で、FileZilla と rsync の両方を 7MB/秒 (基本的に使用可能な帯域幅が飽和する) で取得できました。