Baixar arquivo grande em conexão ruim

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 / s) interrompe aleatoriamente após 10-120 segundos. (É uma rede de uma grande empresa. Entramos em contato com os administradores (trabalhando na Índia) várias vezes, mas eles não podem ou não querem fazer nada.) O problema pode estar nos 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 10porque a conexão geralmente trava por alguns minutos quando falha.

Mas recentemente, mesmo esse script não pode ser concluído.

Um problema é que ele parece ignorar a -C -peça e, portanto, 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 o --rangee as -Copções não podem ser utilizados em conjunto.)

O outro problema é que esse script baixa todos os segmentos ao mesmo tempo. Ele 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 esse fim específico, mas se houver uma ferramenta existente ou se o comando curl funcionar adequadamente com parâmetros diferentes, eu poderia 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 / 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 a cada hora.

lftp( Wikipedia ) é bom para isso. Ele suporta vários protocolos, pode baixar arquivos usando várias conexões paralelas simultâneas (útil quando 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ê):

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

Não posso testar isso na sua situação, mas você não deve usá --range-lo -C -. Aqui está o que a página de manual tem a dizer sobre o assunto:

Use -C -para dizer curlpara descobrir automaticamente onde / como retomar a transferência. Em seguida, ele usa os arquivos de saída / entrada fornecidos para descobrir isso.

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 fortemente que você sempre aspasse suas variáveis ​​para que o shell não tente analisá-las. (Considere um URL https://example.net/param1=one&param2=two, onde o shell dividiria o valor em &.)

Aliás, 120 KB / s é de aproximadamente 1,2 Mb / s, que é uma velocidade de upload xDSL típica em muitas partes do mundo. 10 segundos por MB, 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.

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

wget --continue ${URL}

Consulte 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 pessoa que encontre o torrent não obtenha nada útil.

Eu tive o mesmo problema no meu trabalho anterior (exceto com mais de 300 GB de backups de bancos de dados externos em uma conexão instável (do escritório)). Os usuários tiveram sérios problemas ao baixar arquivos maiores que aprox. 1 GB antes da conexão ter saído. 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, no entanto, 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 o Syncthing para enviar os arquivos diretamente para um NAS interno . Todas as noites após a conclusão dos backups, a Syncthing enviava tudo o que precisávamos para um NAS no escritório. Não apenas o problema do tempo de transmissão de mais de 3 horas foi resolvido, mas fui poupado de 1 a 2 horas para enviar os dados se houvesse uma crise. Às 8h todas as manhãs, os arquivos seriam atualizados no NAS e tínhamos nossos backups prontos. Mesmo com arquivos enormes (em um ponto, um banco de dados de quase 700 GB), ainda estou com problemas de corrupção de arquivos ou outros problemas ...

O Syncthing é muito fácil de configurar e gerenciar, disponível para todas as plataformas (inclusive telefones) e possui um ótimo manuseio de 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 a sincronização é que ela pode ser configurada para sincronizar apenas as alterações no arquivo (como em um backup diferencial) ... possivelmente resolvendo uma parte do seu problema de largura de banda.

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

Isso foi desenvolvido quando 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 :

O recurso que distingue o protocolo Kermit da maioria dos outros é sua ampla variedade de configurações para permitir a adaptação a qualquer tipo e qualidade de conexão entre dois tipos de computador - tamanho do pacote, codificação de pacotes, tamanho da janela, conjunto de caracteres, método de detecção de erros, tempos limite , faz uma pausa. A maioria dos outros protocolos é projetada para funcionar apenas em certos tipos ou qualidades de conexões e / ou entre certos tipos de computadores ou sistemas de arquivos semelhantes e, portanto, funciona mal (ou não existe) em outros lugares e oferece poucos ou nenhum método para se adaptar a não planejado. -para situações. O Kermit, por outro lado, permite alcançar uma transferência bem-sucedida de arquivos e o desempenho mais alto possível em qualquer conexão ".