Pobierz duży plik przez złe połączenie

Czy istnieje narzędzie, które można wykorzystać do pobierania dużych plików w przypadku złego połączenia?

Muszę regularnie pobierać stosunkowo mały plik: 300 MB, ale powolne (80-120 KBytes / s) połączenie TCP losowo przerywa się po 10-120 sekundach. (Jest to sieć dużej firmy. Wielokrotnie kontaktowaliśmy się z ich administratorami (pracującymi z Indii), ale oni nie mogą lub nie chcą nic robić.) Problem może dotyczyć ich odwrotnych serwerów proxy / równoważenia obciążenia.

Do tej pory korzystałem ze zmodyfikowanej wersji pcurl: https://github.com/brunoborges/pcurl

Zmieniłem tę linię:

curl -s --range ${START_SEG}-${END_SEG} -o ${FILENAME}.part${i} ${URL} &

do tego:

curl -s --retry 9999 --retry-delay 3 --speed-limit 2048 --speed-time 10 \
    --retry-max-time 0 -C - --range ${START_SEG}-${END_SEG} -o ${FILENAME}.part${i} ${URL} &

Musiałem dodać, --speed-limit 2048 --speed-time 10ponieważ połączenie zwykle zawiesza się przez kilka minut, gdy nie powiedzie się.

Ale ostatnio nawet ten skrypt nie może zostać ukończony.

Jednym z problemów jest to, że wydaje się ignorować -C -część, więc nie „kontynuuje” segmentu po ponownej próbie. Wygląda na to, że obcina odpowiedni plik tymczasowy i zaczyna się od początku po każdym niepowodzeniu. (Myślę, że --rangei -Copcji nie można używać razem.)

Innym problemem jest to, że ten skrypt pobiera wszystkie segmenty jednocześnie. Nie może mieć 300 segmentów, z których jednocześnie pobieranych jest tylko 10.

Myślałem o napisaniu narzędzia do pobierania w C # do tego konkretnego celu, ale jeśli istnieje narzędzie lub jeśli polecenie curl może działać poprawnie z różnymi parametrami, mógłbym poświęcić trochę czasu.

AKTUALIZACJA 1: Informacje dodatkowe: Funkcji pobierania równoległego nie należy usuwać, ponieważ mają one limit przepustowości (80-120 kB / s, głównie 80) na połączenie, więc 10 połączeń może spowodować 10-krotne przyspieszenie. Pobieranie pliku muszę zakończyć w ciągu 1 godziny, ponieważ plik jest generowany co godzinę.

lftp( Wikipedia ) jest do tego dobra. Obsługuje wiele protokołów, może pobierać pliki przy użyciu kilku równoległych połączeń równoległych (przydatne, gdy utrata pakietów nie jest spowodowana przeciążeniem) i może automatycznie wznawiać pobieranie. Jest także skryptowalny.

Tutaj wraz z dopracowaniem, które wymyśliłeś (podziękowania):

lftp -c 'set net:idle 10
         set net:max-retries 0
         set net:reconnect-interval-base 3
         set net:reconnect-interval-max 3
         pget -n 10 -c "https://host/file.tar.gz"'

Nie mogę przetestować to dla ciebie w twojej sytuacji, ale nie powinien być używany --rangez -C -. Oto, co strona man ma do powiedzenia na ten temat:

Użyj -C -, curlaby automatycznie dowiedzieć się, gdzie / jak wznowić przesyłanie. Następnie wykorzystuje podane pliki wyjściowe / wejściowe, aby to rozgryźć.

Spróbuj zamiast tego:

curl -s --retry 9999 --retry-delay 3 --speed-limit 2048 --speed-time 10 \
    --retry-max-time 0 -C - -o "${FILENAME}.part${i}" "${URL}" &

Zdecydowanie polecam również, aby zawsze cytować swoje zmienne, aby powłoka nie próbowała ich parsować. (Rozważ adres URL https://example.net/param1=one&param2=two, w którym powłoka podzieli wartość w &.)

Nawiasem mówiąc, 120 KB / s to około 1,2 Mb / s, co jest typową prędkością wysyłania xDSL w wielu częściach świata. 10 sekund na MB, czyli nieco mniej niż godzinę dla całego pliku. Nie tak wolno, choć doceniam, że bardziej zależy Ci na niezawodności niż na szybkości.

Może masz więcej szczęścia z wget --continue:

wget --continue ${URL}

Zobacz także https://www.cyberciti.biz/tips/wget-resume-broken-download.html

Poza pudełkiem: załóż opaskę na oko i użyj bittorrent. Zmniejsz rozmiar bloku podczas tworzenia torrenta. Oczywiście zaszyfruj plik, aby każdy, kto znajdzie torrent, nie uzyska nic przydatnego.

Miałem ten sam problem w poprzednim zadaniu (z wyjątkiem 300 GB + kopii zapasowych poza bazą danych przy niestabilnym połączeniu (z biura)). Użytkownicy mieli poważne problemy z pobraniem pliku większego niż ok. 1 GB przed nawiązaniem połączenia. Ponieważ używali standardowego pliku kopiuj / wklej Windows w połączeniu RDP, nic dziwnego.

Odkryłem, że nasze ustawienia VPN były całkowicie niezgodne z konfiguracją sieci (głównie długość MTU). Po drugie, kopiarka plików systemu Windows NIE jest przeznaczona do kopiowania plików przez Internet.

Moje pierwsze rozwiązanie było prostym serwerem FTP, jednak nie rozwiązało problemu czasu transmisji (często 3-4 godziny na naszym połączeniu).

Moim drugim rozwiązaniem było użycie Syncthing do wysłania plików bezpośrednio na wewnętrzny serwer NAS. Każdej nocy po zakończeniu tworzenia kopii zapasowych Syncthing wysyłał wszystko, czego potrzebowaliśmy, z powrotem na serwer NAS w biurze. Nie tylko rozwiązano problem ponad 3-godzinnego czasu transmisji, ale oszczędzono mi 1-2 godziny na przesyłanie danych w razie kryzysu. Codziennie o 8 rano pliki będą aktualizowane na serwerze NAS, a my mieliśmy gotowe kopie zapasowe. Nawet przy dużych plikach (w pewnym momencie baza danych prawie 700 GB) nie doświadczyłem jeszcze uszkodzenia plików ani innych problemów ...

Syncthing jest bardzo łatwy w konfiguracji i zarządzaniu i jest dostępny dla wszystkich platform (nawet telefonów), i ma bardzo dobrą obsługę złych połączeń .. jeśli połączenie nie powiedzie się, Syncthing po prostu czeka kilka minut i próbuje ponownie.

Potrzebujesz lokalnego folderu do synchronizacji rzeczy, ale twoje pliki będą dostępne niemal natychmiast po ich aktualizacji.

Kolejną dobrą rzeczą w synchronizacji jest to, że można ją ustawić tak, aby synchronizowała tylko zmiany w pliku (jak w różnicowej kopii zapasowej) ... prawdopodobnie rozwiązując część problemu z przepustowością.

Możesz rozważyć oldschoolowe rozwiązanie do przenoszenia plików przez kiepskie połączenie - zmodem .

Zostało to opracowane już wtedy, gdy modemy 2400 bodów z ludźmi odbierającymi telefony i zbombardującymi połączenie były normą. Może warto spróbować.

Możesz spróbować użyć Kermit :

Cechą, która odróżnia protokół Kermit od większości innych, jest szeroki zakres ustawień umożliwiający dostosowanie do dowolnego rodzaju i jakości połączenia między dowolnymi dwoma rodzajami komputerów - długość pakietu, kodowanie pakietu, rozmiar okna, zestaw znaków, metoda wykrywania błędów, przekroczenia czasu , zatrzymuje się. Większość innych protokołów jest zaprojektowana do działania tylko na niektórych rodzajach lub właściwościach połączeń i / lub między niektórymi komputerami lub podobnymi systemami plików, a zatem działa słabo (lub wcale) gdzie indziej i oferuje niewiele, jeśli w ogóle, jakichkolwiek metod dostosowania się do nieplanowanych -do sytuacji. Z drugiej strony Kermit pozwala osiągnąć udany transfer plików i najwyższą możliwą wydajność dla każdego połączenia. ”