J'utilise actuellement une boîte Windows, exécutant Chrome 27 sur le canal de développement, et j'ai ce que je pense être un nombre inhabituellement élevé de connexions d'écoute connectées au processus.
La commande suivante renvoie 268 ports d'écoute:
netstat -aon|find /i /c "11692"
( où dans ce cas 11692 est le principal processus de chrome ).
Voici à quoi ressemblent certains des ports de netstat:
UDP 0.0.0.0:62483 : 11692
UDP 0.0.0.0:62486 : 11692
UDP 0.0.0.0:62487 : 11692
UDP 0.0.0.0:62488 : 11692
UDP 0.0.0.0:62489 : 11692
UDP 0.0.0.0:62492 : 11692
UDP 0.0.0.0:62493 : 11692
UDP 0.0.0.0:62494 : 11692
UDP 0.0.0.0:62495 : 11692
UDP 0.0.0.0:62496 : 11692
UDP 0.0.0.0:62498 : 11692
UDP 0.0.0.0:62499 : 11692
UDP 0.0.0.0:62500 : 11692
UDP 0.0.0.0:62501 : 11692
UDP 0.0.0.0:62502 : 11692
UDP 0.0.0.0:62503 : 11692
UDP 0.0.0.0:62504 : 11692
UDP 0.0.0.0:62505 : 11692
UDP 0.0.0.0:62506 : 11692
UDP 0.0.0.0:62509 : 11692
UDP 0.0.0.0:62510 : 11692
UDP 0.0.0.0:62511 : 11692
UDP 0.0.0.0:62512 : 11692
UDP 0.0.0.0:62513 : 11692
UDP 0.0.0.0:62541 : 11692
UDP 0.0.0.0:62542 : 11692
UDP 0.0.0.0:62543 : 11692
UDP 0.0.0.0:62544 : 11692
UDP 0.0.0.0:62545 : 11692
UDP 0.0.0.0:62547 : 11692
UDP 0.0.0.0:62786 : 11692
UDP 0.0.0.0:62787 : 11692
UDP 0.0.0.0:62789 : 11692
UDP 0.0.0.0:62790 : 11692
UDP 0.0.0.0:62791 : 11692
UDP 0.0.0.0:62792 : 11692
UDP 0.0.0.0:62793 : 11692
UDP 0.0.0.0:62794 : 11692
UDP 0.0.0.0:62796 : 11692
UDP 0.0.0.0:62797 : 11692
UDP 0.0.0.0:62798 : 11692
UDP 0.0.0.0:62799 : 11692
UDP 0.0.0.0:62800 : 11692
UDP 0.0.0.0:62801 : 11692
UDP 0.0.0.0:62802 : 11692
UDP 0.0.0.0:62803 : 11692
UDP 0.0.0.0:62805 : 11692
UDP 0.0.0.0:62806 : 11692
UDP 0.0.0.0:62807 : 11692
UDP 0.0.0.0:62808 : 11692
UDP 0.0.0.0:62809 : 11692
UDP 0.0.0.0:62810 : 11692
UDP 0.0.0.0:62812 : 11692
UDP 0.0.0.0:62813 : 11692
UDP 0.0.0.0:62814 : 11692
UDP 0.0.0.0:62815 : 11692
UDP 0.0.0.0:62817 : 11692
UDP 0.0.0.0:62818 : 11692
UDP 0.0.0.0:62820 : 11692
UDP 0.0.0.0:62821 : 11692
UDP 0.0.0.0:62822 : 11692
UDP 0.0.0.0:62823 : 11692
UDP 0.0.0.0:62824 : 11692
UDP 0.0.0.0:62825 : 11692
UDP 0.0.0.0:62826 : 11692
UDP 0.0.0.0:62827 : 11692
UDP 0.0.0.0:62828 : 11692
UDP 0.0.0.0:62829 : 11692
UDP 0.0.0.0:62830 : 11692
UDP 0.0.0.0:64681 : 11692
UDP 0.0.0.0:64682 : 11692
UDP 0.0.0.0:64683 : 11692
UDP 0.0.0.0:65017 : 11692
Peut-être que je manque quelque chose avec ma lecture de netstat, mais cela semble anormalement élevé.
C'est un problème récurrent. La seule chose nécessaire pour évoquer le grand nombre de ports à l'écoute est de démarrer Chrome. De plus, lorsque je ferme Chrome, au moins un processus est toujours en cours d'exécution après la fermeture du navigateur et semble fonctionner indéfiniment ( ce n'est pas le processus associé au grand nombre de ports ouverts - ou du moins pas par lui-même - comme le les ports disparaissent lorsque je ferme le navigateur ).
Est-ce que quelqu'un sait:
- Si c'est normal?
- Si ce n'est pas normal, qu'est-ce qui pourrait l'expliquer?
- Comment puis-je trouver plus d'informations sur ce qui se passe réellement?
J'ai installé Wireshark, mais cela semble toujours brouiller ma compréhension, et je n'ai pas encore envie d'essayer de le faire. De plus, le journal des événements Windows ne révèle rien.
Notez qu'il ne s'agit pas d'un double de la question Pourquoi Google a-t-il besoin de tant de ports ouverts? car ces ports ne sont pas dédiés à - et ne semblent pas être liés à - des sites Web du tout.
Merci d'avance.
Réponses:
DNS asynchrone sur Chrome, en savoir plus sur The Chromium Projects
Pour faire court: Chrome utilise par défaut les résolutions DNS synchrones Windows natives, ce qui signifie qu'il doit attendre chaque résolution successivement, quel que soit le nombre d'onglets chargés simultanément, ce qui ajoutera un retard notable à leur chargement en fonction de l'ordre de résolution des nouveaux problèmes. hôtes. Une solution proposée était de rendre ce composant asynchrone, car ce Chrome devait contourner le composant DNS natif de Windows, ajouter l'un des siens et ainsi ouvrir quelques ports UDP supplémentaires en cas de besoin.
Ce comportement, dans la question du haut, est dû au fait que le composant est en phase de développement et apparaîtra donc comme tel, a de nombreuses connexions, est illimité et gaspille des ressources. Cela ne se produisait que si l'utilisateur modifiait manuellement un indicateur dans Chrome pour activer cette fonctionnalité, généralement réservée aux développeurs ou contributeurs. Voir "Réponse obsolète" pour une explication sur la façon d'accéder aux anciennes versions de Chrome.
Pour les nouvelles versions de Chrome, je peux dire que pour la v43, ce comportement a été corrigé, et maintenant il utilise moins de ports UDP en fonction du nombre d'hôtes inconnus qu'il doit résoudre, sinon il utilisera des résolutions mises en cache et aura moins de ports ouverts.
Pour autant que je sache, les versions actuelles de Chrome n'ont pas d'indicateur pour l'activer, il existe et peut être activé via un commutateur sur chrome.exe. Par défaut, il est désactivé .
Modifiez les raccourcis de Chrome et ajoutez --enable-async-dns après la cible chrome.exe " , séparez-les par un espace. Dans Windows 7, pour un raccourci épinglé, cliquez avec le bouton droit sur l'épingle, dans le menu des vignettes, cliquez avec le bouton droit sur le raccourci Google Chrome au-dessus de l' option Détacher ce programme ... et accéder à ses propriétés, modifiez-y la cible.
Pour savoir si le DNS asynchrone est activé, accédez à chrome: // net-internals / # dns et il devrait y avoir une liste intitulée Client DNS interne activé: vrai ou faux
Réponse obsolète (option existe dans les anciennes versions, environ 27):
Saisissez-le dans la barre d'adresse de Google Chrome:
Faites défiler la liste et assurez-vous que " DNS asynchrone intégré " est désactivé.
la source