uTorrent oblige DNS à cesser de fonctionner de temps en temps

Lorsque vous utilisez uTorrent, DNS cesse périodiquement de répondre.

Le problème ne semble pas être lié à une utilisation excessive de la bande passante (comme vu du routeur à l'ordinateur), mais peut être lié à une certaine forme de protection contre les inondations fournie par le routeur (plus de connexions entrantes au routeur que Windows acceptera).

Comment faire pour que le réseau fonctionne correctement (tout en étant capable d'utiliser uTorrent, bien sûr)?

les clients bittorents se connectent agressivement à leurs pairs ... et certains routeurs interprètent cela comme une syn-flood.

Connexions ouvertes

Lorsque uTorrent est chargé et les chargements / téléchargements sont suspendus (pas arrêtés), il maintient des connexions ouvertes avec vos pairs. Pendant ce temps, des légions de pairs Internet tenteront toujours de se connecter à vous pour savoir si vous avez les bits qu'ils veulent.

Finalement, vous atteindrez la limite de connexion ouverte imposée par votre système d'exploitation (dans Windows 7, c'est 10 connexions) et les connexions de nouveaux clients commenceront à faire la queue sur votre routeur.

Les clients en file d'attente vérifieront agressivement pour voir si une connexion est libre. Cette interrogation agressive peut être interprétée comme une attaque syn-flood par le routeur.

Solutions

• abaissez votre limite de connexion semi-ouverte dans votre logiciel bittorent en dessous de la limite de connexion imposée par votre système d'exploitation
• désactivez la protection contre les inondations IP sur votre routeur / modem.

Saturation de la bande passante

De plus, avec la connexion uTorrent (ou tout trafic en vrac) fonctionnant sans restriction, le canal de téléchargement (et éventuellement de téléchargement) atteint sa pleine utilisation, forçant une partie du trafic "d'entretien" à prendre place à l'arrière, ce qui finit par diminuer l'utilité du réseau.

Voici un exemple:

1. Le téléchargement à haute vitesse (torrent ou autre) sature le lien en aval.
2. L'utilisateur essaie de naviguer vers un site qui n'a pas été visité récemment. L'ordinateur génère une demande d'informations DNS pour le site souhaité. Le "téléchargement" de la demande vers le serveur DNS réussit (non contesté pour l'accès en amont).
3. Le serveur DNS répond (ou tente de le faire), mais la réponse se bloque en essayant d'accéder à la machine de l'utilisateur parce que le canal de téléchargement est saturé de contenu de téléchargement, et puisque quelque chose doit être abandonné et que le téléchargement est agressif pour maintenir la vitesse, le La réponse DNS est supprimée (à un moment donné avant d'arriver au routeur local).

La même chose peut se produire si le téléchargement n'est pas limité. Avec le téléchargement saturé, les paquets connus sous le nom de TCP-ACK (qui sont envoyés sous la forme de réponses de type "Hé, j'ai reçu les paquets xyz avec succès") sont bloqués, ce qui rend les téléchargements interrompus, ce qui rend la navigation Web très inégale.

Solutions

• Déterminez quelles sont les capacités maximales de votre connexion (de haut en bas, individuellement) et définissez la vitesse maximale de vos clients de transfert en masse pour ne pas utiliser plus d'environ 80% de cette vitesse. Cela laissera une "marge" pour des choses comme les paquets DNS et TCP-ACK pour contourner le trafic en masse et être traitées rapidement.
• Utilisez un routeur qui peut gérer la mise en forme du trafic de telle sorte que certains trafics (DNS, Ping IMCP, TCP-ACK) peuvent être priorisés avant d'autres formes de trafic, et certaines formes de trafic (torrent en particulier) peuvent être dé-priorisées. C'est ma méthode préférée. Cela peut donner l'avantage supplémentaire de permettre au tuyau ascendant et descendant complet d'être utilisable pour le trafic torrent lorsque le trafic de priorité plus élevée ne le conteste pas.
• Utilisez une combinaison de 1 et 2 pour limiter le trafic "mal se comporter".

Si vous êtes intéressé par plus d'informations sur le trafic façonnant les distributions Linux / BSD, MonoWall et IPCop ont tous deux de bonnes informations.

Quand j'ai quelque chose comme ça, Wireshark est mon meilleur ami.

Mais d'abord, il est bon de réaliser ces trois choses:

• Le fait que le ping fonctionne ne signifie pas que le DNS (ou tout autre service) fonctionne, et vice-versa.

  En effet, ping utilise un protocole complètement différent (ICMP, tandis que DNS utilise IP et une combinaison de UDP et TCP), à un niveau de modèle de réseau complètement différent. Tout ce qui se passe, depuis votre pare-feu personnel en passant par le nombre de routeurs jusqu'à l'hôte réel où le service est en cours d'exécution, peut être configuré pour éliminer l'un d'eux, mais pas l'autre (qu'il s'agisse de la paranoïa de l'administrateur ou d'un cas d'échec), bien que cela arrive normalement plutôt à ICMP qu'aux autres

• En règle générale, il est également bon de préciser si ce sont vos demandes (DNS) ou les réponses qui se perdent.

  Eh bien, le programme particulier que vous utilisez devrait vous le faire comprendre, mais en règle générale, il est plus facile de le voir vous-même dans l'interface graphique de Wireshark :)

• Comme je l'ai mentionné, DNS utilise normalement UDP comme moyen de fournir le contenu de la demande et de la réponse.

  Contrairement à son frère TCP, UDP est défini de manière à ce qu'il n'y ait aucune garantie que le paquet sera livré, et aucun routeur ne doit (ni ne peut) faire pour vous informer de l'échec. (C'est un sacrifice pour une autre caractéristique de UDP: il est incroyablement rapide. Les routeurs n'ont pas à conserver d'informations sur l'expéditeur ni l'ordre des paquets, ils les transmettent rapidement et oublient. Ils peuvent même leur donner une priorité plus élevée que TCP.)

Habituellement, la première chose que je ferais serait:

1. Démarrer Wireshark
2. Cliquez sur Options de capture
3. Pour le filtre de capture, host 1.2.3.4assurez-vous que vous capturez uniquement le trafic entre vous et 1.2.3.4
4. Commencer la capture
5. Une fois que vous avez tous démarré de cette façon, essayez vos commandes

Cependant, sur la base de votre dernière mise à jour: je ne connais pas ce logiciel, mais je soupçonnerais certainement le client uTorrent. Il est possible qu'une application envoie trop de UDP, par exemple qu'une certaine limite soit atteinte sur votre routeur domestique et qu'elle commence à jeter les paquets UDP.

Je voudrais essayer l' outil DNS Benchmark de GRC . Il teste les serveurs DNS que vous êtes configuré pour utiliser, ainsi que de nombreux autres serveurs DNS. Non seulement il teste leur vitesse, mais aussi leur fiabilité. C'est gratuit et n'a pas besoin d'être installé (c'est Windows seulement). Il y a aussi beaucoup de bonnes informations sur DNS sur ces pages.

Je voudrais savoir dans quelle partie du monde vous vous trouvez, et cela aiderait d'avoir un résultat tracert / traceroute pour google.com et pour 8.8.8.8.

Le problème pourrait être dû à votre routeur ou à votre connexion aux serveurs de Google. La nature intermittente de votre problème a l'odeur d'une mauvaise connectivité, mais il y a tout simplement trop de facteurs lors de l'analyse des problèmes de connectivité Internet pour vous donner une réponse immédiate.

Le réseau de Google peut parfois être surchargé. J'ai des cas quotidiens où une demande de google.com arrive à expiration et doit être redémarrée, et j'utilise son serveur local pour mon pays. C'est en partie une question de chance vers quel segment du réseau de Google la demande est acheminée, et il peut même y avoir des inefficacités dans les algorithmes internes de distribution des demandes de Google.

C'est probablement la même chose avec les serveurs de noms de Google. Bien que Google en possède plusieurs, la demande peut être acheminée vers un serveur interne ou un segment de réseau momentanément surchargé.

Vous n'avez pas mentionné dans quelle partie du monde vous vous trouvez. Si vous n'êtes pas aux États-Unis, chaque demande peut prendre un chemin différent et peut rencontrer des problèmes ou des retards occasionnels si elle dépend de trop de serveurs intermédiaires.

Sans parler des "optimisations" ou des éventuelles déficiences de votre FAI, ni des optimisations que Google aurait pu faire pour répartir la charge mondiale sur ses serveurs.

L'utilisation d'un serveur DNS éloigné peut vous pénaliser d'autres manières. Voir:

Pourquoi utiliser Google DNS / OpenDNS est une mauvaise idée
Dois-je utiliser le DNS de mon FAI ou le 8.8.8.8 de Google?

J'ai trouvé une solution, bien que je ne la comprenne pas complètement, si quelqu'un peut l'expliquer correctement, veuillez la poster comme réponse et je lui donnerai des primes, car d'autres réponses n'ont pas aidé.

Comme je l'ai mentionné dans l'annexe de la question, uTorrent était lié au problème, car la fermeture d'uTorrent a résolu le problème. J'ai décidé de découvrir comment le réparer sans avoir besoin de fermer uTorrent. Dans ce fil et celui-ci (c'était très pertinent car les gens là-bas ont le même FAI et le même routeur), j'ai trouvé des suggestions que je devrais désactiver la protection contre les inondations IP sur mon routeur et ça a fait l'affaire! Le problème et la solution étaient exotiques, peut-être spécifiques au routeur Cisco EPC3925 ou même à un FAI particulier (populaire en Europe, c'est pourquoi il était difficile de google quelque chose en anglais).