高遅延ネットワークでのSFTPアップロードを高速化しますか？

SFTPを使用して一連の大きなファイルを国際的に転送しようとしていますが、どちらの側も非常に良好な接続にもかかわらず、国際パートナーがアップロード速度を〜50kを超えることができないことに気付きました。この速度で複数の接続をアップロードできます（帯域幅ではないのですか？）が、単一のアップロードでは速度が向上しません。これは、多くのファイルが数ギガバイトのサイズであるため問題です。

SFTPは、標準のApple OSX「リモートログイン」SFTPシステムを使用してホストされています。

アップロード速度を改善する方法はありますか、それとも役立つ別のSFTPホストがありますか？これが設定の問題なのか、それともプロトコルの固有の制限なのかははっきりしていません。

（セキュリティ上の理由から、エンドツーエンドの暗号化されたピアツーピア接続を使用する必要があります-クラウドサービスはありません）。

OpenSSH sftpクライアント（あなたが使用するようだ）、あなたが使用することができます。

• -Rリクエストキューの長さを増やすスイッチ（デフォルトは64）
• -B読み取り/書き込み要求サイズを増やすように切り替えます（デフォルトは32 KB）

まず、両方を2倍にしてみてください：

sftp -R 128 -B 65536 user@host

おそらく大した問題ではなく、どれを増やすかです。

いずれかを増やすと、待ち時間の長い接続が飽和状態になります。上記の設定を使用すると、8 MBのデータがいつでもパイプに流れ続けます（128 * 64K = 8M）。

これは、大きなファイルの転送にのみ役立つことに注意してください。大量の小さなファイルを転送する場合、効果はありません。

いくつかの背景と他の（GUI）SFTPクライアントに関する説明については、FileZilla SFTPファイル転送の上限が利用可能な帯域幅を飽和させるのではなく1.3MiB /秒である理由に対する「ネットワーク遅延/遅延」セクションを参照してください。rsyncとWinSCPはさらに遅いです。

圧縮を有効にしてみて、それが役立つかどうかを確認できます。

からman sftp：

-C 圧縮を有効にします（sshの-Cフラグを使用）。

そしてからman ssh：

-C すべてのデータ（stdin、stdout、stderr、および転送されたX11、TCP、およびUNIXドメイン接続のデータを含む）の圧縮を要求します。圧縮アルゴリズムはgzip（1）で使用されるものと同じであり、「レベル」はプロトコルバージョン1のCompressionLevelオプションで制御できます。圧縮はモデム回線やその他の低速接続で望ましいが、高速ネットワークでは遅くなります。デフォルト値は、構成ファイルでホストごとに設定できます。圧縮オプションを参照してください。

それはむしろ、接続がそのパスに沿ったある点でレート制限されているように聞こえます（または、むしろ、接続ごとに50kB / sの最も簡単な説明のようですが、複数のそのような接続が可能です）どちらかの側のディスクが要因ではないことを確認するのは悪い考えです。

また、簡単なpcapを実行して「明白な」問題（多数の再送信など）があるかどうかを確認することもできますが、自信がない限りこれに対処できるかどうか、おそらく圧縮を有効にするとどうなるかがわかります助けて。

SFTPを使用して一連の大きなファイルを国際的に転送しようとしています

回答としてはまだ言及されていませんが、高遅延リンクを介して複数のファイルを転送する場合、パフォーマンスを向上させるための本当に簡単な解決策が1つあります。

複数のファイルを並行して転送します。

そしてそれ はあなたがあなたの質問でも言及した解決策です。これを使って。

基本的に、TCPプロトコルは、大きな帯域幅遅延製品との接続を非常にうまく処理しません。1つの接続では、一度に十分なデータを移動できません。見るhttps://en.wikipedia.org/wiki/TCP_tuningをください

以来、各接続は TCPプロトコルによって制限され、ちょうどより多くの接続を使用します。

sftp転送を高速化する

問題がTCP接続ごとのネットワークチューニングおよび/または調整であると仮定して、 て、lftpミラーサブシステムを使用 sftpを

両端でのネットワークチューニングははるかに大きなトピックであり、多くのやり取りが必要になるため、トピックはServerFaultの範囲外になります。個々の接続については、iwaseatenbyagrueが言及した圧縮がどちらの方法でも役立つ場合があります。これは、リモートエンドが圧縮を許可していることを前提としています。

（質問のタイトルには「高レイテンシ」と記載していますが、本文には記載していません。実際のレイテンシを測定しましたか？結果は何ですか？）

高遅延ネットワークリンクのスループットを明示的に改善するOpenSSHのパッチがあります：HPN-SSH：（emphasis mine）

SCPとOpenSSHの基盤となるSSH2プロトコルの実装は、静的に定義された内部フロー制御バッファーによって制限されるネットワークパフォーマンスです。これらのバッファは、特に長くて高い帯域幅のネットワークリンクで、SCPのネットワークスループットのボトルネックとして機能することがよくあります。実行時にバッファを定義できるようにsshコードを変更すると、このボトルネックが解消されます。OpenSSHのボトルネックを解消し、他のサーバーやクライアントと完全に相互運用できるパッチを作成しました。さらに、HPNクライアントはHPN以外のサーバーからより高速にダウンロードでき、HPNサーバーはHPN以外のクライアントからより高速にアップロードを受信できます。

そのため、受信側でHPN-SSHをコンパイルして使用し、転送速度が向上するかどうかを確認してください。

これがあなたのためのオプションであるかどうかはわかりませんが、データを国際的なサイトにプルするかプッシュすることを試みましたか？ネットワークリソースの競合の問題があるかどうかを確認するために、さまざまなタイミングで同様に。

この速度で複数の接続をアップロードできます（帯域幅ではありませんか？）

それは設定の問題のように聞こえます-故意に（追加のプロビジョニングを行わずにサービスをアップセルする方法として）または偶然に（たとえば、ウィンドウのスケーリングが壊れている）や過度なトラフィック制御）。転送を並列化することはできますが、接続のもう一方の端について、またはファイルのシャーディング/再構成を処理する簡単なスクリプトを開発する価値があるかどうかについては何も話しませんでした。

キューサイズと圧縮の調整は、原因が非常に不適切なソフトウェアである場合を除き、重大な影響を与えることはほとんどありません（また、openSSHはこのカテゴリに該当しません-レイテンシがなければサーバーの問題を除外するために、さまざまな場所のさまざまなクライアントを試すことを検討することができます。

私の最初の呼び出しは、問題の原因となっているプロバイダーを特定し、問題を修正するか、別のプロバイダーに切り替えるよう依頼することです。