Unduh file besar melalui koneksi yang buruk

Apakah ada alat yang ada, yang dapat digunakan untuk mengunduh file besar melalui koneksi yang buruk?

Saya harus secara teratur mengunduh file yang relatif kecil: 300 MB, tetapi koneksi TCP yang lambat (80-120 KBytes / detik) terputus secara acak setelah 10-120 detik. (Ini jaringan perusahaan besar. Kami menghubungi admin mereka (bekerja dari India) beberapa kali, tetapi mereka tidak bisa atau tidak ingin melakukan apa pun.) Masalahnya mungkin dengan proxy terbalik / penyeimbang muatan.

Sampai sekarang saya menggunakan versi modifikasi pcurl: https://github.com/brunoborges/pcurl

Saya mengubah baris ini:

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

untuk ini:

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

Saya harus menambahkan --speed-limit 2048 --speed-time 10karena koneksi sebagian besar hanya hang selama beberapa menit ketika gagal.

Tetapi baru-baru ini bahkan skrip ini tidak dapat diselesaikan.

Satu masalah adalah tampaknya mengabaikan -C -bagian, sehingga tidak "melanjutkan" segmen setelah coba lagi. Tampaknya memotong file temp terkait, dan mulai dari awal setelah masing-masing gagal. (Saya pikir opsi --rangedan -Ctidak dapat digunakan bersama-sama.)

Masalah lainnya adalah skrip ini mengunduh semua segmen secara bersamaan. Tidak dapat memiliki 300 segmen, yang hanya 10 diunduh pada satu waktu.

Saya sedang berpikir untuk menulis alat pengunduhan dalam C # untuk tujuan khusus ini, tetapi jika ada alat yang ada, atau jika perintah curl dapat bekerja dengan baik dengan parameter yang berbeda, maka saya dapat meluangkan waktu.

UPDATE 1: Info tambahan: Fungsionalitas unduhan paralel tidak boleh dihapus, karena mereka memiliki batas bandwidth (80-120 Kbytes / detik, kebanyakan 80) per koneksi, sehingga 10 koneksi dapat menyebabkan 10 kali percepatan. Saya harus menyelesaikan pengunduhan file dalam 1 jam, karena file dihasilkan setiap jam.

lftp( Wikipedia ) bagus untuk itu. Ini mendukung sejumlah protokol, dapat mengunduh file menggunakan beberapa koneksi paralel bersamaan (berguna di mana ada banyak paket yang tidak disebabkan oleh kemacetan), dan dapat secara otomatis melanjutkan unduhan. Ini juga bisa skrip.

Di sini termasuk penyetelan halus yang Anda lakukan (kredit untuk Anda):

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

Saya tidak bisa menguji ini untuk Anda dalam situasi Anda, tetapi Anda tidak boleh menggunakannya --rangebersama -C -. Inilah yang dikatakan halaman manual tentang subjek:

Gunakan -C -untuk memberi tahu curlagar secara otomatis mencari tahu di mana / bagaimana melanjutkan transfer. Kemudian menggunakan file output / input yang diberikan untuk mencari tahu itu.

Coba ini sebagai gantinya:

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

Saya juga sangat menyarankan agar Anda selalu mengutip variabel Anda sehingga shell tidak akan mencoba untuk menguraikannya. (Pertimbangkan sebuah URL https://example.net/param1=one&param2=two, tempat shell akan membagi nilainya di &.)

Secara kebetulan, 120 KB / s adalah sekitar 1,2 Mb / s, yang merupakan kecepatan unggah xDSL pada banyak bagian dunia. 10 detik per MB, jadi sedikit di bawah satu jam untuk seluruh file. Tidak terlalu lambat, meskipun saya menghargai Anda lebih mementingkan keandalan daripada kecepatan.

Mungkin Anda lebih beruntung dengan wget --continue:

wget --continue ${URL}

Lihat juga https://www.cyberciti.biz/tips/wget-resume-broken-download.html

Di luar kotak: Kenakan eyepatch dan gunakan bittorrent. Buat ukuran blok kecil ketika Anda membuat torrent. Jelas, mengenkripsi file sehingga siapa pun yang menemukan torrent tidak mendapat manfaat apa pun.

Saya memiliki masalah yang sama pada pekerjaan saya sebelumnya (kecuali dengan 300GB + backup database di luar kantor pada koneksi yang tidak stabil (dari kantor)). Pengguna memiliki masalah serius mengunduh file yang lebih besar dari kira-kira. 1 GB sebelum koneksi terkoneksi. Karena mereka menggunakan file copy / paste standar Windows melalui koneksi RDP, tidak heran.

Satu hal yang saya temukan, adalah bahwa pengaturan VPN kami sepenuhnya tidak cocok dengan pengaturan jaringan (terutama panjang MTU). Yang kedua adalah bahwa mesin fotokopi file Windows TIDAK dibuat untuk menyalin barang-barang melalui internet.

Solusi pertama saya adalah server FTP sederhana, namun, itu tidak menyelesaikan masalah waktu transmisi (seringkali 3-4 jam pada koneksi kami).

Solusi kedua saya adalah menggunakan Syncthing untuk mengirim file langsung ke NAS internal . Setiap malam setelah cadangan selesai, Syncthing mengirim semua yang kami butuhkan kembali ke NAS di kantor. Tidak hanya masalah waktu transmisi 3+ jam diselesaikan, tetapi saya juga diberikan waktu 1-2 jam untuk mengirimkan data jika ada krisis. Pada jam 8 pagi setiap pagi, file-file akan diperbarui pada NAS, dan kami memiliki cadangan kami siap. Bahkan dengan file besar (pada satu titik database hampir 700GB), saya belum mengalami korupsi file atau masalah lain ...

Syncthing sangat mudah diatur dan dikelola dan tersedia untuk semua platform (bahkan telepon), dan memiliki penanganan koneksi buruk yang sangat baik .. jika koneksi gagal, Syncthing hanya menunggu beberapa menit dan mencoba lagi.

Anda memang perlu folder lokal untuk menyinkronkan sesuatu, tetapi file Anda akan tersedia segera setelah mereka diperbarui.

Hal baik lainnya tentang sinkronisasi, adalah bahwa hal itu dapat diatur untuk hanya menyinkronkan perubahan dalam file (seperti dalam cadangan diferensial) ... mungkin menyelesaikan bagian dari masalah bandwidth Anda.

Anda mungkin mempertimbangkan solusi old-school untuk memindahkan file melalui koneksi yang buruk - zmodem .

Ini dikembangkan kembali ketika 2400 modem baud dengan orang-orang mengangkat telepon dan membom koneksi adalah norma. Bisa dicoba.

Anda dapat mencoba menggunakan Kermit :

Fitur yang membedakan protokol Kermit dari kebanyakan yang lain adalah berbagai pengaturannya untuk memungkinkan adaptasi terhadap segala jenis dan kualitas koneksi antara dua jenis komputer - panjang paket, pengkodean paket, ukuran jendela, kumpulan karakter, metode deteksi kesalahan, batas waktu , jeda. Sebagian besar protokol lain dirancang untuk bekerja hanya pada jenis atau kualitas koneksi tertentu, dan / atau antara jenis komputer tertentu atau sistem file sejenis, dan karenanya bekerja dengan buruk (atau tidak sama sekali) di tempat lain dan menawarkan sedikit jika ada metode untuk beradaptasi dengan yang tidak direncanakan -Untuk situasi. Kermit, di sisi lain, memungkinkan Anda untuk mencapai transfer file yang sukses dan kinerja setinggi mungkin pada koneksi yang diberikan. "