Tăng tốc độ tải lên SFTP trên mạng có độ trễ cao?

27

Tôi đang cố gắng chuyển một tập hợp các tệp lớn ra quốc tế bằng SFTP, nhưng tôi thấy đối tác quốc tế của mình không thể có tốc độ tải lên trên ~ 50k mặc dù kết nối rất tốt ở hai bên. Chúng tôi có thể nhận được nhiều kết nối tải lên ở tốc độ này (không phải băng thông?), Nhưng không có tải lên duy nhất nào cải thiện tốc độ, đây là một vấn đề vì nhiều tệp có kích thước vài gb.

SFTP đang được lưu trữ bằng hệ thống SFTP "Đăng nhập từ xa" tiêu chuẩn của Apple OSX.

Có cách nào để cải thiện tốc độ tải lên, hoặc có một máy chủ SFTP khác sẽ giúp ích không? Tôi không rõ đây là vấn đề cấu hình hay giới hạn vốn có của giao thức.

(Vì lý do bảo mật, tôi cần sử dụng kết nối ngang hàng được mã hóa nối đầu - không có dịch vụ đám mây).

— nick_eu
nguồn

Nếu bạn có ngân sách, có những giải pháp thương mại hoạt động tốt hơn nhiều so với các hệ thống truyền tệp dựa trên TCP như SFTP.

— Kenster

4

Nếu đó là chuyển khoản nhiều lần, tại sao không thử một giải pháp thay thế cho internet .

— vasin1987

1

Một tập lệnh shell đơn giản để bắt đầu rsyncchuyển N sẽ dễ dàng đạt được các yêu cầu của bạn là 1. Chuyển an toàn và 2. Tối đa hóa băng thông của bạn. Xem ở đây để biết ví dụ về cách bắt đầu N rsyncchuyển stackoverflow.com/a/38014502/52074

— Trevor Boyd Smith

2

Hoặc chỉ cần sử dụng uftp-multicast.sourceforge.net muốn mã hóa và Mac ra khỏi băng thông của bạn.

— Trevor Boyd Smith

4

Trái với câu cuối cùng của bạn, dịch vụ đám mây sẽ ổn nếu bạn mã hóa tệp cục bộ, chuyển nó qua đám mây, sau đó giải mã cục bộ 8at đầu kia), điều đó vẫn có nghĩa là mã hóa đầu cuối. (Bạn có thể muốn thêm một số phản hồi ngắn về việc tiếp nhận thành công). Bạn sử dụng mã hóa sftp để ngăn chặn các cuộc tấn công bởi ai đó có thể đánh hơi tất cả lưu lượng truy cập của bạn. Do đó, chỉ cần cung cấp cho họ dữ liệu được mã hóa không tệ hơn là giả sử họ có thể lấy dữ liệu đó.

— Hagen von Eitzen

29

Với ứng dụng khách OpenSSHsftp (mà bạn dường như sử dụng), bạn có thể sử dụng:

-Rchuyển sang tăng chiều dài hàng đợi yêu cầu (mặc định là 64)
-Bchuyển sang tăng kích thước yêu cầu đọc / ghi (mặc định là 32 KB)

Để bắt đầu, hãy thử nhân đôi cả hai:

sftp -R 128 -B 65536 user@host

Nó có thể không quan trọng nhiều, mà bạn tăng lên.

Tăng một trong hai sẽ giúp bão hòa kết nối độ trễ cao của bạn. Với các cài đặt ở trên, nó sẽ giữ cho dữ liệu có giá trị 8 MB chảy trong đường ống bất cứ lúc nào (128 * 64K = 8M).

Lưu ý rằng điều này chỉ giúp chuyển tập tin lớn. Nó sẽ không có hiệu lực, khi chuyển rất nhiều tệp nhỏ.

Để biết một số thông tin cơ bản và thảo luận về các máy khách SFTP (GUI) khác, hãy xem phần "Độ trễ / độ trễ mạng" trong câu trả lời của tôi về Tại sao tối đa việc truyền tệp SFTP FileZilla bị giới hạn ở mức 1,3MiB / giây thay vì bão hòa băng thông có sẵn? rsync và WinSCP thậm chí còn chậm hơn .

— Martin Prikryl
nguồn

4

Bạn có thể thử và kích hoạt tính năng nén và xem điều đó có giúp ích không.

Từ man sftp:

-C Cho phép nén (thông qua cờ -C của ssh).

Và từ man ssh:

-C Yêu cầu nén tất cả dữ liệu (bao gồm stdin, stdout, stderr và dữ liệu cho các kết nối miền X11, TCP và UNIX được chuyển tiếp). Thuật toán nén được sử dụng tương tự bởi gzip (1), và mức độ có thể được điều khiển bởi các tùy chọn NénLevel cho phiên bản giao thức 1. Nén là mong muốn trên các dòng modem và các kết nối chậm khác, nhưng sẽ chỉ làm chậm mọi thứ trên các mạng nhanh . Giá trị mặc định có thể được đặt trên cơ sở lưu trữ theo máy chủ trong các tệp cấu hình; xem tùy chọn Nén.

Nghe có vẻ như kết nối có thể bị giới hạn tốc độ tại một số điểm trên đường đi của nó (hoặc đúng hơn, đó dường như là lời giải thích đơn giản nhất cho 50kB / s của bạn cho mỗi kết nối, nhưng có thể nhiều kết nối như vậy), mặc dù có thể không phải là một ý tưởng tồi để đảm bảo các đĩa ở hai bên không phải là một yếu tố.

Bạn cũng có thể chạy một bản pcap nhanh để xem liệu có bất kỳ vấn đề 'rõ ràng' nào không (chẳng hạn như một số lượng lớn các lần truyền lại) - nhưng trừ khi bạn có chút tự tin, bạn có thể giải quyết vấn đề này, tôi có thể chỉ xem nếu bật tính năng nén Cứu giúp.

— iwaseatenbyagrue
nguồn

Cảm ơn! Thật không may, các tệp được nén trước, vì vậy tôi nghi ngờ rằng sẽ làm bất cứ điều gì ...: /

— nick_eu

Nén không tăng tốc mọi thứ ở đây ngay cả khi dữ liệu sẽ không được nén. Nó quá lớn về thời gian của CPU (và độ trễ) nên không có ý nghĩa gì trong những ngày này.

— Jakuje

1

Nếu nút cổ chai là mạng thì một chút CPU ở hai bên không nên làm chậm bất cứ thứ gì @Jakuje, trừ khi hộp không thể nén ở tốc độ 50kB / giây, đây không phải là vấn đề.

— Ben

@Ben Câu hỏi nêu rõ rằng mạng không phải là nút cổ chai.

— Jakuje

4

Tôi đang cố gắng chuyển một tập hợp các tệp lớn quốc tế bằng SFTP

Nó chưa được đề cập như một câu trả lời, nhưng khi chuyển nhiều tệp qua liên kết có độ trễ cao, có một giải pháp thực sự đơn giản để có hiệu suất tốt hơn:

Chuyển nhiều tệp song song.

Và nó là một giải pháp mà bạn thậm chí đã đề cập trong câu hỏi của bạn. Sử dụng nó.

Về cơ bản, giao thức TCP không xử lý tốt các kết nối với một sản phẩm trễ băng thông lớn - một kết nối duy nhất không thể giữ đủ dữ liệu di chuyển bất cứ lúc nào. Xem https://en.wikipedia.org/wiki/TCP_tuning

Vì mỗi kết nối bị giới hạn bởi giao thức TCP, chỉ cần sử dụng nhiều kết nối hơn.

— Andrew Henle
nguồn

1

Dưới đây là cách song song hóa chuyển SFTP: serverfault.com/questions/248105/iêu

— niutech

3

Tăng tốc độ chuyển sftp

Giả sử các vấn đề của bạn là điều chỉnh mạng và / hoặc điều chỉnh trên mỗi kết nối TCP, hãy xem sftp bằng cách sử dụng hệ thống con nhân bản lftp

Điều chỉnh mạng ở mỗi đầu là một chủ đề lớn hơn nhiều và sẽ đòi hỏi nhiều lần qua lại, đẩy chủ đề ra ngoài phạm vi của ServerFault. Đối với các kết nối riêng lẻ, việc nén được đề cập bởi iwaseatenbyagrue có thể giúp một trong hai cách. Điều này giả định kết thúc từ xa cho phép nén.

— Aaron
nguồn

3

(Bạn đề cập đến "độ trễ cao" trong tiêu đề câu hỏi, nhưng không phải trong văn bản cơ thể. Bạn đã đo độ trễ thực tế chưa, và kết quả là gì?)

Có một bản vá cho OpenSSH cải thiện rõ ràng thông lượng trên một liên kết mạng có độ trễ cao: HPN-SSH : (nhấn mạnh của tôi)

SCP và triển khai giao thức SSH2 cơ bản trong OpenSSH là hiệu suất mạng bị giới hạn bởi bộ đệm điều khiển luồng nội bộ được xác định tĩnh. Các bộ đệm này thường kết thúc như một nút cổ chai cho thông lượng mạng của SCP, đặc biệt là trên các liên kết mạng dài và cao. Sửa đổi mã ssh để cho phép các bộ đệm được xác định trong thời gian chạy giúp loại bỏ nút cổ chai này. Chúng tôi đã tạo ra một bản vá sẽ loại bỏ các nút thắt cổ chai trong OpenSSH và hoàn toàn tương thích với các máy chủ và máy khách khác. Ngoài ra, các máy khách HPN sẽ có thể tải xuống nhanh hơn từ các máy chủ không phải HPN và các máy chủ HPN sẽ có thể nhận tải lên nhanh hơn từ các máy khách không phải HPN.

Vì vậy, hãy thử biên dịch và sử dụng HPN-SSH ở phía bên nhận và xem liệu nó có cải thiện tốc độ truyền của bạn không.

— đại sứ twisteroid
nguồn

Cảm ơn! Tôi chưa thực sự đo lường được, giờ tôi đang lúng túng thừa nhận, nhưng tôi đang đi nửa vòng trái đất vào một đất nước có internet, vì vậy tôi đoán là mình đúng. :) Bản vá âm thanh rất hữu ích!

— nick_eu

@nick_eu Tôi đã thấy những giai thoại rằng các nhà khoa học sẽ sử dụng HPN-SSH để chuyển một lượng lớn dữ liệu khoa học trên Đại Tây Dương. Âm thanh như nó phải là hoàn hảo cho trường hợp sử dụng của bạn.

— Đại sứ twisteroid

0

Không chắc chắn nếu đây là một tùy chọn cho bạn, nhưng bạn đã thử kéo và đẩy dữ liệu lên trang web quốc tế chưa? Cũng như vào các thời điểm khác nhau để xem liệu đó có phải là vấn đề tranh chấp tài nguyên mạng không?

— buồn ngủ
nguồn

ý tưởng tuyệt vời, sẽ cố gắng.

— nick_eu

0

Chúng tôi có thể nhận được nhiều kết nối tải lên ở tốc độ này (vì vậy không phải băng thông?)

Nghe có vẻ như là một vấn đề cấu hình - có thể có chủ ý (như một cách để nâng cao dịch vụ mà không phải cung cấp thêm) hoặc do tai nạn (ví dụ: mở rộng cửa sổ bị vỡ hoặc điều khiển giao thông quá nhiệt). Mặc dù bạn có thể song song hóa các giao dịch mà bạn đã không nói với chúng tôi về những gì ở đầu kia của kết nối hoặc nếu nó đáng để phát triển một số tập lệnh đơn giản để xử lý việc sắp xếp / phục hồi các tập tin.

Điều chỉnh kích thước hàng đợi và nén dường như không có tác động đáng kể, trừ khi nguyên nhân là phần mềm được viết rất tệ (và openSSH không thuộc loại này - không có nhiều điểm trong việc sử dụng openssh với hàng đợi yêu cầu dài hơn / kích thước khối lớn hơn trừ khi độ trễ là trên 250msec. Bạn có thể cân nhắc thử với các máy khách khác nhau từ các địa điểm khác nhau để loại trừ sự cố với máy chủ.

Cuộc gọi đầu tiên của tôi sẽ là xác định nhà cung cấp nào sẽ đổ lỗi cho vấn đề này, yêu cầu họ khắc phục sự cố hoặc chuyển sang nhà cung cấp khác.

— cây đậu tương
nguồn

Xin lỗi, nên đã rõ ràng hơn. Không có "nhà cung cấp" - Tôi đang lưu trữ trên máy tính để bàn của riêng mình và một đồng nghiệp đang cố gắng kết nối từ máy tính của họ. Đồng nghiệp chỉ đang mở một phiên ssh (không chắc chắn về giao thức nhưng có thể kiểm tra) và sử dụngput

— nick_eu

@nick_eu anh đang nói về các nhà cung cấp internet.

— Džuris

Nghe có vẻ như là một vấn đề cấu hình . Không phải là vấn đề cấu hình. Bản thân giao thức TCP không hoạt động tốt trên các kết nối với sản phẩm có độ trễ băng thông lớn. Về cơ bản, nếu kết nối có thể có nhiều dữ liệu trong một chuyến bay, thì giao thức TCP không thể giữ cho nhiều dữ liệu đó di chuyển bất cứ lúc nào. Đó là lý do tại sao các kết nối TCP song song hoạt động để cải thiện tốc độ truyền dữ liệu.

— Andrew Henle

"không hoạt động tốt trên các kết nối với một sản phẩm trễ băng thông lớn" - vui lòng đọc RFC 1323 (từ 1992) và 7323 (thay thế 1323 vào năm 2014)

— symcbean

@symcbean Sau đó, giải thích OP là chúng tôi có thể nhận được nhiều kết nối tải lên ở tốc độ này (vì vậy không băng thông?), nhưng không upload đơn cải thiện về tốc độ Đó là một triệu chứng điển hình của giao thức TCP qua kết nối với độ trễ cực - tất cả các phần mở rộng TCP có thể làm là Giảm thiểu vấn đề phần nào vì họ không thể giải quyết các vấn đề cơ bản với chính giao thức. Và may mắn với việc xác định nhà cung cấp nào sẽ đổ lỗi cho vấn đề này, yêu cầu họ khắc phục sự cố trong khi cố gắng "chuyển một tập hợp các tệp lớn ra quốc tế".

— Andrew Henle