서버에서 다운로드 중이고 FileZilla를 사용하면 다운로드가 최대 1.3MiB/초로 제한되지만 동시 다운로드를 시작할 수 있으며 다운로드도 1.3MiB/초로 다운로드됩니다. 그렇다면 1.3MB/s보다 빠른 속도로 하나의 파일만 다운로드하고 사용 가능한 대역폭 포화 상태(~6+MB/s)에 가까워질 수 없는 이유는 무엇입니까?
lftp와 같은 분할된 다운로드를 지원하는 다른 SFTP 클라이언트를 사용할 수 있다는 것을 알고 있습니다. 오픈 소스인 다른 좋은 클라이언트도 알고 있습니까?
하지만 여전히 한 파일 다운로드를 1.3MB/s로 제한하는 것이 무엇인지 알고 싶습니다. TCP 및 버퍼 등에 대한 기술적 제한이 있거나 구성 문제가 있습니까? 확인해보니 FileZilla에 대해 트래픽 조절이 전혀 활성화되어 있지 않은 것이 확실합니다.
또한 rsync를 시도했는데 FileZilla/SFTP보다 나빴습니다. 나는 또한 WinSCP를 시도했는데 SCP/SFTP 방법에 관계없이 가장 느렸습니다. 따라서 1.3MB/s의 지속적인 전송 속도로 FileZilla는 다른 전송 방법에 비해 꽤 좋습니다.
누군가 전송 최고 속도가 1.3MB/s인 이유에 대해 잘 설명하고 있다면 분할 다운로드를 사용하지 않고도 이를 늘릴 수 있는지 알고 싶습니다. 서버가 OpenSSH 6.7p1(Debian)을 실행 중입니다. 클라이언트는 Windows의 FileZilla입니다.
업데이트: Martin의 정보(아래 답변 참조)에 대한 응답으로 다운로드 중인 서버와 클라이언트 사이의 핑이 180ms~190ms로 꽤 일정하다는 점을 추가하고 있습니다. 또한 CPU 사용량은 최대 2%~8%로 매우 낮습니다. 최신 버전인 Winscp 5.73을 사용해 보았고 sftp 모드에서는 scp 모드에서 555kb/s, 최대 약 805kb/s를 얻었습니다. 반면에 Filezilla에서 보조 동시 전송을 시작하면 이에 대해서도 일정한 1.3MiB/s를 얻습니다.
그렇다면 Martin과 Michael이 약간 언급한 것처럼 서버에 대한 180ms 지연이 수학적으로 제한 요소가 될 수 있습니까? 아니면 처리량을 향상시킬 수 있는 다른 원인이 있을 수 있습니까? 그렇지 않은 경우 안전하고 분할된 다운로드를 지원하는 다른 오픈 소스 다운로더(lftp와 같지만 Windows에서 잘 실행됨)를 아는 사람이 있으면 감사하겠습니다.
답변1
전송 속도에 영향을 미치는 세 가지 공통 요소는 다음과 같습니다.
대역폭– 분명히 당신의 문제가 아닌 명백한 요소입니다.
네트워크 지연/지연– SFTP는 패킷 지향 프로토콜입니다. 다운로드할 때 SFTP 클라이언트는 SFTP 서버에 "읽기" 요청을 보내고, 응답을 기다리고, 반환된 데이터를 로컬 파일에 추가합니다. 파일이 끝날 때까지 반복합니다.
연결이 빠르더라도 서버가 멀리 있거나 느리면 데이터가 다시 도착하는 데 시간이 걸립니다. 클라이언트가 이 시간을 쓸데없이 기다리며 낭비한다면 전송 속도가 느려질 것입니다.
대부분의 SFTP 클라이언트(FileZilla 및 WinSCP 포함)는 각각의 단일 "읽기" 요청에서 큰 파일 청크를 요청하고 이전에 대한 응답을 기다리지 않고 여러 "읽기" 요청을 전송(대기열에 추가)하여 문제를 극복합니다. 예를 들어 WinSCP는 각각 32KB씩 한 번에 최대 32개의 청크(총 1MB)를 요청할 수 있습니다(기본값). 그러나 대역폭과 네트워크 지연 사이에 큰 차이가 있는 경우 1MB라도 대역폭을 포화시키기에는 너무 작을 수 있습니다.
기본 TCP 프로토콜에도 비슷한 문제가 발생할 수 있습니다. 따라서 실제 SFTP 클라이언트의 효율성뿐만 아니라 기본 TCP 계층의 효율성도 중요합니다.
또한보십시오대역폭 지연 제품위키피디아에서.
적어도 테스트를 위해 최신 버전의 WinSCP를 사용한 경우에는 이것이 귀하의 문제라고 생각하지 않습니다. 가 있었다일부 개선최근 릴리스에서는 WinSCP가 FileZilla만큼 효율적으로 대기 시간이 긴 연결을 활용할 수 있게 되었습니다.
CPU– 암호화되는 SFTP는 CPU를 많이 사용합니다. 큰 대역폭에 비해 상대적으로 느린 CPU를 사용하는 경우 CPU가 네트워크에서 전송할 수 있는 속도만큼 빠르게 데이터를 암호화(또는 다운로드의 경우 해독)할 수 없기 때문에 전송이 제한될 수 있습니다.
일반적인 SFTP 클라이언트는 CPU 코어 간에 암호화/암호 해독을 분산할 수 없으므로 실제로 전송 속도를 제한하는 것은 단일 CPU 코어의 용량입니다.
Windows 작업 관리자를 사용하여 전송 중에 코어 중 하나가 최대로 활용되는지 확인하세요.
이 답변의 일부는 WinSCP 기사에서 나왔습니다.파일 전송 속도가 매우 느립니다. WinSCP는 사용 가능한 모든 대역폭을 활용하지 않습니다. 전송 속도를 향상시키려면 어떻게 해야 합니까?
답변2
나에게도 이 문제가 있었다.
작업 관리자를 사용하여 우선 순위를 높음으로 설정했습니다.
이제 최대 5MiB/s를 얻을 수 있습니다.
답변3
나는 최근에 Windows 10 및 최신 버전의 filezilla를 사용하여 동일한 네트워크를 시도했고 동일한 서버에서 최대 7MB/초의 전송 속도를 얻었습니다! 그런 다음 가상 머신 내에서 RSYNC로 테스트했는데 7MB/초도 얻었습니다. 이제 이 Windows 7 시스템에 설치한 COMODO 방화벽에 문제가 있다는 것을 "확실히 확신"합니다.
분명히 "비활성화"하더라도 규칙을 적용하지는 않지만 네트워크 스택 속도를 저하시킵니다. 이 Windows 7 시스템을 가상 머신 내에 설치/복제했으며 Comodo cis 프리미엄(바이러스 백신+방화벽)을 완전히 "제거"하고 여기에서 확인하겠습니다. 또한 이 컴퓨터에 대해 언급해야 할 점은 네트워크 사이의 다른 모든 시스템이 1ms 미만으로 안정적이었던 네트워크의 일부 시스템에 불규칙하고 간헐적인 대기 시간 핑이 발생하는 것을 발견했다는 것입니다. 따라서 대역폭 지연 제품 정보는 매우 좋지만 제 경우에는 동일한 네트워크 로컬 및 원격 설치에서 다른 설치에서 7MB/s(기본적으로 사용 가능한 대역폭을 포화)로 filezilla와 rsync를 모두 얻을 수 있었습니다.