利用可能な帯域幅を飽和させるのではなく、FileZilla SFTPファイル転送の上限が1.3MiB /秒になっているのはなぜですか？ rsyncとWinSCPはさらに遅い
サーバーからダウンロードしています。FileZillaを使用すると、ダウンロードが最大で1.3 MiB /秒に達しますが、同時ダウンロードを開始でき、1.3 MiB /秒でダウンロードされます。それでは、なぜ1つのファイルを1.3MB/sより速い速度でダウンロードして、飽和状態の利用可能な帯域幅（〜6 + MB/s）に近づけないのでしょうか。
Lftpなどのセグメント化されたダウンロードをサポートする他のSFTPクライアントを使用できることは知っていますが、オープンソースの他の優れたものを知っていますか？
しかし、私はまだ1つのファイルのダウンロードを1.3MB/sに制限しているのは何であるか知りたいのですが、それはTCPとバッファーなどの技術的な制限、またはいくつかの構成の問題ですか？ FileZillaで有効になっているトラフィック調整はまったくありません。
また、rsyncを試しましたが、FileZilla/SFTPよりも悪かったです。 WinSCPも試しましたが、SCP/SFTPの方法に関係なく、最も低速でした。したがって、1.3MB/sの一定の転送で、FileZillaは他の転送方法と比べてかなり良いです。
誰かが1.3MB/sで転送がピークになる理由についての良い説明があれば、私は本当に知りたいのですが、セグメント化されたダウンロードを使用せずにこれを増やすことができれば。サーバーはOpenSSH 6.7p1（Debian）クライアントを実行しています。WindowsではFileZillaです。
更新：マーティンの情報（以下の彼の回答を参照）に応じて、サーバーとクライアントの間でpingが180ミリ秒から190ミリ秒の間かなり一定であることを追加しています。また、CPU使用率は非常に低く、最大2％から8％です。最新バージョンのwinscp 5.73で試してみました。sftpモードでは、scpモードで555kb/s、最大約805kb/sを取得しました。一方、Filezillaで二次同時転送を開始すると、1.3MiB/sも一定になります。
では、マーティンとマイケルが少し触れたように、サーバーへの180ミリ秒の遅延は数学的に制限要因になるのでしょうか？それとも、スループットを向上させるために他に何か問題があるのでしょうか？そうでない場合は、安全でセグメント化されたダウンロードをサポートする他のオープンソースダウンローダー（lftpのようにWindowsで適切に動作する）を知っている人がいれば幸いです。
転送速度に影響を与える3つの一般的な要因があります。
Bandwidth–明らかにあなたの問題ではない明らかな要因。
ネットワーク遅延/遅延– SFTPはパケット指向プロトコルです。ダウンロード時に、SFTPクライアントは「読み取り」リクエストをSFTPサーバーに送信し、応答を待ち、返されたデータをローカルファイルに追加します。そして、ファイルの終わりまで繰り返します。
接続が速い場合でも、サーバーが遠い（または遅い）場合は、データが戻るまでに時間がかかります。クライアントがこの時間を無駄に待機していると、転送速度が遅くなります。
ほとんどのSFTPクライアント（FileZillaやWinSCPを含む）は、単一の「読み取り」要求ごとにファイルの大きなチャンクを要求することと、以前の応答を待たずに複数の「読み取り」要求を送信（キューイング）することの両方によって問題を克服します。たとえば、WinSCPは一度に最大32個のチャンクを32 KBずつ要求でき、合計1 MBになります（これらはデフォルトです）。ただし、帯域幅とネットワーク遅延の間に大きな不一致がある場合、その1 MBでも帯域幅を飽和させるには小さすぎる可能性があります。
基礎となるTCPプロトコルは同様の問題を引き起こす可能性があります。そのため、実際のSFTPクライアントの効率だけでなく、基礎となるTCPレイヤーの効率も高くなります。
Wikipediaの Bandwidth-delay product も参照してください。
少なくともテストに最新バージョンのWinSCPを使用している場合は、これも問題ではないと思います。最近のリリースでは いくつかの改善点 があり、WinSCPはFileZillaと同じくらい効率的に高遅延接続を利用できます。
[〜＃〜] cpu [〜＃〜]– SFTPは暗号化されているため、CPUに負荷がかかります。大きな帯域幅と比較して比較的遅いCPUを使用している場合、ネットワークがデータを転送できる限りの速さでデータを暗号化（またはダウンロードの場合は復号化）できないCPUによって、転送が制限されることがあります。
一般的なSFTPクライアントは暗号化/復号化をCPUコア間で分散できないため、実際には転送速度を制限するのは単一のCPUコアの容量です。
Windowsタスクマネージャーを使用して、コアの1つが転送中に最大限に利用されているかどうかを確認します。
この回答の一部はWinSCPの記事に由来します ファイル転送速度が非常に遅い。WinSCPはすべての利用可能な帯域幅を利用していません。転送速度を改善するにはどうすればよいですか？
私にもこの問題がありました。
タスクマネージャーを使用して優先度を高に設定しました。
今では最大5 MiB /秒
私は最近、windows 10とおそらくより新しいバージョンのfilezillaを使用して、まったく同じネットワークを試しましたが、同じサーバーから最大7MB /秒の転送を得ました！次に、仮想マシン内でRSYNCを使用してテストし、7MB /秒も取得しました。問題はこのWindows 7システムにインストールしたCOMODOファイアウォールにあるので、「かなり確信しています」。
どうやらそれを「無効」にしても、ルールを強制するだけではなく、ネットワークスタックの速度が低下するようです。このWindows 7システムを仮想マシン内にインストール/複製したので、Comodo cisプレミアム（アンチウイルス+ファイアウォール）を完全に「削除」して、ここで確認します。このマシンについても言及する必要があります。また、ネットワーク上の他のすべてのシステムが1ミリ秒未満で安定していた一部のシステムへの不安定な断続的なレイテンシのpingにも気付きました。したがって、帯域幅遅延の製品情報は非常に優れていますが、私の場合、同じネットワークローカルとリモートの別のインストールで、7 MB /秒（基本的に使用可能な帯域幅を飽和させます）でfilezillaとrsyncの両方を取得できました。