Faça o download de um arquivo grande em uma conexão incorreta

Question

Existe uma ferramenta existente, que pode ser usada para baixar arquivos grandes em uma conexão ruim?

Eu tenho que baixar regularmente um arquivo relativamente pequeno: 300 MB, mas a conexão TCP lenta (80-120 KBytes / seg) quebra aleatoriamente após 10-120 segundos. (É uma rede de grande empresa. Entramos em contato com seus administradores (trabalhando na Índia) várias vezes, mas eles não podem ou não querem fazer nada.) O problema pode estar em seus proxies reversos / balanceadores de carga.

Até agora eu usei uma versão modificada do pcurl: link

Eu mudei esta linha:

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

para isso:

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

Eu tive que adicionar --speed-limit 2048 --speed-time 10 porque a conexão é interrompida por minutos quando falha.

Mas recentemente nem mesmo esse script pode ser concluído.

Um problema é que parece ignorar a parte -C - , por isso não "continua" o segmento após uma nova tentativa. Parece truncar o arquivo temporário relacionado e iniciar desde o início após cada falha. (Acho que as opções --range e -C não podem ser usadas juntas.)

O outro problema é que esse script faz o download de todos os segmentos ao mesmo tempo. Não pode ter 300 segmentos, dos quais apenas 10 estão sendo baixados por vez.

Eu estava pensando em escrever uma ferramenta de download em C # para essa finalidade específica, mas se houver uma ferramenta existente ou se o comando curl puder funcionar corretamente com parâmetros diferentes, eu poderia poupar algum tempo.

UPDATE 1: Informações adicionais: A funcionalidade de download paralelo não deve ser removida, porque eles têm um limite de largura de banda (80-120 Kbytes / s, principalmente 80) por conexão, portanto 10 conexões podem causar uma aceleração de 10 vezes. Eu tenho que terminar o download do arquivo em 1 hora, porque o arquivo é gerado por hora.

    

Answer 1

lftp ( Wikipedia ) é bom para isso. Ele suporta vários protocolos, pode baixar arquivos usando várias conexões paralelas simultâneas (útil onde há muita perda de pacotes não causada por congestionamento) e pode retomar downloads automaticamente. Também é programável por scripts.

Aqui, incluindo o ajuste fino que você criou (créditos para você):

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

    

Answer 2

Eu não posso testar isso para você na sua situação, mas você não deve usar --range com -C - . Veja o que o man page tem a dizer sobre o assunto:

Use -C - to tell curl to automatically find out where/how to resume the transfer. It then uses the given output/input files to figure that out.

Tente isso:

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

Eu também recomendo strongmente que você sempre cite duas vezes suas variáveis para que o shell não tente analisá-las. (Considere um URL https://example.net/param1=one&param2=two , em que o shell dividiria o valor em & .)

Por acaso, 120 KB / s é aproximadamente 1,2 Mb / s, o que é uma velocidade típica de upload xDSL em muitas partes do mundo. 10 segundos por MB, portanto, um pouco menos de uma hora para o arquivo inteiro. Não é tão lento, embora eu aprecie que você esteja mais preocupado com a confiabilidade do que com a velocidade.

    

Answer 3

Talvez você tenha mais sorte com wget --continue :

wget --continue ${URL}

Veja também o link

    

Answer 4

Fora da caixa: coloque um tapa-olho e use o bittorrent. Faça o tamanho do bloco pequeno quando você cria o torrent. Obviamente, criptografe o arquivo para que qualquer pessoa que encontre o torrent não consiga nada útil.

    

Answer 5

Eu tive o mesmo problema em meu trabalho anterior (exceto com backups de banco de dados externos de 300 GB + em uma conexão instável (do escritório)). Os usuários tiveram problemas graves ao baixar arquivos maiores que aprox. 1 GB antes de a conexão ficar bloqueada. Como eles usaram o arquivo padrão de copiar / colar do Windows em uma conexão RDP, não é de admirar.

Uma coisa que descobri foi que nossas configurações de VPN eram completamente incompatíveis com a configuração da rede (principalmente o comprimento da MTU). A segunda coisa é que a copiadora de arquivos do Windows NÃO é feita para copiar coisas pela internet.

Minha primeira solução foi um servidor FTP simples, mas não resolveu o problema do tempo de transmissão (geralmente de 3 a 4 horas em nossa conexão).

Minha segunda solução foi usar Syncthing para enviar os arquivos diretamente para um NAS interno. Todas as noites, após a conclusão dos backups, o Syncthing enviava tudo o que precisávamos para um NAS no escritório. Não só foi resolvido o problema de mais de 3 horas de tempo de transmissão, mas fui poupado das 1-2 horas para enviar os dados se houvesse uma crise. Todas as manhãs, às 8 da manhã, os arquivos seriam atualizados no NAS, e nós tínhamos nossos backups prontos. Mesmo com arquivos enormes (em um ponto, quase um banco de dados de 700GB), ainda não experimentei nenhuma corrupção de arquivos ou outros problemas ...

O Syncthing é muito fácil de configurar e gerenciar, e está disponível para todas as plataformas (até mesmo telefones) e tem um tratamento muito bom de conexões ruins. Se a conexão falhar, o Syncthing simplesmente aguarda alguns minutos e tenta novamente. p>

Você precisa de uma pasta local para sincronizar coisas, mas seus arquivos estarão disponíveis assim que forem atualizados.

Outra coisa boa sobre o syncthing é que ele pode ser configurado para sincronizar apenas as alterações no arquivo (como em um backup diferencial) ... possivelmente resolvendo uma parte do seu problema de largura de banda. / p>     

Answer 6

Você pode considerar uma solução antiga para mover arquivos por uma conexão ruim - zmodem .

Isso foi desenvolvido quando 2400 modems de transmissão com pessoas atendendo telefones e bombardeando a conexão era a norma. Poderia valer a pena tentar.

    

Answer 7

Você pode tentar usar o Kermit :

The feature that distinguishes Kermit protocol from most others is its wide range of settings to allow adaptation to any kind and quality of connection between any two kinds of computer — packet length, packet encoding, window size, character set, error-detection method, timeouts, pauses. Most other protocols are designed to work only on certain kinds or qualities of connections, and/or between certain kinds of computers or like file systems, and therefore work poorly (or not at all) elsewhere and offer few if any methods to adapt to unplanned-for situations. Kermit, on the other hand, allows you to achieve successful file transfer and the highest possible performance on any given connection."