대기 시간이 긴 네트워크에서 SFTP 업로드 속도를 높이시겠습니까?

SFTP를 사용하여 국제적으로 대용량 파일 세트를 전송하려고하는데 국제 파트너가 양쪽의 연결 상태가 양호하더라도 ~ 50k 이상의 업로드 속도를 얻을 수 없다는 것을 알았습니다. 이 속도 (대역폭이 아님)로 여러 개의 연결을 업로드 할 수 있지만 단일 업로드로 속도가 향상되지는 않습니다. 이는 파일 크기가 몇 GB 인 많은 문제입니다.

SFTP는 표준 Apple OSX "원격 로그인"SFTP 시스템을 사용하여 호스팅됩니다.

업로드 속도를 향상시킬 수있는 방법이 있습니까, 아니면 다른 SFTP 호스트가 도움이됩니까? 이것이 구성 문제인지 아니면 프로토콜의 고유 한 제한인지는 확실하지 않습니다.

(보안상의 이유로 클라우드 서비스가없는 종단 간 암호화 된 피어 투 피어 연결을 사용해야합니다.)

함께 오픈 SSH sftp클라이언트 (당신이 사용하는 것), 당신은 사용할 수 있습니다 :

• -R요청 큐 길이를 늘리려면 전환하십시오 (기본값은 64).
• -B읽기 / 쓰기 요청 크기를 늘리려면 전환 (기본값은 32KB)

시작하려면 두 가지를 모두 두 번 시도하십시오.

sftp -R 128 -B 65536 user@host

그것은 중요하지 않을 것입니다.

둘 중 하나를 늘리면 대기 시간이 긴 연결을 포화시키는 데 도움이됩니다. 위의 설정을 사용하면 언제든지 파이프에 8MB의 데이터 흐름이 유지됩니다 (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를 사용하여 국제적으로 대용량 파일 세트를 전송하려고합니다.

아직 답변으로 언급되지는 않았지만 대기 시간이 긴 링크를 통해 여러 파일을 전송할 때 더 나은 성능을 얻는 간단한 솔루션이 있습니다.

여러 파일을 병렬로 전송하십시오.

그리고 그것은 이다 당신도 당신의 질문에 언급 된 솔루션. 사용해.

기본적으로 TCP 프로토콜은 큰 대역폭 지연 제품과의 연결을 잘 처리하지 못합니다. 단일 연결은 한 번에 충분한 데이터 이동을 유지할 수 없습니다. https://en.wikipedia.org/wiki/TCP_tuning을 참조 하십시오.

각 연결 은 TCP 프로토콜에 의해 제한 되므로 더 많은 연결을 사용하십시오.

sftp 전송 속도 향상

TCP 연결 당 네트워크 조정 및 / 또는 조절 문제가 있다고 가정하면 lftp 미러 하위 시스템을 사용하여 sftp를 살펴보십시오.

각 끝에서 네트워크 조정은 훨씬 더 큰 주제이며 많은 양의 앞뒤로 주제를 ServerFault 범위 밖으로 밀어냅니다. 개별 연결의 경우 iwaseatenbyagrue 가 언급 한 압축이 어느 쪽이든 도움이 될 수 있습니다. 이것은 원격 끝이 압축을 허용한다고 가정합니다.

(질문 제목에는 "높은 대기 시간"이 있지만 본문에는 없습니다. 실제 대기 시간을 측정 한 결과는 무엇입니까?)

대기 시간이 긴 네트워크 링크의 처리량을 명시 적으로 개선하는 OpenSSH 패치가 있습니다. HPN-SSH : (강조 광산)

OpenSSH에서 SCP와 기본 SSH2 프로토콜 구현은 정적으로 정의 된 내부 흐름 제어 버퍼에 의해 네트워크 성능이 제한됩니다. 이러한 버퍼는 종종 네트워크 링크가 길고 높은 대역폭에서 SCP의 네트워크 처리량에 병목 현상을 일으키는 경우가 많습니다. 런타임시 버퍼를 정의 할 수 있도록 ssh 코드를 수정하면이 병목 현상이 제거됩니다. OpenSSH의 병목 현상을 제거하고 다른 서버 및 클라이언트와 완전히 상호 운용 가능한 패치를 만들었습니다. 또한 HPN 클라이언트는 HPN이 아닌 서버에서 더 빨리 다운로드 할 수 있으며 HPN 서버는 HPN이 아닌 클라이언트로부터 더 빠르게 업로드를 수신 할 수 있습니다.

따라서 수신 측에서 HPN-SSH를 컴파일하여 사용하고 전송 속도가 향상되는지 확인하십시오.

이것이 당신을위한 옵션인지 확실하지 않지만, 데이터를 국제 사이트로 끌어 오는 것을 시도한 적이 있습니까? 다른 시간에 네트워크 리소스에 대한 경합에 문제가 있는지 확인하려면?

이 속도로 여러 연결을 업로드 할 수 있습니다 (대역폭이 아닙니까?)

고의로 (추가 프로비저닝없이 서비스를 판매하는 방법으로) 또는 실수로 (예 : 깨진 창 크기 조정 또는 지나치게 과도한 트래픽 제어) 구성 문제처럼 들립니다 . 전송을 병렬화 할 수는 있지만 연결의 다른 쪽 끝에 무엇이 있거나 파일의 샤딩 / 재구성을 처리하는 간단한 스크립트를 개발할 가치가 있는지 알려주지 않았습니다.

원인이 매우 잘못 작성된 소프트웨어 가 아니라면 큐 크기 및 압축 조정이 큰 영향을 미치지 는 않습니다. 서버의 문제를 배제하기 위해 다른 위치의 다른 클라이언트와 함께 시도하는 것을 고려할 수 있습니다.

첫 번째 전화는 문제의 원인이되는 제공자를 식별하고 문제를 해결하도록 요청하거나 다른 제공자로 전환하는 것입니다.