Descargue el archivo grande a través de una mala conexión

30

¿Existe una herramienta existente que se pueda usar para descargar archivos grandes a través de una mala conexión?

Tengo que descargar regularmente un archivo relativamente pequeño: 300 MB, pero la conexión TCP lenta (80-120 KBytes / seg) se rompe aleatoriamente después de 10-120 segundos. (Es la red de una gran empresa. Contactamos a sus administradores (que trabajan desde India) varias veces, pero no pueden o no quieren hacer nada). El problema podría estar en sus servidores proxy / balanceadores de carga inversos.

Hasta ahora, utilizaba una versión modificada de pcurl: https://github.com/brunoborges/pcurl

Cambié esta línea:

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

a esto:

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

Tuve que agregar --speed-limit 2048 --speed-time 10porque la conexión casi siempre se cuelga durante minutos cuando falla.

Pero recientemente, incluso este script no se puede completar.

Un problema es que parece ignorar la -C -parte, por lo que no "continúa" el segmento después de un reintento. Parece truncar el archivo temporal relacionado y comenzar desde el principio después de cada error. (Creo que el --rangey las -Copciones no se pueden utilizar juntos.)

El otro problema es que este script descarga todos los segmentos al mismo tiempo. No puede tener 300 segmentos, de los cuales solo 10 se descargan a la vez.

Estaba pensando en escribir una herramienta de descarga en C # para este propósito específico, pero si hay una herramienta existente, o si el comando curl podría funcionar correctamente con diferentes parámetros, entonces podría dedicar algo de tiempo.

ACTUALIZACIÓN 1: Información adicional: la funcionalidad de descarga paralela no debe eliminarse, ya que tienen un límite de ancho de banda (80-120 Kbytes / seg, principalmente 80) por conexión, por lo que 10 conexiones pueden causar una aceleración de 10 veces. Tengo que terminar la descarga del archivo en 1 hora, porque el archivo se genera cada hora.

curl http download

— Gatito agazapado
fuente

44

¿Es la única opción para acceder a los archivos a través de FTP / HTTP? ¿No puede usar algo como rsync(que le permitirá reiniciar las transferencias)? lftpTambién permite reiniciar automáticamente las transmisiones.

— Kusalananda

Sí, restringieron todo el acceso a HTTPS a sus servidores hace algunos años. Por cierto, el servidor permite reiniciar en una posición específica, pcurl hace uso de eso.

— Crouching Kitten

1

¿Está buscando una herramienta de línea de comandos para secuencias de comandos? Porque de lo contrario, simplemente usaría FileZilla o un cliente ftp / sftp similar que admita reiniciar una descarga.

— Bakuriu

55

"un archivo relativamente pequeño: 300 MB" Ah, forma de hacerme sentir viejo :)

— Lightness compite con Monica el

44

Además, wow, eso es ... una red espantosa.

— Lightness compite con Monica el

33

lftp( Wikipedia ) es bueno para eso. Admite varios protocolos, puede descargar archivos usando varias conexiones paralelas simultáneas (útil cuando hay mucha pérdida de paquetes no causada por congestión) y puede reanudar automáticamente las descargas. También es programable.

Aquí, incluido el ajuste fino que se le ocurrió (créditos para usted):

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

— Stéphane Chazelas
fuente

Gracias. Intenté esto, pero no parece usar conexiones paralelas:

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'

— Crouching Kitten

Oh, cuando eliminé la configuración "net: timeout", se volvió paralela. Pero se ralentiza después de un tiempo. Creo que porque las conexiones comienzan a "colgarse".

— Crouching Kitten

1

Funciona perfectamente con la net:idleconfiguración. ¡Gracias! Agregaré mi solución a la pregunta.

— Crouching Kitten

1

Tenga en cuenta que lftp admite torrent como el protocolo de transferencia subyacente. Úsalo. Todos los demás protocolos que admite no admiten la detección / corrección de errores por fragmento y dependen de TCP para proporcionar la detección de errores. Tenga en cuenta que torrent utiliza la detección de errores TCP, pero además verifica el hash sha1 de todo su archivo y también cada bloque transferido a través de la red. En mi experiencia, una película de 4GB torrentada a través de una red 4G generalmente tiene alrededor de dos errores de verificación de hash, esto significa que TCP consideró que el paquete recibido estaba libre de errores a pesar de que estaba dañado

— slebetman

1

@slebetman, aquí el OP usa HTTPS. TLS proporciona una comprobación de integridad adicional (sobre la suma de comprobación débil de TCP) a través de HMAC. También HTTP tiene soporte para contenido de suma de comprobación o fragmentos con los encabezados Content-MD5y Digest(aunque no sé si los lftpadmite o si se usarían en el caso del OP). En cualquier caso, no parece que torrent sea una opción para el OP.

— Stéphane Chazelas

12

No puedo probar esto en tu situación, pero no deberías usarlo --rangecon -C -. Esto es lo que la página del manual tiene que decir sobre el tema:

Use -C -para indicar curlpara averiguar automáticamente dónde / cómo reanudar la transferencia. Luego usa los archivos de salida / entrada dados para resolver eso.

Intenta esto en su lugar:

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

También recomiendo encarecidamente que siempre doble comillas sus variables para que el shell no intente analizarlas. (Considere una URL https://example.net/param1=one&param2=two, donde el shell dividiría el valor en &).

Por cierto, 120 KB / s es aproximadamente 1.2 Mb / s, que es una velocidad de carga xDSL típica en muchas partes del mundo. 10 segundos por MB, un poco menos de una hora para todo el archivo. No es tan lento, aunque aprecio que estés más preocupado por la confiabilidad que por la velocidad.

— roaima
fuente

2

Gracias. Este enfoque funcionaría, pero es lento, porque no se descarga en paralelo. Tienen un límite de velocidad por conexión, y tengo que finalizar la descarga en 1 hora, ya que generan el archivo cada hora. Actualizando la pregunta.

— Crouching Kitten

8

Quizás tengas más suerte con wget --continue:

wget --continue ${URL}

Ver también https://www.cyberciti.biz/tips/wget-resume-broken-download.html

— Alex338207
fuente

4

Fuera de la caja: colóquese un parche en el ojo y use bittorrent. Haz el tamaño de bloque pequeño cuando crees el torrent. Obviamente, encripte el archivo para que cualquier otra persona que encuentre el torrent no obtenga nada útil.

— Loren Pechtel
fuente

1

Es la rara corporación que distribuye internamente archivos a través de torrent.

— RonJohn

55

Exactamente. Incluso si la conexión es realmente mala y el archivo de alguna manera se dañó, debería funcionar bien. CONSEJO PROFESIONAL: Cifrarlo, renombrarlo como 'KimKardashianNude.mp4' y dejar que miles de personas lo ayuden con la conexión. Copia de seguridad distribuida y automática de forma gratuita. :)

— Eric Duminil

Como dijo el propio Linus: "Solo los débiles usan copia de seguridad en cinta: los hombres de verdad solo cargan sus cosas importantes en ftp y dejan que el resto del mundo lo refleje;)"

— ivanivan

@RonJohn Sé que no se usa comúnmente, pero eso no significa que no se pueda usar. El protocolo bittorrent es muy bueno para soportar malas conexiones.

— Loren Pechtel

@LorenPechtel una orden de trabajo para RISK para aprobar los puertos, un WO para que el NOC abra los puertos y WO para que los equipos de Linux y Windows instalen los clientes torrent, y otro WO para monitorearlos a todos de modo que solo se estén procesando los archivos aprobados transferido Y nada de eso tiene en cuenta HIPPA, PCI o el hecho de que un archivo que se supone que va del punto A al punto B ahora va del punto A a los puntos C, D, E, F, G, H, I y J antes llegar al punto B. RIESGO lo desaprobará por esa misma razón.

— RonJohn

3

Tuve el mismo problema en mi trabajo anterior (excepto con copias de seguridad de bases de datos externas de 300GB + en una conexión inestable (desde la oficina)). Los usuarios tuvieron graves problemas para descargar un archivo de más de aprox. 1 GB antes de que se desconectara la conexión. Dado que utilizaron el archivo estándar de copiar / pegar de Windows a través de una conexión RDP, no es de extrañar.

Una cosa que descubrí fue que nuestra configuración de VPN no coincidía completamente con la configuración de la red (principalmente la longitud de MTU). La segunda cosa es que la copiadora de archivos de Windows NO está hecha para copiar cosas a través de Internet.

Mi primera solución fue un servidor FTP simple, sin embargo, no resolvió el problema del tiempo de transmisión (a menudo 3-4 horas en nuestra conexión).

Mi segunda solución fue usar Syncthing para enviar los archivos directamente a un NAS interno. Cada noche, después de completar las copias de seguridad, Syncthing enviaba todo lo que necesitábamos a un NAS en la oficina. No solo se resolvió el problema del tiempo de transmisión de más de 3 horas, sino que se me ahorraron las 1-2 horas para enviar los datos en caso de crisis. A las 8 de la mañana todas las mañanas, los archivos se actualizarían en el NAS, y teníamos nuestras copias de seguridad listas. Incluso con archivos enormes (en un momento una base de datos de casi 700 GB), todavía tengo que experimentar cualquier corrupción de archivos u otros problemas ...

Syncthing es muy fácil de configurar y administrar y está disponible para todas las plataformas (incluso teléfonos), y tiene un muy buen manejo de malas conexiones ... si la conexión falla, Syncthing simplemente espera unos minutos e intenta nuevamente.

Necesitas una carpeta local para sincronizar las cosas, pero tus archivos estarán disponibles casi tan pronto como se actualicen.

Otra cosa buena sobre la sincronización es que se puede configurar para sincronizar solo los cambios en el archivo (como en una copia de seguridad diferencial) ... posiblemente resolviendo una parte de su problema de ancho de banda.

— Tylon Foxx
fuente

+1 por mencionar la sincronización - una alternativa de google drive / dropbox para copias de seguridad

— Edward Torvalds

1

Puede considerar una solución de la vieja escuela para mover archivos a través de una conexión pésima: zmodem .

Esto se desarrolló cuando 2400 módems en baudios con personas que levantaban los teléfonos y bombardeaban la conexión era la norma. Podría valer la pena probar.

— AburridoVer
fuente

0

Podrías intentar usar Kermit :

La característica que distingue el protocolo Kermit de la mayoría de los demás es su amplia gama de configuraciones para permitir la adaptación a cualquier tipo y calidad de conexión entre dos tipos de computadora: longitud de paquete, codificación de paquete, tamaño de ventana, juego de caracteres, método de detección de errores, tiempos de espera pausas La mayoría de los otros protocolos están diseñados para funcionar solo en ciertos tipos o calidades de conexiones, y / o entre ciertos tipos de computadoras o sistemas de archivos similares, y por lo tanto funcionan mal (o no funcionan) en otros lugares y ofrecen pocos o ningún método para adaptarse a los no planificados -para situaciones. Kermit, por otro lado, le permite lograr una transferencia de archivos exitosa y el mayor rendimiento posible en cualquier conexión ".

— Wallace Howery
fuente