Tại sao scp rất chậm và làm thế nào để làm cho nó nhanh hơn?

Tôi đang cố gắng sao chép một loạt các tệp với scpnhưng nó rất chậm. Đây là một ví dụ với 10 tệp:

$ 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

Điều kỳ lạ là tốc độ truyền tải khoảng 413KB / giây và kích thước tệp khoảng 413KB nên thực sự cần truyền một tệp mỗi giây, tuy nhiên mất khoảng 4,3 giây cho mỗi tệp.

Bất kỳ ý tưởng mà chi phí này đến từ đâu, và có cách nào để làm cho nó nhanh hơn?

Nhận xét của @ wurtel có lẽ đúng: có rất nhiều chi phí thiết lập mỗi kết nối. Nếu bạn có thể khắc phục rằng bạn sẽ nhận được chuyển khoản nhanh hơn (và nếu bạn không thể, chỉ cần sử dụng rsynccách giải quyết của @ roaima ). Tôi đã thực hiện một thử nghiệm chuyển các tệp có kích thước tương tự ( head -c 417K /dev/urandom > foo.1và tạo một số bản sao của tệp đó) sang một máy chủ cần một thời gian để kết nối (HOST4) và một tệp phản hồi rất nhanh (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
$ 

Bạn có thể sử dụng rsync(kết thúc ssh), sử dụng một kết nối duy nhất để chuyển tất cả các tệp nguồn.

rsync -avP cap_* user@host:dir

Nếu bạn không có rsync(và tại sao không !?), bạn có thể sử dụng tarvới sshnhư thế này, mà tránh tạo ra một tập tin tạm thời:

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

Điều rsyncnày được ưu tiên, tất cả những thứ khác đều bằng nhau, vì nó có thể khởi động lại trong trường hợp bị gián đoạn.

Đó là cuộc đàm phán chuyển nhượng cần có thời gian. Nói chung, các hoạt động trên n tệp của b byte mỗi mất nhiều thời gian hơn nhiều so với một thao tác trên một tệp n * b byte. Điều này cũng đúng, ví dụ như đối với I / O đĩa.

Nếu bạn nhìn kỹ, bạn sẽ thấy tốc độ truyền trong trường hợp này là size_of_the_file / giây.

Để truyền tệp hiệu quả hơn, hãy kết hợp chúng lại với nhau tar, sau đó chuyển tarball:

tar cvf myarchive.tar cap_20151023T*.png

hoặc, nếu bạn cũng muốn nén kho lưu trữ,

tar cvzf myarchive.tar.gz myfile*

Có nén hay không phụ thuộc vào nội dung tập tin, vd. nếu chúng là JPEG hoặc PNG, nén sẽ không có hiệu lực.

Một lý do khác khiến scp chậm hơn so với yêu cầu, đặc biệt là trên các mạng băng thông cao, là nó có bộ đệm điều khiển luồng nội bộ được xác định tĩnh mà cuối cùng trở thành nút cổ chai hiệu năng mạng.

HPN-SSH là phiên bản vá của OpenSSH, giúp tăng kích thước của các bộ đệm này. Nó tạo ra sự khác biệt lớn đối với tốc độ truyền scp (xem biểu đồ trên trang web, nhưng tôi cũng nói từ kinh nghiệm cá nhân). Tất nhiên, để có được những lợi ích bạn cần cài đặt HPN-SSH trên tất cả các máy chủ của mình nhưng nó cũng đáng giá nếu bạn thường xuyên cần chuyển các tệp lớn xung quanh.

Tôi đã sử dụng kỹ thuật được mô tả ở đây sử dụng gzip và netcat song song để nhanh chóng nén và sao chép dữ liệu.

Nó đun sôi xuống:

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

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

Điều này sử dụng tar để thu thập các tập tin hoặc tập tin. Sau đó sử dụng pigz để lấy nhiều luồng cpu để nén và gửi tệp, việc truyền mạng đang sử dụng netcat. Về phía bên nhận, netcat lắng nghe sau đó giải nén (song song) và gỡ bỏ.

Chỉ có vấn đề này khi thực hiện chuyển từ trang này sang trang khác của một tệp mp4 lớn thông qua scp. Đã nhận được ~ 250KB / s. Sau khi vô hiệu hóa bảo vệ lũ UDP (FP) trên tường lửa đích, tốc độ truyền tăng lên 6,5MB / s. Khi bật lại FP, tốc độ giảm xuống ~ 250KB / s.

Người gửi: cygwin, Người nhận: Fedora 20, Tường lửa Sophos UTM.

SSH sử dụng UDP để làm gì? @ superuser.com - Nó không trực tiếp từ những gì tôi đọc.

Khi xem xét nhật ký tường lửa, phát hiện lũ đã xảy ra trên cả hai cổng nguồn & số 4500 trên các địa chỉ IP công cộng, chứ không phải các địa chỉ VPN nội bộ của trang web riêng tư. Vì vậy, có vẻ như vấn đề của tôi có thể là tình huống NAT Traversal trong đó scpdữ liệu TCP cuối cùng được mã hóa và gói gọn trong các gói ESP & UDP, và do đó phải tuân theo FP. Để loại bỏ scpkhỏi phương trình, tôi đã chạy một hoạt động sao chép tệp Windows trên VPN và nhận thấy hiệu suất tương tự scpvới và không bật FP. Cũng đã chạy iperfthử nghiệm qua TCP và nhận thấy 2Mbit / giây với FP và 55Mbits / giây mà không có.

NAT-T hoạt động với IPSec như thế nào? @ cisco.com