왜 scp가 너무 느리고 어떻게 더 빨리 만드는가?

파일 배치를 복사하려고하는데 scp매우 느립니다. 다음은 10 개의 파일이있는 예입니다.

$ time scp cap_* user@host:~/dir
cap_20151023T113018_704979707.png    100%  413KB 413.2KB/s   00:00    
cap_20151023T113019_999990226.png    100%  413KB 412.6KB/s   00:00    
cap_20151023T113020_649251955.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_284028464.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_927950468.png    100%  413KB 413.0KB/s   00:00    
cap_20151023T113022_567641507.png    100%  413KB 413.1KB/s   00:00    
cap_20151023T113023_203534753.png    100%  414KB 413.5KB/s   00:00    
cap_20151023T113023_855350640.png    100%  412KB 411.7KB/s   00:00    
cap_20151023T113024_496387641.png    100%  412KB 412.3KB/s   00:00    
cap_20151023T113025_138012848.png    100%  414KB 413.8KB/s   00:00    
cap_20151023T113025_778042791.png    100%  413KB 413.4KB/s   00:00    

real    0m43.932s
user    0m0.074s
sys 0m0.030s

이상한 점은 전송 속도가 약 413KB / s이고 파일 크기가 약 413KB이므로 실제로 초당 1 개의 파일을 전송해야하지만 파일 당 약 4.3 초가 걸립니다.

이 오버 헤드가 어디에서 왔는지 더 빨리 이해할 수있는 방법이 있습니까?

@ wurtel의 의견은 아마도 맞을 것입니다 : 각 연결을 설정하는 데 많은 오버 헤드가 있습니다. 이 문제를 해결 하면 더 빠른 전송이 가능합니다 (그렇지 않으면 @roaima의 rsync해결 방법 만 사용하십시오 ). 비슷한 크기의 파일 ( head -c 417K /dev/urandom > foo.1및 해당 파일의 일부 사본)을 연결하는 데 시간이 걸리는 호스트 (HOST4)와 매우 빠르게 응답하는 호스트 (HOST1) 로 전송하는 실험 을 수행했습니다.

$ time ssh $HOST1 echo


real    0m0.146s
user    0m0.016s
sys     0m0.008s
$ time scp * $HOST1:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m0.337s
user    0m0.032s
sys     0m0.016s
$ time ssh $HOST4 echo


real    0m1.369s
user    0m0.020s
sys     0m0.016s
$ time scp * $HOST4:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m6.489s
user    0m0.052s
sys     0m0.020s
$ 

단일 연결을 사용하여 모든 소스 파일을 전송하는 rsync(이상 ssh)을 사용할 수 있습니다 .

rsync -avP cap_* user@host:dir

당신이하지 않은 경우 rsync(왜!?하지 않음) 당신은 사용할 수 tar와 ssh임시 파일을 생성하는 것을 피한다, 이는 다음과 같이 :

tar czf - cap_* | ssh user@host tar xvzfC - dir

는 rsync그것이 중단되는 경우 재시작이기 때문에, 다른 모든 조건이 동일, 선호된다.

시간이 걸리는 것은 양도 협상입니다. 일반적으로 b 바이트 의 n 파일에 대한 조작은 각각 n * b 바이트 의 단일 파일에 대한 단일 조작보다 훨씬 오래 걸립니다 . 디스크 I / O의 경우에도 마찬가지입니다.

주의 깊게 살펴보면이 경우 전송 속도가 size_of_the_file / secs 임을 알 수 있습니다 .

파일을보다 효율적으로 전송하려면 파일을 함께 묶은 tar다음 tarball을 전송하십시오.

tar cvf myarchive.tar cap_20151023T*.png

또는 아카이브를 압축하려는 경우

tar cvzf myarchive.tar.gz myfile*

압축 여부는 파일 내용에 따라 다릅니다 (예 : JPEG 또는 PNG 인 경우 압축이 적용되지 않습니다.

scp가 특히 대역폭이 높은 네트워크에서 속도보다 느려 야하는 또 다른 이유는 네트워크 성능 병목 현상이 발생하는 내부 흐름 제어 버퍼를 정적으로 정의했기 때문입니다.

HPN-SSH 는 OpenSSH의 패치 버전으로 이러한 버퍼의 크기를 증가시킵니다. 그것은 scp 전송 속도에 큰 차이를 만듭니다 (사이트의 차트를 참조하지만 개인 경험에서도 이야기합니다). 물론, 이점을 얻으려면 모든 호스트에 HPN-SSH를 설치해야하지만 정기적으로 대용량 파일을 전송해야하는 경우에는 그만한 가치가 있습니다.

병렬 gzip과 netcat을 사용하여 데이터를 빠르게 압축하고 복사하는 여기에 설명 된 기술 을 사용했습니다.

그것은 다음과 같이 요약됩니다 :

# SOURCE: 
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888

# TARGET:
> nc <source host> 8888 | pigz -d | tar xf - -C /

tar를 사용하여 파일을 수집합니다. 그런 다음 pigz를 사용하여 파일을 압축하고 전송하는 많은 CPU 스레드를 얻습니다. 네트워크 전송은 netcat을 사용하고 있습니다. 수신 측에서 netcat은 수신 한 후 (병렬로) 압축 해제하고 압축을 해제합니다.

이 문제는을 통해 큰 mp4 파일의 사이트 간 전송을 수행했습니다 scp. ~ 250KB / s를 받고있었습니다. 대상 방화벽에서 UDP 플러드 보호 (FP)를 비활성화 한 후 전송 속도가 6.5MB / s로 증가했습니다. FP를 다시 켤 때 속도는 ~ 250KB / s로 떨어졌습니다.

발신자 : cygwin, 수신자 : Fedora 20, Firewall Sophos UTM.

SSH는 무엇을 위해 UDP를 사용합니까? @ superuser.com - 내가 무엇을 읽고 직접하지 않습니다.

방화벽 로그를 검토 할 때 개인 사이트 간 내부 VPN 주소가 아닌 공개 IP 주소를 통해 소스 및 대상 포트 4500에서 플러드 감지가 발생했습니다. 따라서 내 문제는 scpTCP 데이터가 궁극적으로 ESP 및 UDP 패킷으로 암호화되어 캡슐화되어 FP에 영향을받는 NAT 통과 상황 인 것 같습니다 . scp방정식에서 제거하기 위해 VPN을 통해 Windows 파일 복사 작업을 실행했으며 scpFP를 사용하거나 사용하지 않는 것과 유사한 성능을 발견했습니다 . 또한 iperfTCP를 통해 테스트를 실행하고 FP로 2Mbits / sec를 보았으며, 그렇지 않으면 55Mbits / sec로 나타났습니다.

NAT-T는 IPSec과 어떻게 작동합니까? @ cisco.com