Comment afficher les tailles de file d'attente d'envoi et de réception TCP sous Windows?


10

Linux netstat affiche les tailles de file d'attente d'envoi et de réception.

Comment obtenir ces informations sous Windows, en particulier Server 2003?


Pouvez-vous coller un exemple de la sortie que vous aimeriez voir?
Izzy

Consultez ce lien. J'ai besoin des colonnes Recv-Q et Send-Q de netstat. linux-ip.net/html/tools-netstat.html

Réponses:


3

(c'est un peu une décharge de cerveau)

En regardant quelques versions de la source netstat, il semble que les informations que vous recherchez sont interrogées directement depuis le noyau (/ proc / net / ...) et non via des appels liés aux sockets qui ont des équivalents Windows. Si vous êtes vraiment déterminé à avoir cela, je regarderais comment il est récupéré dans netstat et voir ce que vous pouvez trouver qui fournit quelque chose d'équivalent.

Vous devriez probablement consulter ndis.com (Network Driver Interface Specification) et PCAUSA.com pour des informations au niveau du pilote, car c'est probablement votre meilleur endroit pour récupérer ces informations sur Windows.

Je ne pense pas que getsockopt () ou la plupart de l'arène Winsock vous rendra utile, mais si vous voulez aller dans cette direction, consultez les informations MSDN Winsock et consultez également la FAQ du programmeur Winsock .

Pour les communications entrantes, vous pourrez peut-être obtenir quelque chose d'utile à partir de la fonction ioctlsocket () avec FIONREAD pour obtenir la quantité de données lisibles pour un socket; il se peut que vous ne puissiez pas obtenir cela entre les processus et selon le type de données, il peut ne renvoyer des informations pour le premier bloc de données que pour la file d'attente entière s'il y a plus d'un élément en file d'attente.

Vous pourriez faire quelques recherches sur le «backlog» dans ce contexte, mais la plupart de ce que j'ai vu semblait concerner la définition de la taille maximale pour traiter les inondations SYN, pas vraiment pour voir la taille réelle du backlog.

Si vous êtes vraiment déterminé, vous pourriez peut-être faire quelque chose avec votre propre fournisseur de services en couches , mais c'est une route étrange et laide pleine de dangers et je vais suggérer de rester à l'écart.

MISE À JOUR: Après avoir fouillé un peu plus, je pense vraiment que vous devriez envisager d'interroger les OID NDIS. Trouver les informations les plus pertinentes pour vous est laissé comme un exercice entre vous, MSDN et TechNet.


3

Cette question est ancienne mais je voulais ajouter quelques informations. C'est un résultat de recherche assez élevé sur Google.

Pour autant que je sache, il n'y a pas moyen de le faire, mais si quelqu'un peut creuser davantage et trouver une alternative valable, ce serait très apprécié!

Comme @Fencepost l'a souligné dans sa réponse, vous pouvez essayer d'interroger les OID NDIS. L'OID NDIS le plus pertinent que j'ai trouvé est OID_GEN_TRANSMIT_QUEUE_LENGTH

La plupart des OID NDIS sont mappés à des classes WMI, vous pouvez les répertorier dans PowerShell avec

Get-WmiObject -Namespace root\wmi -List  | Where-Object {$_.name -Match "MSNdis" } | Sort-Object

mais il ne semble pas y en avoir un pour la longueur de la file d'attente de transmission.

@Chris J a mentionné Interface Network \ Output Queue Length. Vous pouvez obtenir cette valeur sur la ligne de commande avec typeperf .

typeperf "\Network Interface(*)\Output Queue Length" -sc 1

Mais la valeur est toujours 0: http://support.microsoft.com/kb/822226

Windows ne garde la trace de ces informations que dans le logiciel du pilote NIC, et ce ne sont que des paquets mis en file d'attente par NIC, et ne fait pas de distinction entre ce qui est mis en file d'attente par socket.

Si vous souhaitez effectuer le débogage réseau sur la ligne de commande, tous les compteurs que vous trouvez dans perfmon peuvent être interrogés à l'aide de typeperf ou logman .


1

Ce que vous voulez peut être les résultats des appels de fonction de l'API WinSock getsockopt:

  • SO_RCVBUF Espace tampon total par socket réservé pour les réceptions. Ceci n'est pas lié à SO_MAX_MSG_SIZEet ne correspond pas nécessairement à la taille de la fenêtre de réception TCP.

  • SO_SNDBUF Espace tampon total par socket réservé aux envois. Ceci n'est pas lié à SO_MAX_MSG_SIZEet ne correspond pas nécessairement à la taille d'une fenêtre d'envoi TCP.

Le problème est qu'on peut demander des sockets dont vous connaissez la poignée. Interroger de l'extérieur semble être difficile, jetez un œil à l' outil sysinternals TcpView . Mark Russinovich est vraiment un crack et même lui ne fournit pas les informations dans son outil. Je suis à peu près sûr qu'il aurait ajouté une colonne s'il avait eu un moyen d'obtenir facilement les valeurs ...

Je suppose qu'un pilote de noyau pourrait aider à explorer le système mais n'a trouvé aucun outil disponible. Les tailles peuvent être définies sur une base par socket afin que les valeurs globales n'aient aucune signification ...


1

La chose la plus proche que je peux trouver est le compteur de performances Network Interface\Output Queue Length. Ce n'est pas par connexion - seulement par interface et ne couvre que la file d'attente sortante (évidemment, par son nom).


1

Maintenant, les tailles de fenêtre sont différentes par socket! Les paramètres par interface ne représentent que les valeurs par défaut.

Je ne connais aucun moyen de voir la taille de la fenêtre de chaque socket. Dans Solaris, cela peut être vu avec "netstat".


0

1
en particulier, que suis-je censé regarder là-bas?

Windows utilise divers algorithmes pour définir sa taille de fenêtre de réception TCP; vous pouvez remplacer la valeur par défaut en définissant une clé de Registre. Ce programme peut également vous aider: dslreports.com/drtcp .
Massimo

Massimo- vous confondez la taille des fenêtres avec les données en file d'attente. Je ne suis pas intéressé par la taille des fenêtres.

D'accord désolé. De toute façon, ces informations ne sont pas disponibles dans Windows.
Massimo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.