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

30

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

Я должен регулярно загружать относительно небольшой файл: 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 час, потому что файл генерируется каждый час.

Крадущийся котенок
источник
4
Это единственная возможность доступа к файлам через FTP / HTTP? Вы не можете использовать что-то вроде rsync(что позволит вам перезапустить переводы)? lftpтакже позволяет автоматически перезапускать передачи.
Кусалананда
Да, они ограничивали весь доступ к HTTPS к своим серверам несколько лет назад. КСТАТИ сервер позволяет перезапустить с определенной позиции, pcurl использует это.
Крадущийся котенок
1
Вы ищете инструмент командной строки для сценариев? Потому что в противном случае я бы просто использовал FileZilla или аналогичный клиент ftp / sftp, который поддерживает перезапуск загрузки.
Бакуриу
5
"сравнительно небольшой файл: 300 МБ" Ах, способ заставить меня чувствовать себя старым :)
Гонки на легкость с Моникой
4
Кроме того, вау, это .. ужасная сеть.
Гонки на легкость с Моникой

Ответы:

33

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"'
Стефан Шазелас
источник
Спасибо. Я пробовал это, но похоже, что он не использует параллельные соединения:lftp -e 'set net:timeout 15; 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"; exit'
Крадущийся котенок
О, когда я удалил параметр "net: timeout", он стал параллельным. Но это замедляется через некоторое время. Я думаю, потому что соединения начинают "зависать".
Крадущийся котенок
1
Он отлично работает с net:idleнастройкой. Спасибо! Я добавлю свое решение вопроса.
Крадущийся котенок
1
Обратите внимание, что lftp поддерживает торрент в качестве основного протокола передачи. Используй это. Все остальные протоколы, которые он поддерживает, не поддерживают обнаружение / исправление ошибок для каждого блока и используют TCP для обеспечения обнаружения ошибок. Обратите внимание, что торрент использует обнаружение ошибок TCP, но поверх него проверяет хэш sha1 всего вашего файла, а также каждый блок, передаваемый по сети. По моему опыту, фильм 4ГБ, транслируемый по сети 4G, обычно имеет около двух ошибок проверки хеша - это означает, что TCP считал полученный пакет безошибочным, даже если он был поврежден
slebetman
1
@slebetman, здесь OP использует HTTPS. TLS обеспечивает дополнительную проверку целостности (через слабую контрольную сумму TCP) через HMAC. Также HTTP поддерживает checksuming содержания или ломтей с Content-MD5и Digestзаголовками (хотя я не знаю , если lftpносители тех или если они будут использоваться в случае с ФП в). В любом случае, это не похоже на то, что торрент будет вариантом для OP.
Стефан Шазелас
12

Я не могу проверить это для вас в вашей ситуации, но вы не должны использовать --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 секунд на МБ, так что чуть меньше часа для всего файла. Не так медленно, хотя я ценю, что вас больше заботит надежность, а не скорость.

roaima
источник
2
Спасибо. Этот подход будет работать, но он медленный, потому что он не загружается параллельно. У них есть ограничение скорости на соединение, и я должен закончить загрузку через 1 час, потому что они ежечасно генерируют файл. Обновление вопроса.
Крадущийся котенок
4

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

Лорен Печтель
источник
1
Это редкая корпорация, которая внутренне распространяет файлы через торрент.
RonJohn
5
В точку. Даже если соединение действительно плохое и файл каким-то образом поврежден, он должен работать нормально. PRO-TIP: зашифруйте его, переименуйте в KimKardashianNude.mp4 и позвольте тысячам людей помочь вам с подключением. Автоматическое, распределенное резервное копирование бесплатно! :)
Эрик Думинил
Как сказал сам Линус: «Только слабые люди используют резервное копирование на магнитную ленту: настоящие мужчины просто загружают свои важные материалы на ftp, и пусть весь мир отражает их;)»
ivanivan
@ RonJohn Я знаю, что это не часто используется, но это не значит, что его нельзя использовать. Протокол bittorrent очень хорошо справляется с плохими соединениями.
Лорен Печтел
@LorenPechtel Заказ на работу для RISK для утверждения портов, WO для NOC, чтобы открыть порты, и WO для команд Linux и Windows, чтобы установить торрент-клиенты, и еще одна WO, чтобы отслеживать их все, чтобы были только утвержденные файлы переданы. И ничто из этого не учитывает HIPPA, PCI или тот факт, что файл, который должен пройти из точки A в точку B, теперь перемещается из точки A в точки C, D, E, F, G, H, I и J до Попадание в пункт B. Риск не одобрит именно по этой причине.
RonJohn
3

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

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

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

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

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

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

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

Tylon Foxx
источник
+1 за упоминание синхронизации - альтернатива Google Drive / Dropbox для резервных копий
Эдвард Торвальдс
1

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

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

BoredBsee
источник
0

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

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

Уоллес Хоури
источник