☰

WAN을 통한 scp 전송 속도가 느립니다.

tag-icon • tag-icon networking performance scp
WAN을 통한 scp 전송 속도가 느립니다.

나는 300mbit 대칭 파이버 라인을 가지고 있으며 호스트 A(파이버 300mbit)에서 호스트 B(기가비트 대역폭이 넘는 digitalocean 시스템)로 51MBYTE tar 파일을 전송해야 합니다.

양쪽 모두 괜찮은 속도 테스트 결과(A의 경우 300mbit, B의 경우 700mbit)를 얻었지만 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 표시이고, 두 번째는 대량 전송을 위한 것입니다).

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]

두 호스트 간의 데이터는 속도를 측정하는 속도 테스트 서버를 통과할 필요가 없으므로(아마도 그렇지 않을 것입니다) 이러한 측정은 귀하의 경우에는 관련이 없습니다. 이 두 호스트 사이의 속도를 측정하려면 이 두 호스트 사이의 트래픽만 측정하면 됩니다. 비대칭이거나 다양한 방식으로 제한되는 일부 선이 있을 수 있습니다.

답변3

먼저 가장 어리석은 TCP 스트림의 속도를 측정하겠습니다. SFTP나 FTPS가 아닌 일반 FTP가 문제를 해결합니다. 어떤 이유로 FTP가 작동하지 않는 경우(방화벽이 문제일 수 있음) netcat을 사용해 보세요.

FTP는 문자 그대로 소켓에 바이트를 보냅니다. 전체 TCP 패킷 크기를 사용하고 단일 파일에 대해 이야기하는 한 TCP를 더 효율적으로 사용할 수 없습니다. 따라서 이는 두 호스트 간에 달성할 수 있는 작업에 대한 기준을 제공합니다.

(TCP ACK 패킷을 기다리지 않고 WAN을 통해 더 빠르게 실행할 수 있는 일부 UDP 기반 프로토콜이 있지만 이는 일반적인 표준은 아닙니다.)

그러나 FTP는 압축하지 않으므로 일부 데이터 유형의 경우 시간이 더 오래 걸릴 수 있습니다. 이는 원시 TCP 처리량을 측정하려는 우리의 목표를 용이하게 합니다.

FTP도 느리거나 비대칭인 경우 이러한 시스템 간의 경로에 비대칭 링크가 있을 수 있습니다. 양쪽 끝에서 Wireshark 스니퍼를 실행하고 손실된 패킷 추적 등을 확인하여 추가 진단을 수행할 수 있습니다.

FTP가 빠르고 대칭적이라면 다른 문제가 발생하게 됩니다. 너무 깊게 파고들지 않고서는 추측하기 어렵고, 가능성도 많습니다. 예를 들어 한 컴퓨터에는 압축을 위해 SSH가 구성되어 있지만 다른 컴퓨터에는 그렇지 않을 수 있습니다.

관련 정보