Quando tento baixar um arquivo via HTTP, os downloads às vezes param após cerca de 30 MB. As taxas de download desce para 0 B / s e nenhum dado continua chegando. Quando eu paro o download e continuo novamente, o download ainda trava. Mas quando eu baixar novamente do byte 0 novamente, tudo funciona bem até 30 MB quando ele pára novamente. Às vezes, depois de algumas horas, só funciona novamente sem problemas. A posição no arquivo quando o download pára é variável, mas a maior parte do tempo é em torno de 30 a 35 MB.
Como gerenciador de downloads, eu uso o wget. O mesmo comportamento acontece com o uso de curl e outros gerenciadores de download. O erro ocorre independentemente do servidor do qual faço o download. Eu também observei esse erro em outros computadores Linux na minha rede. Todos os computadores da minha rede executam o Gentoo Linux no x86.
Todas as conexões de internet na minha rede passam por um servidor na minha rede que executa um proxy Squid transparente na porta 80. Esse servidor está conectado a um roteador, que é um Speedport W 700V da Deutsche Telekom AG. Esse roteador está conectado à internet usando ADSL, com velocidade de 448 kbit / s e 96 kbit / s.
Tenho quase certeza de que meu proxy transparente não é o problema. Eu desliguei isso sem resolver o problema. Também conectei o roteador diretamente via WLAN sem resolver o problema. Eu também tentei fazer o download de outra porta via HTTP. Além disso, tentei fazer o download do arquivo usando o IPv6 com um túnel gateway6 do meu computador, o que resultou exatamente no mesmo problema.
Agora o mais estranho é que tudo funciona bem usando FTP e HTTPS (também com o wget no mesmo computador). Ainda mais estranho: quando eu retomar o download que paira sobre HTTP usando FTP ou HTTPS, baixe alguns bytes dessa forma, pare o wget e volte a usar HTTP, ele carrega os dados novamente! Mas depois de alguns MB, ele pode parar novamente. Infelizmente, os arquivos baixados dessa maneira estão sempre quebrados (a soma MD5 não está correta), portanto, em algum momento, deve ter havido dados falsos. Eu tentei procurar por mensagens de erro HTML no arquivo baixado, mas grep -i html não encontra nada. (Eu não consigo pensar em uma maneira de procurar por mensagens de erro HTML compactadas com GZIP no arquivo, então eu não tentei isso.)
Eu tentei usar strace no wget quando ele não conseguiu retomar um download, você pode encontrar toda a saída em pastebin . As linhas importantes são repetidas a cada segundo:
clock_gettime(CLOCK_MONOTONIC, {326102, 62176435}) = 0
) = 1
write(2, "78% [++++++++++++++++++++++++++++"..., 19578% [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ] 110,683,685 --.-K/s ) = 195
select(4, [3], NULL, NULL, {0, 949999}) = 0 (Timeout)
Eu não tenho absolutamente nenhuma idéia do que poderia ser o motivo deste problema. Parece que o que causa o problema fala HTTP. Parece falar HTTP que inteligentemente o reconhece em um túnel IPv6 sobre IPv4. Mas o que poderia ser e por que isso acontece apenas às vezes? A outra possibilidade seria que há um problema no meu computador que é o mesmo em outros computadores Gentoo Linux também.
Alguém já teve algum problema? Qual poderia ser o motivo e onde eu tenho que continuar investigando para descobrir mais sobre o assunto?
Atualização:
Acabei de me deparar com o problema novamente e tentei retomar o download pela WLAN do roteador e, dessa vez, funcionou. Talvez eu tenha feito algo errado durante meus últimos testes com a WLAN. Agora, talvez o meu servidor proxy transparente seja de fato o problema. É um servidor proxy Squid muito básico que não armazena nada em cache. Talvez o fato seja interessante que um segundo proxy Squid seja executado no mesmo computador em outra porta.
Atualização:
Um download parou novamente e desta vez eu desliguei todas as configurações do firewall e parei todos os servidores proxy. Eu não retomei o download do meu servidor de rede, que está diretamente conectado ao roteador. Então, meu servidor proxy definitivamente não é a causa do problema. Vou tentar atualizar o firmware do meu roteador agora, embora eu não tenha acesso de administrador a ele. Eu vou ver o que posso fazer.
Atualização:
Atualizar para o firmware mais recente do meu roteador não ajudou. Não vejo outra possibilidade além de ser a falha do meu provedor. Minha "solução" é agora para tunelar todo o tráfego através de um servidor SSH em algum outro lugar.
Essa postagem é realmente antiga e toda a infraestrutura de rede foi substituída por muito tempo, mas eu ainda queria postar a solução, que eu não publiquei no dia.
O problema foi causado pela placa de rede que conectou meu servidor de rede ao roteador. Substituir a placa resolveu o problema. Não sei qual foi exatamente o problema, deve ter sido um bug de firmware causado por algumas sequências de bytes específicas ou por outras condições específicas.
Even more strange: when I resume the download that hanged over HTTP using FTP or HTTPS, download a few bytes that way, stop wget and then resume again using HTTP, it loads data again! But after a few MB, it may stop again. Unfortunately, files downloaded that way are always broken (the MD5 sum is not correct)
Isso grita "proxy quebrado" O protocolo para retomar um download HTTP não é de forma alguma complicado (é apenas um cabeçalho extra), mas isso é exatamente o tipo de coisa que um proxy quebrado estaria bagunçando.
Aposto que se você tentar fazer o download de um arquivo grande usando o wget, espere ele falhar e, em seguida, execute o wget -c mudando o http para https, ele será retomado muito bem.
Tags networking wget linux http