WAN による scp 転送速度が遅くなります。

WAN による scp 転送速度が遅くなります。

私は300 mbitの対称ファイバーラインを持っており、ホストA(ファイバー300 mbit)からホストB(ギガビット帯域幅を超えるdigitaloceanシステム)に51MBYTEのtarファイルを転送する必要があります。

どちらもまともな速度テスト結果(Aの場合は300 mbit、Bの場合は700 mbit)を得ましたが、AからBIにscpを実行すると、次のような結果が得られます。

assets.tar            100%   51MB 220.3KB/s   03:55

最大速度はわずか220kbitです。

しかし、HOST BからAIでこれを行うと、非常に良い結果が得られます。

assets.tar            100%   51MB   8.4MB/s   00:06    ***REALLY GOOD SPEED***

何が問題なのでしょうか?

答え1

opensshまたは一部の派生製品を使用している場合は、sshdとsshのデフォルト値を確認してくださいIPQoS

IPQoSlowdelay throughputデフォルトは以前のバージョンでV_7_8_P1、その後次に変更されますaf21 cs1(最初のものは対話型セッションのためのTOSマークであり、2番目は一括転送のためのものです)。

WANパス(サプライヤのLAN内でも)では、CS1優先順位が非常に低く、SSHとの転送速度がscp非常にsftp低くなりますrsync。以前のデフォルトに戻すとIPQoS問題が解決しました。

詳細と変更の理由については、以下を参照してください。openssh コミット情報

openssh パッケージのバージョンに依存しないでください。一部のディストリビューションは、明らかに以前のデフォルト値を維持することを決定します。影響を受けるディストリビューションは、バージョン8から始まるすべてのRedhatベースのディストリビューション(CentOS、AlmaLinux、RockyLinuxなど)です。

sshd設定を確認してくださいsshd -T | grep -i IPQoS

テストするには試してくださいscp -o IPQoS=throughput …

以前のデフォルト設定に永久に復元するには:

  1. 次に追加/etc/ssh/sshd_config:

    IPQoS lowdelay throughput
    
  2. /etc/ssh/ssh_config次の基本または特定のホストルールを追加します。

    Host *
      IPQoS lowdelay throughput
    
  3. 新しい設定を有効にしますsystemctl reload sshd

YMMVは、実際のネットワークトポロジとポリシーに基づいてaf21対話型セッションに適しているため、さまざまなTOSタグをテストすることをお勧めします。

答え2

SCPは単にファイルを前後にコピーする非常にシンプルなツールです。超高速のために設計されておらず、両方のバッファが非常に小さいです。

目標がパフォーマンスの場合、sftpまたはを使用する必要がありますrsync

速度測定に関していくつかのグラフを描いてみましょう。

[host A]   --- ??? mbit  ---    [host B]
        \                      /
         \ 300 mbit           / 700 mbit
          \                  /
           [speedtest server]

2つのホスト間のデータは、速度を測定する速度テストサーバーを通過する必要がないため(おそらくそうではありません)、これらの測定はあなたの場合には関係ありません。これら2つのホスト間の速度を測定するには、これら2つのホスト間のトラフィックを測定するだけです。非対称またはさまざまな方法で制限されているいくつかの線がある可能性があります。

答え3

まず、最も愚かなTCPストリームの速度を測定します。 SFTPやFTPSではなく、通常のFTPが問題を解決します。何らかの理由でFTPが機能しない場合(ファイアウォールが問題である可能性がある)、netcatを試してください。

FTP は文字通りソケットにバイトを送信します。完全なTCPパケットサイズを使用し、単一のファイルについて話す限り、TCPはより効率的に使用できません。したがって、これは2つのホスト間で達成できる操作の基準を提供します。

(TCP ACKパケットを待たずにWANを介してより高速に実行できるUDPベースのプロトコルがいくつかありますが、これは一般的な標準ではありません。)

ただし、FTP は圧縮しないため、一部のデータ型では時間がかかる場合があります。これにより、生のTCPスループットを測定しようとする私たちの目標が容易になります。

FTPも遅いか非対称の場合、これらのシステム間のパスに非対称リンクがある可能性があります。両端でWiresharkスニファーを実行し、失われたパケット追跡などを確認して追加の診断を実行できます。

FTPが高速で対称的な場合、他の問題が発生します。あまり深く掘り下げずには推測しにくく、可能性も多いです。たとえば、あるコンピュータには圧縮用にSSHが設定されていますが、別のコンピュータにはそうでない場合があります。

関連情報