Скачать большой файл через плохое соединение

Существует ли существующий инструмент, который можно использовать для загрузки больших файлов через плохое соединение?

Я должен регулярно загружать относительно небольшой файл: 300 МБ, но медленное (80-120 КБайт / с) TCP-соединение случайно разрывается через 10-120 секунд. (Это сеть большой компании. Мы связывались с их администраторами (работающими из Индии) несколько раз, но они не могут или не хотят ничего делать.) Проблема может быть в их обратных прокси / балансировщиках нагрузки.

До сих пор я использовал модифицированную версию pcurl: https://github.com/brunoborges/pcurl

Я изменил эту строку:

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

к этому:

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} &

Мне пришлось добавить, --speed-limit 2048 --speed-time 10потому что соединение в основном просто зависает в течение нескольких минут, когда оно не удается.

Но в последнее время даже этот сценарий не может завершить.

Одна проблема заключается в том, что она, кажется, игнорирует -C -часть, поэтому она не «продолжает» сегмент после повторной попытки. Кажется, он усекает соответствующий временный файл и запускается с начала после каждого сбоя. (Я думаю, что --rangeи -Cпараметры нельзя использовать вместе.)

Другая проблема заключается в том, что этот скрипт загружает все сегменты одновременно. Он не может иметь 300 сегментов, из которых только 10 загружаются одновременно.

Я думал о том, чтобы написать инструмент для загрузки в C # для этой конкретной цели, но если есть существующий инструмент или если команда curl могла бы работать должным образом с другими параметрами, то я мог бы сэкономить некоторое время.

ОБНОВЛЕНИЕ 1: Дополнительная информация: Функцию параллельной загрузки не следует удалять, поскольку они имеют ограничение полосы пропускания (80–120 Кбайт / с, в основном 80) на соединение, поэтому 10 соединений могут вызвать ускорение в 10 раз. Я должен закончить загрузку файла через 1 час, потому что файл генерируется каждый час.

lftp( Википедия ) хорош для этого. Он поддерживает несколько протоколов, может загружать файлы, используя несколько параллельных параллельных соединений (полезно, когда существует большая потеря пакетов, не вызванная перегрузкой), и может автоматически возобновлять загрузку. Это также сценарий.

Здесь, включая тонкую настройку, которую вы придумали (кредиты вам):

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"'

Я не могу проверить это для вас в вашей ситуации, но вы не должны использовать --rangeс -C -. Вот что говорит справочная страница на эту тему:

Используйте, -C -чтобы сказать, curlчтобы автоматически выяснить, где / как возобновить перевод. Затем он использует заданные файлы вывода / ввода, чтобы выяснить это.

Попробуйте это вместо этого:

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

Я также настоятельно рекомендую вам всегда заключать в кавычки переменные, чтобы оболочка не пыталась их проанализировать. (Рассмотрим URL https://example.net/param1=one&param2=two, где оболочка будет разделять значение в &.)

Кстати, 120 КБ / с - это примерно 1,2 МБ / с, что является типичной скоростью загрузки xDSL во многих частях мира. 10 секунд на МБ, так что чуть меньше часа для всего файла. Не так медленно, хотя я ценю, что вас больше заботит надежность, а не скорость.

Может быть, вам повезет больше с wget --continue:

wget --continue ${URL}

Смотрите также https://www.cyberciti.biz/tips/wget-resume-broken-download.html

За пределами коробки: наденьте повязку и используйте битторрент. Сделайте размер блока маленьким, когда создаете торрент. Очевидно, что зашифруйте файл, чтобы любой, кто нашел торрент, не получил ничего полезного.

У меня была такая же проблема в моей предыдущей работе (за исключением 300 ГБ + резервных копий базы данных вне офиса при нестабильном (из офиса) соединении). У пользователей возникли серьезные проблемы с загрузкой файла больше, чем ок. 1 ГБ до отключения соединения. Так как они использовали стандартный файл Windows для копирования / вставки через RDP-соединение, неудивительно.

Одна вещь, которую я обнаружил, состояла в том, что наши настройки VPN полностью не соответствовали настройкам сети (в основном длина MTU). Во-вторых, копировщик файлов Windows НЕ предназначен для копирования через Интернет.

Моим первым решением был простой FTP-сервер, однако он не решал проблему времени передачи (часто 3-4 часа на нашем соединении).

Мое второе решение состояло в том, чтобы использовать Syncthing для отправки файлов непосредственно на собственный NAS. Каждую ночь после завершения резервного копирования Syncthing отправлял все необходимое нам обратно в NAS-офис в офисе. Мало того, что была решена проблема с временем передачи более 3 часов, мне пришлось сэкономить 1-2 часа на доставке данных в случае кризиса. Каждое утро в 8 часов утра файлы будут обновляться на NAS, и у нас будут готовые резервные копии. Даже с огромными файлами (однажды база данных почти 700 ГБ) мне еще не приходилось испытывать какие-либо повреждения файлов или другие проблемы ...

Синхронизация очень проста в настройке и управлении, она доступна для всех платформ (даже телефонов) и имеет очень хорошую обработку плохих соединений. Если соединение не удается, Синхронизация просто ждет несколько минут и пытается снова.

Вам нужна локальная папка для синхронизации, но ваши файлы будут доступны почти сразу после их обновления.

Еще одна хорошая особенность синхронизации состоит в том, что она может быть настроена только на синхронизацию изменений в файле (как в дифференциальной резервной копии) ... возможно, решая часть проблемы с пропускной способностью.

Вы можете рассмотреть решение старой школы для перемещения файлов по паршивому соединению - zmodem .

Это было разработано еще тогда, когда 2400 бод модемов с людьми, снимающими телефоны и разрывающими соединение, были нормой. Может быть стоит попробовать.

Вы можете попробовать использовать Kermit :

Функция, которая отличает протокол Kermit от большинства других, заключается в его широком диапазоне настроек, позволяющих адаптировать к любому виду и качеству соединения между любыми двумя типами компьютеров - длиной пакета, кодированием пакета, размером окна, набором символов, методом обнаружения ошибок, тайм-аутами. паузы. Большинство других протоколов предназначены для работы только с определенными типами или качествами соединений и / или между определенными типами компьютеров или подобных файловых систем, и, следовательно, работают плохо (или не работают вообще) в других местах и ​​предлагают мало методов адаптации для незапланированных для ситуаций. Kermit, с другой стороны, позволяет добиться успешной передачи файлов и максимально возможной производительности при любом подключении ».