Завантажте великий файл через погане з'єднання

Чи існує існуючий інструмент, який можна використовувати для завантаження великих файлів через погане з'єднання?

Мені доводиться регулярно завантажувати відносно невеликий файл: 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 ГБ бази даних) я ще не мав жодних пошкоджень файлів чи інших проблем ...

Syncthing дуже простий у налаштуванні та керуванні, і він доступний для всіх платформ (навіть телефонів) і має дуже гарне поводження з поганими з’єднаннями.

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

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

Ви можете розглянути рішення старої школи для переміщення файлів через паршиве з'єднання - zmodem .

Це було розроблено ще коли 2400 бод-модемів із людьми піднімали телефони та бомбардували зв’язок, було нормою. Можливо, варто спробувати.

Ви можете спробувати використати Kermit :

Особливістю, яка відрізняє протокол Kermit від більшості інших, є його широкий діапазон налаштувань, що дозволяє адаптуватись до будь-якого виду та якості зв'язку між будь-якими двома видами комп'ютерів - довжиною пакету, кодуванням пакета, розміром вікна, набором символів, методом виявлення помилок, тайм-аутами , паузи. Більшість інших протоколів розроблені для роботи лише на певних видах або якостях з'єднань та / або між певними типами комп'ютерів або подібних файлових систем, а тому працюють погано (або зовсім не є) в інших місцях і пропонують небагато, якщо якісь методи адаптуються до незапланованих -для ситуацій. Kermit, з іншого боку, дозволяє досягти успішної передачі файлів і максимально високої продуктивності на будь-якому даному з'єднанні. "