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

27

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).

nick_eu
źródło
Jeśli masz budżet, istnieją rozwiązania komercyjne , które działają znacznie lepiej niż systemy przesyłania plików oparte na TCP, takie jak SFTP.
Kenster,
4
Jeśli jest to jednorazowy transfer wielu GB, dlaczego nie spróbować alternatywy dla Internetu .
vasin1987 11.04.17
1
Prosty skrypt powłoki umożliwiający rozpoczęcie rsynctransferu N z łatwością spełni Twoje wymagania 1. Bezpiecznego transferu i 2. Maksymalizacji przepustowości. Zobacz tutaj przykład rozpoczynania rsynctransferów N stackoverflow.com/a/38014502/52074
Trevor Boyd Smith
2
Lub po prostu użyj pliku uftp-multicast.sourceforge.net, aby zaszyfrować, a Mac zużyje przepustowość.
Trevor Boyd Smith
4
W przeciwieństwie do ostatniego zdania usługa w chmurze powinna być w porządku, jeśli szyfrujesz plik lokalnie, przesyłasz go przez chmurę, a następnie odszyfrowuje lokalnie 8 na drugim końcu), co nadal oznaczałoby szyfrowanie całościowe. (Możesz dodać krótką opinię na temat udanego odbioru). Używasz szyfrowania sftp, aby zapobiec atakom kogoś, kto jest w stanie obwąchać cały Twój ruch. Dlatego samo podanie im zaszyfrowanych danych nie jest gorsze niż założenie, że i tak mogą je zdobyć.
Hagen von Eitzen,

Odpowiedzi:

29

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 .

Martin Prikryl
źródło
4

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.

iwaseatenbyagrue
źródło
Dzięki! Niestety pliki są wstępnie skompresowane, więc wątpię, aby cokolwiek
zrobiło
Kompresja nie przyspiesza tutaj, nawet jeśli dane nie zostaną skompresowane. Jest to zbyt duży czas pracy procesora (i opóźnienie), więc w dzisiejszych czasach nie ma sensu.
Jakuje,
1
Jeśli wąskim gardłem jest sieć, to trochę więcej procesora po obu stronach nie powinno niczego spowalniać @Jakuje, chyba że box nie jest w stanie skompresować przy 50kB / s, co nie powinno być problemem.
Ben
@Ben Pytanie wyraźnie stwierdza, że ​​sieć nie stanowi wąskiego gardła.
Jakuje,
4

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ń.

Andrew Henle
źródło
1
Oto jak zrównoleglić transfery SFTP: serverfault.com/questions/248105/…
niutech
3

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ę.

Aaron
źródło
3

(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.

ambasador Twisteroid
źródło
Dzięki! Właściwie nie mierzyłem, teraz wstydzę się przyznać, ale idę w połowie świata do kraju z tak bardzo internetem, więc chyba mam rację. :) Łatka brzmi bardzo przydatnie!
nick_eu 11.04.17
@nick_eu Widziałem anegdoty, że naukowcy wykorzystaliby HPN-SSH do przesyłania dużych ilości danych naukowych przez Atlantyk. Wygląda na to, że powinien być idealny do twojego przypadku użycia.
ambasador Twisteroid
0

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?

Sleepyweasel
źródło
świetny pomysł, spróbuję.
nick_eu
0

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.

symcbean
źródło
Przepraszam, powinno być bardziej jasne. Nie ma „dostawcy” - hostuję na własnym pulpicie, a kolega próbuje połączyć się ze swojego komputera. Kolega właśnie otwiera sesję ssh (nie jestem pewien protokołu, ale może sprawdzić) i używaput
nick_eu
@nick_eu mówi o dostawcach Internetu.
Džuris,
Brzmi jak problem z konfiguracją Nie. To nie jest problem z konfiguracją. Sam protokół TCP nie działa dobrze na połączeniach z produktem o dużym opóźnieniu przepustowości. Zasadniczo, jeśli połączenie jest takie, że wiele danych może być jednocześnie w locie, sam protokół TCP nie może utrzymać tak dużej ilości danych w dowolnym momencie. Dlatego równoległe połączenia TCP działają w celu poprawy szybkości przesyłania danych.
Andrew Henle,
„nie działa dobrze na połączeniach z produktem o dużym opóźnieniu przepustowości” - przeczytaj RFC 1323 (od 1992) i 7323 (zastąpiono 1323 w 2014)
symcbean
@symcbean Następnie wyjaśnij PO 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 Jest to klasyczny objaw TCP w przypadku połączenia z ekstremalnym opóźnieniem - wszystkie rozszerzenia TCP mogą łagodzić problem nieco, ponieważ nie mogą rozwiązać podstawowych problemów związanych z samym protokołem. Powodzenia w określeniu, który dostawca jest odpowiedzialny za problem, poproś go o naprawienie problemu podczas próby „przesłania zestawu dużych plików na arenie międzynarodowej”.
Andrew Henle,