O uTorrent faz com que o DNS pare de funcionar ocasionalmente

Ao usar o uTorrent, o DNS periodicamente pára de responder.

O problema parece não estar relacionado ao uso excessivo de largura de banda (como visto do roteador para o computador), mas pode estar relacionado a alguma forma de proteção contra inundação fornecida pelo roteador (mais conexões de entrada do roteador do que o Windows aceitará).

Como faço para que a rede funcione corretamente (embora ainda possa usar o uTorrent, é claro)?

clientes bittorent se conectam agressivamente aos pares ... e alguns roteadores interpretam isso como uma inundação de sincronização.

Conexões abertas

Quando o uTorrent é carregado e os uploads / downloads são pausados ​​(não interrompidos), ele mantém conexões abertas com seus pares. Enquanto isso, legiões de colegas da internet ainda tentarão se conectar a você para descobrir se você tem os bits que eles desejam.

Eventualmente, você atingirá o limite de conexão aberto imposto pelo seu sistema operacional (no Windows 7 são 10 conexões) e as conexões de novos clientes começarão a enfileirar no roteador.

Os clientes na fila verificarão agressivamente para ver se a conexão está livre. Essa pesquisa agressiva pode ser interpretada como um ataque de inundação de sincronização pelo roteador.

Soluções

• Reduza seu limite de conexão semiaberto no seu software bittorent abaixo do limite de conexão imposto pelo seu sistema operacional
• desative a proteção contra inundação de IP no seu roteador / modem.

Saturação da largura de banda

Além disso, com a conexão do uTorrent (ou qualquer tráfego em massa) sendo executada sem restrições, o canal de upload (e possivelmente download) alcança uso total, forçando algum tráfego de "manutenção" a ficar em segundo plano, o que acaba diminuindo a utilidade da rede.

Aqui está um exemplo:

1. O download em alta velocidade (torrent ou outro modo) satura o link a jusante.
2. O usuário tenta navegar para um site não visitado recentemente. O computador gera uma solicitação de informações de DNS para o site desejado. O "upload" da solicitação para o servidor DNS foi bem-sucedido (não desafiado pelo acesso ao canal upstream).
3. O servidor DNS responde (ou tenta), mas a resposta é interrompida ao tentar acessar a máquina do usuário porque o canal de download está saturado com o conteúdo do download, e como algo precisa ser descartado e o download é agressivo ao manter a velocidade, o A resposta do DNS é descartada (em algum momento antes de chegar ao roteador local).

O mesmo pode acontecer se o upload for irrestrito. Com o upload saturado, os pacotes conhecidos como TCP-ACK (que são enviados como respostas do tipo "Ei, recebi o pacote xyz com êxito") são interrompidos, interrompendo os downloads, fazendo com que a navegação na Web fique muito irregular.

Soluções

• Descubra quais são os recursos máximos da sua conexão (para cima e para baixo, individualmente) e defina a velocidade máxima dos seus clientes de transferência em massa para não usar mais do que cerca de 80% dessa velocidade. Isso deixará espaço para coisas como pacotes DNS e TCP-ACK ignorarem o tráfego em massa e serem tratados rapidamente.
• Use um roteador capaz de lidar com a modelagem de tráfego, de modo que determinado tráfego (DNS, Ping IMCP, TCP-ACK) possa ser priorizado antes de outras formas de tráfego, e algumas formas de tráfego (torrent em particular) podem ser priorizadas. Este é o meu método preferido. Isso pode oferecer o benefício adicional de permitir que o canal completo para cima e para baixo seja utilizável no tráfego de torrent quando o tráfego de alta prioridade não o desafia.
• Use uma combinação de 1 e 2 para restringir o tráfego "que se comporta mal".

Se estiver interessado em obter mais informações sobre o tráfego que molda as distribuições Linux / BSD, o MonoWall e o IPCop têm boas informações.

Quando tenho algo assim, o Wireshark é meu melhor amigo.

Mas primeiro é bom perceber essas três coisas:

• O fato de o ping estar funcionando não significa que o DNS (ou qualquer outro serviço) esteja funcionando e vice-versa.

  Isso ocorre porque o ping usa um protocolo completamente diferente (ICMP, enquanto o DNS usa IP e uma combinação de UDP e TCP), em um nível completamente diferente do modelo de rede. Qualquer coisa a caminho, do firewall pessoal ao número de roteadores até o host real em que o serviço está sendo executado, pode ser configurada para jogar fora um deles, mas não o outro (seja a paranóia do administrador ou algum caso de falha), embora normalmente acontece com o ICMP do que outros

• Geralmente, também é bom deixar claro se são suas solicitações (DNS) ou as respostas que estão sendo perdidas.

  Bem, o programa específico que você está usando deve deixar isso claro para você, mas como regra geral, é mais fácil vê-lo na GUI do Wireshark :)

• Como mencionei, o DNS normalmente usa o UDP como forma de entregar o conteúdo da solicitação e resposta.

  Ao contrário de seu irmão TCP, o UDP é definido de forma que não há garantia de que o pacote será entregue, e não há nada que um roteador deva (nem possa) fazer para informar sobre falhas. (Este é um sacrifício para o outro recurso do UDP: é incrivelmente rápido. Os roteadores não precisam manter nenhuma informação sobre remetente nem ordem dos pacotes; eles apenas os transmitem e esquecem rapidamente. TCP.)

Normalmente, a primeira coisa que eu faria seria:

1. Iniciar o Wireshark
2. Clique em Opções de captura
3. Para o filtro Capture, defina host 1.2.3.4para garantir que você esteja capturando apenas o tráfego entre você e o 1.2.3.4
4. Começar captura
5. Depois de ter iniciado tudo dessa maneira, tente seus comandos

No entanto, com base na sua última atualização: não conheço este software, mas definitivamente suspeitaria do cliente uTorrent. É possível que um aplicativo envie muitos UDP que, por exemplo, atingem algum limite no seu roteador doméstico e ele comece a jogar pacotes UDP fora.

Eu tentaria a ferramenta de benchmark DNS do GRC . Ele testa os servidores DNS que você está configurado para usar, assim como muitos outros servidores DNS. Não apenas testa sua velocidade, mas também sua confiabilidade. É gratuito e não precisa ser instalado (embora seja apenas o Windows). Também há muitas informações boas sobre o DNS nessas páginas.

Gostaria de saber em que parte do mundo você está e ajudaria a obter um resultado de tracert / traceroute para google.com e 8.8.8.8.

O problema pode ser causado pelo seu roteador ou pela sua conexão com os servidores do Google. A natureza intermitente do seu problema tem o cheiro de uma conectividade ruim, mas há simplesmente muitos fatores ao analisar os problemas de conectividade da Internet para fornecer uma resposta imediata.

A rede do Google pode ocasionalmente ficar sobrecarregada. Tenho casos diários em que uma solicitação para google.com atinge o tempo limite e precisa ser reiniciada, e eu uso o servidor local do meu país. Em parte, é uma questão de sorte para qual segmento da rede do Google a solicitação é roteada e pode até haver ineficiências nos algoritmos internos de distribuição de solicitações do Google.

Provavelmente é o mesmo com os servidores de nomes do Google. Embora o Google tenha vários deles, a solicitação pode ser roteada para um servidor interno ou um segmento de rede momentaneamente sobrecarregado.

Você não mencionou em que parte do mundo você está situado. Se você não estiver nos EUA, cada solicitação poderá seguir uma rota diferente e enfrentar problemas ou atrasos ocasionais, dependendo de muitos servidores intermediários.

Sem mencionar "otimizações" ou possíveis deficiências do seu ISP, ou qualquer otimização que o Google possa ter feito para particionar a carga em todo o mundo em seus servidores.

O uso de um servidor DNS remoto pode penalizá-lo de outras maneiras. Vejo :

Por que usar o DNS do Google / OpenDNS é uma má idéia
Devo usar o DNS do meu ISP ou o 8.8.8.8 do Google?

Encontrei a solução, embora não a entenda completamente, se alguém puder explicá-la adequadamente, poste-a como resposta e eu darei uma recompensa a ele, porque outras respostas não ajudaram.

Como mencionei no apêndice da pergunta, o uTorrent estava relacionado ao problema, porque o fechamento do uTorrent resolveu o problema. Decidi descobrir como corrigi-lo sem precisar fechar o uTorrent. Em esta discussão e esta (foi muito relevante porque as pessoas não têm o mesmo ISP e router) eu encontrei sugestões que eu deveria desativar proteção contra inundações IP no meu roteador e ele fez o truque! O problema e a solução eram exóticos, possivelmente específicos para o roteador Cisco EPC3925 ou mesmo para um ISP específico (popular na Europa, por isso era difícil pesquisar no Google algo em inglês).