Przyspieszyć przesyłanie SFTP w sieci o dużym opóźnieniu?

Próbuję przesłać zestaw dużych plików na arenie międzynarodowej za pomocą SFTP, ale okazuje się, że mój międzynarodowy partner nie może uzyskać prędkości przesyłania powyżej ~ 50 000 pomimo bardzo dobrych połączeń po obu stronach. Możemy uzyskać przesyłanie wielu połączeń z tą prędkością (więc nie przepustowość?), Ale żadne pojedyncze przesyłanie nie poprawia prędkości, co stanowi problem, ponieważ wiele plików ma rozmiar kilku GB.

SFTP jest hostowany przy użyciu standardowego systemu SFTP Apple OSX „Remote Login”.

Czy istnieje sposób na poprawę prędkości wysyłania, czy może istnieje inny host SFTP, który mógłby pomóc? Nie jest dla mnie jasne, czy jest to problem z konfiguracją, czy nieodłączne ograniczenie protokołu.

(Ze względów bezpieczeństwa muszę korzystać z szyfrowanego połączenia peer-to-peer typu end-to-peer - bez usług w chmurze).

W kliencie OpenSSHsftp (którego wydaje się używać) możesz użyć:

• -Rprzełącznik, aby zwiększyć długość kolejki żądań (domyślnie 64)
• -Bprzełącznik, aby zwiększyć rozmiar żądania odczytu / zapisu (domyślnie 32 KB)

Na początek spróbuj podwoić oba:

sftp -R 128 -B 65536 user@host

Prawdopodobnie nie ma to większego znaczenia, który z nich zwiększasz.

Zwiększenie jednego z nich powinno pomóc nasycić połączenie o dużym opóźnieniu. Dzięki powyższym ustawieniom w każdej chwili utrzyma przepływ danych o wartości 8 MB w rurze (128 * 64 K = 8 M).

Pamiętaj, że pomaga to tylko w przypadku przesyłania dużych plików. Nie przyniesie to żadnego efektu przy przenoszeniu dużej liczby małych plików.

Aby zapoznać się z tłem i dyskusją na temat innych klientów SFTP (GUI), zobacz sekcję „Opóźnienie / opóźnienie sieci” mojej odpowiedzi na pytanie: Dlaczego transfer plików FileZilla SFTP jest ograniczony do 1,3 Mb / s zamiast nasycania dostępnej przepustowości? rsync i WinSCP są jeszcze wolniejsze .

Możesz spróbować włączyć kompresję i sprawdzić, czy to pomoże.

Od man sftp:

-C Umożliwia kompresję (przez flagę -C ssh).

I od man ssh:

-C Żąda kompresji wszystkich danych (w tym stdin, stdout, stderr i danych dla przekierowanych połączeń w domenach X11, TCP i UNIX). Algorytm kompresji jest taki sam, jak używany przez gzip (1), a „poziomem” można sterować za pomocą opcji CompressionLevel dla protokołu w wersji 1. Kompresja jest pożądana na liniach modemowych i innych wolnych połączeniach, ale spowalnia tylko szybkie sieci. . Wartość domyślną można ustawić dla poszczególnych hostów w plikach konfiguracyjnych; zobacz opcję Kompresja.

Brzmi raczej tak, jakby połączenie mogło być ograniczone w pewnym momencie na swojej ścieżce (lub raczej wydaje mi się to najprostszym wyjaśnieniem twojego 50kB / s na połączenie, ale możliwe jest wiele takich połączeń), chociaż może to nie być zły pomysł, aby upewnić się, że dyski po obu stronach nie są czynnikiem.

Możesz także uruchomić szybkie polecenie pcap, aby sprawdzić, czy występują jakieś „oczywiste” problemy (takie jak duża liczba retransmisji) - ale jeśli nie masz pewności, że będziesz w stanie rozwiązać ten problem, prawdopodobnie po prostu sprawdzę, czy włączenie kompresji Wsparcie.

Próbuję przesłać zestaw dużych plików na arenie międzynarodowej za pomocą SFTP

Nie zostało to jeszcze wspomniane jako odpowiedź, ale podczas przesyłania wielu plików za pomocą łącza o dużym opóźnieniu istnieje jedno naprawdę proste rozwiązanie, aby uzyskać lepszą wydajność:

Przesyłaj wiele plików równolegle.

I to jest to rozwiązanie, które nawet nie wspomniał w swoim pytaniu. Użyj tego.

Zasadniczo protokół TCP nie obsługuje bardzo dobrze połączeń z produktem o dużym opóźnieniu przepustowości - pojedyncze połączenie nie może utrzymać wystarczającej ilości danych w ruchu jednocześnie. Zobacz https://en.wikipedia.org/wiki/TCP_tuning

Ponieważ każde połączenie jest ograniczone przez protokół TCP, wystarczy użyć więcej połączeń.

Przyspiesz transfery sftp

Zakładając, że masz problemy z dostrajaniem sieci i / lub dławieniem dla połączenia TCP, spójrz na sftp za pomocą podsystemu kopii lustrzanych lftp

Dostrajanie sieci na każdym końcu jest znacznie większym tematem i wymagałoby dużo w przód iw tył, wypychając temat poza zakres ServerFault. W przypadku indywidualnych połączeń kompresja wspomniana przez iwaseatenbyagrue może pomóc w obu przypadkach. Zakłada się, że zdalny koniec umożliwia kompresję.

(W tytule pytania wspominasz o „dużym opóźnieniu”, ale nie w tekście. Czy zmierzyłeś rzeczywiste opóźnienie i jakie są wyniki?)

Jest łatka do OpenSSH, która wyraźnie poprawia przepustowość łącza sieciowego o wysokim opóźnieniu: HPN-SSH : (moje podkreślenie)

SCP i podstawowa implementacja protokołu SSH2 w OpenSSH ograniczają wydajność sieci przez statycznie zdefiniowane bufory wewnętrznej kontroli przepływu. Bufory te często kończą się jako wąskie gardło przepustowości sieci SCP, szczególnie w przypadku długich i wysokich pasm z łączami sieciowymi. Modyfikacja kodu ssh, aby umożliwić definiowanie buforów w czasie wykonywania, eliminuje to wąskie gardło. Stworzyliśmy łatkę, która usunie wąskie gardła w OpenSSH i jest w pełni interoperacyjna z innymi serwerami i klientami. Ponadto klienci HPN będą mogli pobierać szybciej z serwerów innych niż HPN, a serwery HPN będą mogły odbierać przesyłanie szybciej od klientów innych niż HPN.

Spróbuj więc skompilować i użyć HPN-SSH po stronie odbierającej i sprawdź, czy poprawi to szybkość transferu.

Nie masz pewności, czy jest to dla Ciebie opcja, ale czy próbowałeś wyciągać vs wypychać dane na międzynarodową stronę? Jak również w różnych momentach, aby sprawdzić, czy jest to problem z rywalizacją o zasoby sieciowe?

Możemy uzyskać przesyłanie wielu połączeń z tą prędkością (więc nie przepustowość?)

To brzmi jak problem z konfiguracją - celowo (jako sposób na sprzedaż usług bez konieczności dokonywania dodatkowych czynności) lub przez przypadek (np. Zepsute skalowanie okna lub nadmierna kontrola ruchu). Chociaż możesz zrównoleglić transfery, nie powiedziałeś nam nic o tym, co jest na drugim końcu połączenia lub czy warto opracować proste skrypty do obsługi dzielenia / odtwarzania plików.

Strojenie rozmiaru kolejki i kompresji raczej nie będzie miało znaczącego wpływu, chyba że przyczyną jest bardzo źle napisane oprogramowanie (a openSSH nie wchodzi w tę kategorię - nie ma większego sensu w stosowaniu openssh z dłuższą kolejką żądań / większym rozmiarem bloku, chyba że opóźnienie jest ponad 250 ms. Możesz spróbować spróbować z różnymi klientami z różnych lokalizacji, aby wykluczyć problem z serwerem.

Moje pierwsze połączenie polegałoby na ustaleniu, który dostawca jest odpowiedzialny za problem, poproszeniu go o naprawienie problemu lub zmianę dostawcy.