Les deux "netstat -p" et "lsof -n -i -P" semblent lire tous les processus fd, comme stat /proc/*/fd/*.Comment faire comme "netstat -p", mais plus vite?
Comment le faire plus efficacement? Mon programme veut savoir quel processus est en train de se connecter à ce programme.
Traverser tous les processus à plusieurs reprises semble trop inefficace.
Les moyens suggérant des choses iptables ou des correctifs du noyau sont également les bienvenus.
Jetez un coup d'œil à this answer, où sont mentionnés divers procédés et programmes qui effectuent des mappages socket à process. Vous pouvez également essayer plusieurs techniques supplémentaires pour améliorer les performances:
/proc, et les informations contenues dans /proc/net. Ceci est fait par les programmes mentionnés dans la réponse liée, mais n'est viable que si votre processus dure plus de quelques secondes.getpeername(), mais cela vous permet de connaître les points de terminaison possibles et les processus auxquels ils correspondent. Vos questions suggèrent que vous connectez des sockets localement, vous pouvez essayer d'utiliser Unix sockets qui vous permet de recevoir les informations d'identification d'un homologue lors de l'échange de messages en passant SO_PASSCRED à setsockopt(). Jetez un oeil à ces exemples (ils sont assez méchant mais le meilleur que j'ai pu trouver).
fs/proc/base.c dans le noyau Linux. C'est le cœur de l'information donnée par le résultat d'un lien de lecture sur un descripteur de fichier au /proc/PID/fd/FD. Une partie importante de l'overhead est le passage des demandes dans la couche VFS, le verrouillage de nombreuses sur toutes les structures de données du noyau qui fournissent l'information donnée, et la suppression de la chaîne et la destruction au niveau du noyau et de la fin respectivement. Vous pouvez adapter une partie du code dans ce fichier pour générer cette information sans la plupart des couches intermédiaires, en particulier en réduisant le verrouillage à une fois par processus, ou simplement une fois par analyse de l'ensemble de données souhaité.Ma recommandation personnelle est juste la force brute pour l'instant, traverser idéalement les processus en /proc dans l'ordre numérique inverse, les processus les plus récents et intéressants auront plus PIDs, et revenir dès que vous avez trouvé les résultats que vous recherchez. Faire cela une fois par connexion entrante est relativement pas cher, cela dépend vraiment de la performance critique de votre application. Vous trouverez certainement intéressant de contourner l'appel netstat et d'analyser directement la nouvelle connexion à partir de /proc/net/PROTO, puis recherchez le socket dans /proc/PID/fd. Si tout votre trafic est localhost, passez simplement aux sockets Unix et obtenez directement les informations d'identification. Écrire un nouveau module syscall ou proc qui récupère d'énormes quantités de données concernant les descripteurs de fichiers que je voudrais sauvegarder pour la fin.
2 n'est pas un moyen. Sockets Unix non plus. Le programme attrape la connexion redirigée par "-j REDIRECT" et montre à l'utilisateur pour quel programme est la connexion (et applique les politiques en fonction du nom du processus). si firefox puis haut prio; si qbittorrent alors faible prio. –
"Faire cela une fois par connexion entrante est relativement bon marché", même si c'est le cas, l'apparence de "strace" dans la console ne sera pas aussi bonne qu'avant. La majorité des appels système serait en vain (seulement quelques-uns - avec un bénéfice). –
@Vi: Regardez, et l'actualité sont des choses trop différentes. Vous remarquerez peut-être qu'appeler un programme C "semble" très mauvais. Puisque vous ne l'avez pas encore implémenté, vous remarquerez à quel point netstat semble lent. Vous constaterez que cela n'a rien à voir avec la surcharge de la recherche fd dans/proc, et tout ce qui concerne les recherches de noms d'hôtes inverses (passez '-n' pour le contourner). Vous devriez profiler votre application éventuelle avant que vous blâtiez cette partie de votre programme. –
Question similaire: http://stackoverflow.com/questions/838317/how-to-tie-a-network-connection-to-a-pid-without-using-lsof-or-netstat Mais aucune réponse utile . –