高遅延ネットワークでのSFTPアップロードを高速化しますか？
大きなファイルのセットをSFTPを使用して国際的に転送しようとしていますが、どちらの側でも非常に良好な接続があるにもかかわらず、国際パートナーが最大50kを超えるアップロード速度を取得できないことがわかりました。この速度（帯域幅ではない？）で複数の接続をアップロードできますが、単一のアップロードで速度が向上することはありません。これは、多くのファイルのサイズが数GBであるため問題です。
SFTPは、標準のApple OSX "Remote Login" SFTPシステムを使用してホストされています。
アップロード速度を改善する方法はありますか、それとも役立つ別のSFTPホストはありますか？これが構成の問題なのか、プロトコルの固有の制限なのかは、私にはわかりません。
（セキュリティ上の理由から、エンドツーエンドの暗号化されたピアツーピア接続を使用する必要があります-クラウドサービスはありません）。
OpenSSH sftp client （使用しているように見える）を使用すると、以下を使用できます。
まず、両方を2倍にしてみます。
sftp -R 128 -B 65536 user@Host
どちらを増やすかは、おそらくそれほど重要ではありません。
どちらかを増やすと、高遅延接続が飽和するのに役立ちます。上記の設定を使用すると、いつでも8 MB相当のデータがパイプを流れるようになります（128 * 64K = 8M）。
これは大きなファイルの転送にのみ役立つことに注意してください。多数の小さなファイルを転送する場合、効果はありません。
他の（GUI）SFTPクライアントの背景と説明については、私の回答の「ネットワーク遅延/待機時間」セクションを参照してください 利用可能な帯域幅を飽和させるのではなく、FileZilla SFTPファイル転送の上限が1.3MiB /秒になっているのはなぜですか？ rsyncとWinSCPはさらに遅くなります 。
大きなファイルのセットをSFTPを使用して国際的に転送しようとしています
まだ回答としては言及されていませんが、待ち時間の長いリンクを介して複数のファイルを転送する場合、パフォーマンスを向上させるための本当に簡単な解決策が1つあります。
複数のファイルを並行して転送します。
そして、はあなたの質問でさえ言及した解決策です。これを使って。
基本的に、TCPプロトコルは、大きな帯域幅遅延製品との接続を適切に処理しません。単一の接続では、十分なデータの移動を維持できません。詳細は httpsを参照してください。 ：//en.wikipedia.org/wiki/TCP_tuning
各接続はTCPプロトコルによって制限されるため、より多くの接続を使用してください。
圧縮を有効にして、それが役立つかどうかを確認できます。
man sftp：
-C圧縮を有効にします（sshの-Cフラグを使用）。
そしてman ssh：
-Cすべてのデータ（stdin、stdout、stderr、および転送されたX11のデータを含む）の圧縮を要求しますTCPおよびUNIXドメイン接続）圧縮アルゴリズムはgzip（1）で使用されるものと同じです、および「レベル」は、プロトコルバージョン1のCompressionLevelオプションで制御できます。圧縮は、モデム回線やその他の低速接続では望ましいですが、高速ネットワークでは速度が低下するだけです。デフォルト値はHost-by -構成ファイルでのホストの基礎。圧縮オプションを参照してください。
それはむしろ、パスに沿ったある時点で接続がレート制限されているように聞こえます（または、接続あたり50kB/sの最も単純な説明のように思えますが、複数のそのような接続が可能です）。どちらかの側のディスクが要因ではないことを確認するのは悪い考えです。
クイックpcapを実行して、「明らかな」問題（多数の再送信など）があるかどうかを確認することもできますが、ある程度の確信が持てない場合は、これに対処できるかどうか、圧縮を有効にするかどうかを確認します。助けて。
（質問のタイトルには「高レイテンシ」と記載されていますが、本文にはありません。実際のレイテンシを測定しましたか。結果はどうですか？）
高遅延ネットワークリンクのスループットを明示的に改善するOpenSSHへのパッチがあります。 HPN-SSH ：（私の強調）
OpenSSHでのSCPおよび基になるSSH2プロトコルの実装は、静的に定義された内部フロー制御バッファーによってネットワークパフォーマンスが制限されます。これらのバッファーは、SCPのネットワークスループットのボトルネックとして機能することが多く、特に帯域幅の長いネットワークリンクではそうです。実行時にバッファーを定義できるようにsshコードを変更すると、このボトルネックが解消されます。 OpenSSHのボトルネックを解消し、他のサーバーやクライアントと完全に相互運用可能なパッチを作成しました。 さらに、HPNクライアントは非HPNサーバーからより速くダウンロードでき、HPNサーバーは非HPNクライアントからより速くアップロードを受信できます。
したがって、受信側でHPN-SSHをコンパイルして使用し、転送速度が向上するかどうかを確認してください。
sftp転送を高速化します
あなたの問題がTCP接続ごとのネットワークチューニングおよび/またはスロットリングであると仮定すると、lftpミラーサブシステムを使用したsftp
両端のネットワークチューニングははるかに大きなトピックであり、多くのやり取りが必要になるため、ServerFaultの範囲外にトピックが押し出されます。個々の接続では、iwaseatenbyagrueで言及されている圧縮がどちらの方法でも役立つ場合があります。これは、リモートエンドが圧縮を許可していることを前提としています。
これが選択肢であるかどうかはわかりませんが、データをプルするか、国際サイトにプッシュすることを試みましたか？同様に、ネットワークリソースの競合に関する問題かどうかを確認するために、さまざまなタイミングで確認します。
この速度でアップロードする複数の接続を取得できます（帯域幅ではないのですか？）
故意に（追加のプロビジョニングを行うことなくサービスをアップセルする方法として）、または偶然に（たとえば、壊れた ウィンドウスケーリング または熱狂的なトラフィック制御）、構成の問題のように聞こえます。転送を並列化することはできますが、接続の反対側に何があるのか、またはファイルのシャーディング/再構成を処理する簡単なスクリプトを開発する価値があるかどうかについては何も説明していません。
原因がvery正しく記述されていないソフトウェア（およびopenSSHがこのカテゴリに含まれない-でない限り）でない限り、キューサイズと圧縮のチューニングは大きな影響を与える可能性は低い待ち時間が250ミリ秒を超えない限り、より長いリクエストキュー/大きなブロックサイズでopensshを使用することの多くのポイントサーバーの問題を除外するために、異なる場所の異なるクライアントを試すことを検討してください。
私の最初の電話は、問題の原因となっているプロバイダーを特定し、問題を修正するか、別のプロバイダーに切り替えるよう依頼することです。