TCP affiche LISTENING dans la colonne d’état alors que UDP n’affiche rien:
Est-ce parce que UDP n'a qu'un seul état (qui est à l' écoute ) et qu'il n'est donc pas nécessaire de le montrer, ou y a-t-il une autre raison?
TCP affiche LISTENING dans la colonne d’état alors que UDP n’affiche rien:
Est-ce parce que UDP n'a qu'un seul état (qui est à l' écoute ) et qu'il n'est donc pas nécessaire de le montrer, ou y a-t-il une autre raison?
Réponses:
Comme mentionné dans les commentaires, UDP est sans connexion. Contrairement à TCP, il n’a pas de concept "à l’écoute", "établi", "fermé" ou quelque chose du genre. Si un port UDP est ouvert, il apparaît dans la liste. si ce n'est pas ouvert, ce n'est pas. Il n'y a pas d'autre état à afficher. Afficher LISTENING
ou quelque chose de similaire dans cette colonne pourrait impliquer qu'il existe d'autres états possibles, ce qui serait faux.
Malgré des affirmations selon lesquelles netstat ne montre pas l' état car UDP est apatride, netstat sur son OS non-Windows ne montre une valeur pour la colonne Etat. Par exemple, Solaris affiche "Idle" ou "Unbound". Autant que je sache, les sockets "inactifs" sont ceux liés à des ports locaux particuliers, alors que les sockets "non liés" sont toujours "*. *" Et sont donc probablement ouverts mais non liés à des ports particuliers. netstat sur Linux peut afficher au moins "ESTABLISHED". De plus, j'aimerais quand même savoir si un port UDP attend des connexions en provenance d'autres sources pour initier du trafic ou s'il est simplement ouvert pour pouvoir envoyer des éléments ailleurs.
read
), il existe ou non un processus en attente d'un recv
appel système bloquant (ou lié), et le noyau sait s'il existe un tel processus (car, tout comme avec un tuyau ou un tty, il doit savoir comment réagir lorsque l’entrée apparaît). Il devrait donc être possible netstat
de déterminer et de signaler si un processus attend de recevoir des données sur un socket UDP.