Pourquoi le système écoute-t-il sur le port 8000?

13

J'ai remarqué par accident aujourd'hui que j'ai un serveur Web inconnu qui écoute sur le port 8000. L'ouverture de http: // localhost: 8000 renvoie simplement 404, donc je n'ai aucune idée de ce qui écoute exactement là-bas.

J'ai l'habitude netstat -anode savoir que le processus avec PID 4 écoute sur ce port. PID 4 est le processus système. Pourquoi mon système écoute-t-il sur ce port, sans que je démarre réellement un serveur? Ou comment puis-je savoir ce qui écoute exactement là-bas?

J'ai lu les questions connexes sur le port 80 et le port 443 , mais aucun des services mentionnés n'y était exécuté sur mon système. Et les autres suggestions n'ont pas fonctionné non plus.

Éditer:

La réponse HTTP du serveur est répertoriée Microsoft-HTTPAPI/2.0comme serveur.

edit2:

Comme demandé par Shadok, voici les entrées de TCPView avec 8000 comme port. Mais je doute que ce soit utile du tout…

Résultats TCPView

windows-7 windows port

— poussée
source

17

IIRC, tout programme qui utilise l' API HTTP Server pour exécuter un serveur HTTP sur Windows verra ce service facturé au processus système car il s'exécute via le http.sysserveur du noyau .

Vous pouvez voir les URL enregistrés en exécutant la commande suivante: netsh http show servicestate. Cela inclura également le numéro de port.

netstat -ab peut également révéler quels services ont commencé à écouter sur un port donné.

— afrazier
source

Je vous remercie! J'aurais vraiment dû y penser moi-même… J'ai compris que c'était VAIO Care (un utilitaire Sony) qui avait lancé le service (VCAgent.exe). Mais apparemment, ce service n'est pas vraiment nécessaire. J'ai gardé un renifleur de réseau ouvert pour vérifier s'il y a des demandes au serveur en cliquant dans le programme, mais rien ne s'est vraiment passé (la demande normale dans le navigateur Web est apparue). Quoi qu'il en soit, je l'ai supprimé du démarrage automatique, donc cela devrait être résolu maintenant. Bien qu'il soit assez stupide que toutes les API du serveur utilisent toujours le processus système.

— poke

+1 pournetstat -ab

— Kevin Kibler

Dommage que mon netstat -abdit "Impossible d'obtenir les informations de propriété", donc je suis bloqué, mais sinon, c'est toujours une commande utile

— Tominator

1

Pour référence, mon cas est Free Video Maker utilisé le port. J'ai rencontré un conflit de serveur de tutoriel Angular JS, je dois donc le résoudre.

— simongcc

1

(Dans le cas où cela se perd, j'ai également ajouté une réponse.) Essayez également: netsh http show servicestate view = requestq

— Nick Westgate

4

Un peu tard, peut-être, mais ce fil est apparu assez haut dans ma recherche sur Google, et semblait le plus pertinent, mais il manquait cette dernière information que j'ai trouvée utile.

Vous pouvez voir les URL enregistrées (dynamiquement) en exécutant la commande suivante: netsh http show servicestate

— PiBa-NL
source

1

Un peu de recherche sur Google montre des exemples d'applications WCF utilisant 8000 et l'interface Intel Remote Desktop. Je ne m'attendrais pas à ce qu'ils fonctionnent en tant que système.

Il y a quelques chevaux de Troie / portes dérobées qui utilisent 8000, donc peut-être que démarrer un disque antivirus et faire une analyse complète serait une bonne idée.

— Paul
source

1

Vous pouvez utiliser TCPView pour trouver beaucoup plus d'informations sur ce processus que ce que vous pouvez trouver via netstat.
Si vous ne savez toujours pas ce que l'application est vraiment après cette publication, une capture d'écran de la ligne mentionnant le port 8000 et nous le saurons.

— Shadok
source

TCPView n'affiche pas plus que netstat (c'est pourquoi je n'ai même pas mentionné que je l'ai essayé). Mais bien sûr, j'ai ajouté une capture d'écran des lignes du port 8000 à ma question.

— poke

1

Les sockets système (PID 4) peuvent être http.sys, auquel cas vous pouvez utiliser la commande netsh donnée par PiBa-NL.

Mais notez qu'il y a quelques paramètres. Il semble que les valeurs par défaut équivalent à:

netsh http show servicestate view=session verbose=yes

La vue des sessions n'a pas aidé dans mon cas, mais cela a montré le PID:

netsh http show servicestate view=requestq

— Nick Westgate
source

Merci! Le PID était la clé pour moi.

— duct_tape_coder

0

Dans mon cas, le port 8000 a été repris par les pilotes de la carte son Sound BlasterX AE-5 . Le processus Creative.AudPosServicesitué dans C:\Program Files (x86)\Creative\Connection Serviceutilise ce port.

Heureusement, il est possible de changer ce port. Ouvrez la Creative.AudPosService.exe.configligne et le changement où le numéro de port est situé <add baseAddress="http://localhost:8000/"/>à <add baseAddress="http://localhost:9999/"/>ou toute autre chose qui ne gêne pas votre travail. Redémarrez l'ordinateur et ça devrait aller.

— Vladimir Jovanović
source