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. (É a rede de uma grande empresa. Entramos em contato com seus administradores (trabalhando da Í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 usei uma versão modificada do pcurl: https://github.com/brunoborges/pcurl
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 geralmente trava por minutos quando falha.
Mas, recentemente, nem mesmo esse script pode ser concluído.
Um problema é que ele parece ignorar a -C -
parte, então não "continua" o segmento após uma nova tentativa. Parece truncar o arquivo temporário relacionado e começar do início após cada falha. (Acho que --range
as -C
opções e não podem ser usadas juntas.)
O outro problema é que esse script baixa 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 funcionar corretamente com parâmetros diferentes, posso poupar algum tempo.
ATUALIZAÇÃO 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 / seg, principalmente 80) por conexão, portanto, 10 conexões podem causar um aumento de velocidade de 10 vezes. Tenho que terminar o download do arquivo em 1 hora, pois o arquivo é gerado de hora em hora.
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.Aqui, incluindo o ajuste fino que você criou (créditos para você):
Não posso testar isso para você na sua situação, mas você não deve usar
--range
com-C -
. Aqui está o que a página de manual tem a dizer sobre o assunto:Tente isso em vez disso:
Eu também recomendo fortemente que você sempre coloque aspas duplas em suas variáveis para que o shell não tente analisá-las. (Considere uma URL
https://example.net/param1=one¶m2=two
, onde o shell dividiria o valor em&
.)Aliás, 120 KB/s é aproximadamente 1,2 Mb/s, que é uma velocidade de upload xDSL típica em muitas partes do mundo. 10 segundos por MB, ou seja, 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.
Talvez você tenha mais sorte com
wget --continue
:Veja também https://www.cyberciti.biz/tips/wget-resume-broken-download.html
Fora da caixa: coloque um tapa-olho e use bittorrent. Reduza o tamanho do bloco ao criar o torrent. Obviamente, criptografe o arquivo para que qualquer outra pessoa que encontre o torrent não receba nada de útil.
Eu tive o mesmo problema em meu trabalho anterior (exceto com backups de banco de dados externos de 300 GB ou mais em uma conexão instável (do escritório). Os usuários tiveram problemas graves para baixar arquivos maiores que aprox. 1 GB antes da conexão cair. 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 do MTU). A segunda coisa é que a copiadora de arquivos do Windows NÃO foi feita para copiar coisas pela Internet.
Minha primeira solução foi um servidor FTP simples, porém, não resolveu o problema do tempo de transmissão (geralmente 3-4 horas em nossa conexão).
Minha segunda solução foi usar o 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 de volta para um NAS no escritório. Não apenas o problema de mais de 3 horas de tempo de transmissão foi resolvido, mas também fui poupado de 1 a 2 horas para enviar os dados se houvesse uma crise. Todas as manhãs, às 8h, os arquivos eram atualizados no NAS e tínhamos nossos backups prontos. Mesmo com arquivos enormes (a certa altura, um banco de dados de quase 700 GB), ainda não experimentei nenhum arquivo corrompido ou outros problemas...
O Syncthing é muito fácil de configurar e gerenciar e está disponível para todas as plataformas (até mesmo telefones) e lida muito bem com conexões ruins. Se a conexão falhar, o Syncthing simplesmente espera alguns minutos e tenta novamente.
Você precisa de uma pasta local para sincronizar as coisas, mas seus arquivos estarão disponíveis quase 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 parte do seu problema de largura de banda.
Você pode considerar uma solução tradicional para mover arquivos em uma conexão ruim - zmodem .
Isso foi desenvolvido quando os modems de 2400 baud com pessoas pegando os telefones e bombardeando a conexão eram a norma. Pode valer a pena tentar.
Você pode tentar usar o Kermit :